Chromium is an excellent desktop browser, but it was not designed as a small, embeddable automation runtime. Most browser automation systems inherit Chromium's full browser stack even when they only need programmable page execution.
Costs of the Chromium model
- Large runtime footprint for every browser instance
- Higher memory and CPU overhead at scale
- Complex process, sandbox, profile, and lifecycle behavior
- Slower cold starts and heavier deployment artifacts
- Difficult deep customization below the automation API layer
- Architecture optimized for interactive browsing, not machine-driven execution
What Koko focuses on
Koko is not trying to be a full desktop-browser replacement. It targets the subset automation systems need most:
- Deterministic navigation
- DOM and Web API execution
- Protocol control (CDP, MCP)
- Lifecycle correctness
- Embeddable multi-session runtime behavior
Benchmark evidence
On local fixtures, Koko navigation is ~4× faster than Playwright bundled Chromium; Wikipedia crawl shows ~3× lower RSS per page. See Microbench and Wikipedia crawl.
Koko treats the browser as programmable infrastructure: smaller, easier to control, easier to embed, and better suited for AI-native workloads.
Trade-offs
Koko prioritizes runtime correctness and controllable browser behavior over desktop-browser feature parity. Not every Chrome feature or site compatibility edge case is replicated — the goal is reliable automation infrastructure, not human browsing UX.