A verified fast pass shipped 80% of edits in under 300 ms

Summary. Jomoq-1 is a unified editing model built from two stages: a fast pass on a ~3,000 tokens/second engine that either finishes an edit outright or writes a handoff brief, and a frontier-model lane that takes over when the fast pass declines. Drafts only ship after deterministic verification: the ops apply cleanly, the document stays structurally sound, and no truncation markers appear. In our first benchmark of 20 playground editing tasks, this pipeline matched a frontier-only baseline at 100% task success, under both deterministic checks and an independent model judge, while shipping 80% of edits from the fast lane at a median 288 ms, at 17.7× lower cost than the classic full-rewrite approach, and, unlike cache-transfer methods, with zero approximation: every shipped edit is either verified or the frontier model's own output.

Background: nobody wants to pay the big model to read

Most of the latency and much of the cost in an AI editing turn is spent on the model ingesting context it doesn't strictly need: re-reading an entire file to change one heading. The interesting recent work on this is TrustAI's KV-cache transfer: run prefill on a small model, project its attention cache into a larger model through a learned per-head mapping, and let the large model decode from the transferred state. Their published results are honest and worth reading: a 7.91× faster target start at 8K tokens when the cache is preloaded, which becomes 1.25× end-to-end once the small model's reading time is counted; continuation agreement with the unassisted large model of 61–82% depending on the pair; and a per-model-pair trained mapper, restricted to open-weight families they serve themselves.

We took the same economic premise (the small model does the reading) and moved the handoff from the tensor level to the task level, where it can be exact.

Method: draft or brief, then verify

Every Jomoq-1 turn opens with one call to a small open-weight model (gpt-oss-120B) served at roughly 3,000 tokens/second. The call has a two-outcome contract:

• Draft. For a request the model judges simple (text changes, style tweaks, attribute edits, small self-contained additions), it returns find-and-replace operations directly. A deterministic gate then verifies the draft: every match is present and unique, the resulting document passes a structural balance check, and no omission markers appear. A verified draft ships. Total cost of the gate: microseconds, zero tokens.
• Brief. For anything it isn't confident about, the model instead returns an orientation brief (a summary plus verbatim excerpts of the relevant regions) and the turn escalates to a frontier model (Claude Sonnet 5 in this study). Crucially, the escalated model retains access to the ground-truth file, so the brief accelerates it without ever limiting it.

A failed verification silently converts the draft into a brief and escalates. The user never sees a downgrade; they see speed where speed was safe. This is the property cache transfer cannot offer: a transferred KV cache is the large model's context, approximation and all: 61–82% agreement is the input, not an implementation detail. A task-level handoff makes the small model's work either verified or advisory, never load-bearing for correctness.

Benchmark

JomoqBench v0 is 20 editing tasks over three realistic single-file pages (a 60-line landing page, a 170-line portfolio, a 480-line storefront), spanning the five categories our playground traffic actually contains: text changes, style tweaks, single-element edits, refactors, and generative additions. Success requires the edit to apply cleanly, the document to stay structurally balanced, and task-specific checks to pass. We ran four configurations on the same tasks:

*Full-rewrite baseline ran on a representative 8-task subset. On that matched subset the pipeline averaged $0.0031/turn, 17.7× cheaper, reaching 43× on the largest file, where a rewrite costs $0.106 against the fast lane's $0.0025. All numbers are single-run, n=20, and should be read as preliminary.

Three results stand out. First, the pipeline recovered every task the fast model alone dropped (17/20 → 20/20): the misses were refactor/generative tasks whose exact-match edits the small model fumbled, and every one escalated and succeeded. The escalation lane is measurably load-bearing, which is also the answer to "why not just use the fast engine for everything." Second, the judge layer earned its place: in an earlier run, a drafted class rename passed every deterministic check but missed the descendant CSS selectors. An independent claude-opus-5 judge caught it, we moved cross-cutting renames to the escalate side of the boundary, and the re-run above is clean under both deterministic checks and the judge, with zero false ships among drafts. Third, 80% of tasks never touched a frontier model at all, landing at a median 288 ms, a latency class where the edit feels attached to the keystroke.

Comparison with KV-cache transfer

Limitations

• n=20 and a single run per configuration, with one boundary-tuning iteration between runs. Success is graded by deterministic checks plus an independent claude-opus-5 judge; a larger task set is the next measurement pass.
• Our baselines are single-shot API calls: the strongest form of the traditional approach. Production agent loops add system prompts, history, and 2–3 iterations per turn, so multiples measured here are conservative; shadow-mode telemetry against real traffic will produce the definitive latency numbers.
• One serving-stack observation cut against folklore: the full-rewrite baseline returned ~9K-token rewrites in under a second, consistent with copy-optimized speculative decoding on the serving side. Rewrite latency is no longer the weak point of the traditional approach: rewrite cost is, and that cost scales with file size while the fast lane's does not.
• Draft-rate and category boundaries were calibrated on this task distribution; real traffic will move them.

What ships

The pipeline described here ships as Jomoq-1, the default model of Jomoq Pro: one name in the picker, with the lane visible per turn for transparency. The benchmark harness, task set, and the gate thresholds this architecture had to clear before implementation are part of the repository, and every number we publish going forward is generated from a benchmark run.