[Eval] Qualify Kev (kev-0.6b-browser-use and Kev-4B) as an open browser decision model through the existing System One path #108

Why

Every open browser backend we have today is either a vision model (omnijev, onejev, jev-vl-served) or a general text decision model that was never trained on web pages (laya, cua, clm). The browser front's text path has no open model that was fine-tuned for "which element, which operation". Two releases in the last weeks fill that gap and speak the same wire we already have:

• jaredpalmer/kev (Apache-2.0, pushed 2026-10-27): a family of Jev-like decision models on Qwen3.5/3.8. Its README says the server "matches TypeSafe's System One" (POST /v1/systemone) and that "the TypeSafe Python SDK works against a Kev server unchanged". Each checkpoint ships with a fitted temperature, and the README reports calibration against Jev on new-source questions.
• arbazsiddiqui/kev-0.6b-browser-use (Apache-2.0, code and eval harness, write-up): Kev-0.6B fine-tuned on Mind2Web plus WebChain. On the author's 1,000 Mind2Web test steps with 10 candidates it reports 32.2% step success (Kev-9B 32.5, hosted Jev 43.5, Laya 3.8), Brier 0.84, 80 ms per decision on an L4. It is served with python -m kev.serve --run arbazsiddiqui/kev-0.6b-browser-use.

Because TYPESAFE_API_URL already overrides the jev endpoint (docs/configuration.md), this should need no new adapter, only a qualification run, the same way #103 qualifies Open-Jev.

Proposed scope (one PR of evidence and docs)

1. Serve kev-0.6b-browser-use and one general Kev checkpoint (for example jaredpalmer/kev-4b) with kev.serve; point --model jev at it with TYPESAFE_API_URL and TYPESAFE_MODEL. Record the checkpoint revision the server reports in GET /v1/models, not the name we sent.
2. Check the request shape first. kev-0.6b-browser-use was trained on Mind2Web-style candidate lists with 10 candidates at a time, while our browser front sends the jev-ultrafast state and one target head per operation. Measure whether it still works on our shape before any task run; if it needs a different state layout, record that as a finding and stop rather than writing a shaping layer in this PR.
3. Run the WebVoyager Allrecipes task 0 from the README table and the deterministic local search scenario, with every attempt counted (successes, failures, timeouts, BLOCKED), decision p50/p95 latency and hardware.
4. Add a Kev row to docs/capabilities.md that separates "wire compatible" from "qualified on this checkpoint", and link it from [Tracking] Roadmap: applications, benchmarks, model backends and System1-Omni #54.

Acceptance criteria

• Every claimed run names the Agents SHA, the Kev server commit, the checkpoint revision, hardware and S1A_DECISION_TIMEOUT_S.
• Results under docs/results/ show both Kev checkpoints next to hosted Jev on the same task and budget, including failures.
• If any field of our /v1/systemone request is rejected or ignored by kev.serve, the doc says which.
• No claim is copied from the upstream Mind2Web table; only our own runs are reported as ours.

Out of scope

• The in-browser WebGPU build (ONNX) and open-jev npm path.
• Fine-tuning Kev on our own traces (a follow-up once the baseline exists).
• A new --model kev adapter, unless step 2 proves the existing one cannot carry it.

Related

#54 (roadmap, model backends), #103 (Open-Jev qualification through the same path), #94 / #107 (a calibrated local model makes a cheaper first stage for deferral), #13 (repeatable suites), #109 (offline step-level browser benchmark).