Browser UI actions 5-10x slower than chrome-devtools / playwright MCP (login flow takes 20-30 min vs 1-2 min)

[rahul-lt]

Summary

kane-cli browser objectives run 5–10× slower than equivalent flows via chrome-devtools MCP or playwright MCP. Same UI flows that take 1–2 min on those MCPs take 20–30 min on kane-cli.

Repro

1. Launch browser via kane-cli with an objective like "open , fill login (email + password), click Sign in, land on dashboard".
2. Observe per-step UI action latency (fill input, click button, wait for navigation).

Observed

• Each UI action (type into field, click, wait-for) takes 5–10 min to resolve.
• Full login + a couple of post-login UI steps balloons to 20–30 min per run.
• Behavior consistent across multiple sessions/objectives, not a one-off.

Expected

Comparable latency to other browser-driving MCPs:

Tool	Same login + few UI actions
chrome-devtools MCP	1–2 min
playwright MCP	1–2 min
kane-cli	20–30 min

Impact

Makes kane-cli unusable for iterative UI work — every objective requires a coffee break. Devs are routing around it via chrome/playwright MCP for anything UI-heavy.

Environment

• kane-cli (latest as of 2026-05-28)
• macOS (Darwin 25.5.0)
• Run via Claude Code skill (kane-cli)

Asks

1. Is there a known perf bottleneck (planner roundtrips per step? screenshot+vision per action? snapshot diffing?) — and a flag to skip/disable for cheaper steps?
2. Any tuning (model tier, observation mode, headless vs headful) that reduces per-step latency?
3. Roadmap for parity with chrome-devtools/playwright MCP latency?

[samyakLambda]

Hi! To help us narrow down the root cause, could you share a session ID from one of the slow runs?

You can find it in the kane-cli output — it's usually printed at the start of a run as Session ID: <id> or visible in the run URL on the LambdaTest dashboard.

With that we can pull the step-level timing logs and confirm whether the slowdown is coming from the until_condition polling loop, the LLM round-trips, or something else entirely.