Kitsuvo MCP performance: measured local results

Fast browser control helps an LLM work through pages. These local measurements describe the browser tool loop, with explicit limits.

Measured on October 11, 2026

The local comparison included fresh inline page state after each action. Values are median / p95 milliseconds. Snapshot, click and fill rows use 30 samples per server; warm navigation uses 10. Complete 600-row reads include the final sentinel.

Local MCP timings, including page state
WorkflowKitsuvo stdioKitsuvo HTTPPlaywright MCPDevTools MCP
Small snapshot1.7 / 12.13.3 / 5.39.8 / 24.21.9 / 2.8
Click + snapshot2.9 / 11.94.0 / 5.7541.5 / 606.6230.6 / 244.1
Fill + snapshot2.4 / 11.34.3 / 9.215.9 / 27.3226.6 / 235.4
Warm navigation + snapshot20.4 / 40.119.6 / 23.038.0 / 57.3118.1 / 125.5
Complete 600-row snapshot10.1 / 14.914.5 / 24.845.2 / 51.886.1 / 112.2

Kitsuvo stdio had the lowest median in these five workflows. DevTools had the better p95 for the small snapshot. Results vary between runs and transports.

How the comparison was run

The test used a shared Apple M5 Max machine with 64 GB RAM, two rounds with reversed server order, a matched 648 × 603 viewport, WKWebView for Kitsuvo and Chrome for competitors. Pinned versions were Playwright MCP 0.0.83, Chrome DevTools MCP 1.10.1 and MCP SDK 1.32.1. The final run recorded 722 successful timed observations and zero tool failures.

Playwright's implicit snapshots were file-backed, so the comparison included an explicit snapshot to provide inline page state. DevTools used includeSnapshot for click/fill and an explicit snapshot after navigation. This is not a comparison of acknowledgement-only calls.

What these numbers do not prove

The pinned Kitsuvo release build excluded embedded inference. It was an MCP-path build, not validation of the full default build or the currently installed app. Other work ran on the shared machine. These results do not establish real-site task completion speed, production cloud latency, sustained concurrency, Windows performance, token savings, memory or energy use. Website loading and model reasoning can dominate total task time.

The evidence supports a fast local MCP control loop under these conditions. It does not establish that Kitsuvo is the fastest browser in every environment.

Why the control loop is inexpensive

The Rust host uses native browser engines, a JavaScript page helper and MCP over JSON-RPC. The helper is reused per document. Actions return updated state in the same request. Explicit readiness checks replace unconditional waits, while bounded queues and cancellation prevent stale work from accumulating.

Read the benchmark record and reproduction commands. Try an LLM browsing task, or connect your client.