Measured Evidence

2026-09-01: warm agent service path on Windows

These measurements used qwen3-8-flash-next through RunInfra with a reused warm agent service. The binary revision, hardware, exact prompt, and repository were not recorded.

Source: DAILY-USE.md lines 754-768.

The 2026-09-01 record attributes 83 percent of the one-line task to model time.

2026-08-31: Client-side speed observations on Windows

The dated rows below are from 2026-08-31 in the client-side comparison, while the qwen3-8-flash-next row separately states 2026-09-01. The 2026-08-31 rows used RunInfra, nemotron-3-5-lightning-30b, the owner's Windows machine, and headless create-file tasks. Their binary revision and hardware details were not recorded. Rows without an explicit date are labelled undated.

Source: SHIP-REPORT.md lines 292-311 and its latency record (SHIP-REPORT.md lines 342-368).

Undated: model-battery overhead

Undated record. Source: DAILY-USE.md lines 88-103, under "Speed vs correctness".

The Windows battery compared nemotron-3-5-lightning-30b and deepseek-v4-flash through RunInfra on the same binary, battery and day. It reported 392 to 448 ms of coding agent overhead, separately from model time.

This is not a current battery result or a timing of the agent page's illustrated dark-mode task. The record does not specify the binary revision, service state, hardware, or historical task shapes for this comparison. Nemotron passed 2 of 5 correctness checks and lost trailing newlines; Deepseek passed 5 of 5. The overhead range is not a correctness guarantee and is separate from the one-line bug-fix observation above.

Undated: warm agent service reuse overhead

Source: the "client process reuse" comments in config/rightnow.toml lines 69-79.

Date: not recorded. Provider: RunInfra. Model: not recorded. Build: not recorded. Platform and machine: not recorded. Workload: a headless create-file task with a reused warm agent service. The roughly 1,100 ms comparison used the same workload without the service, and its individual baseline samples were not given. These are reported samples, not a fresh benchmark or an attributed comparison with another agent.

Here overhead means client_total minus server_turn, not just session-open time. Do not combine these samples with the separate 392 to 448 ms model battery or promise this reduction on every task.

Undated: two-call edit prompt

Source: the "round trips" comments in config/rightnow.toml lines 81-87.

A traced one-file edit sent 18,952 prompt tokens on one call and 19,501 on the next, totalling 38,453 prompt tokens across both calls. The second prompt was 549 tokens larger; 549 is not the full size of the second request.

Date: not recorded. Provider: not recorded. Model: not recorded. Build: not recorded. Platform and machine: not recorded. Workload: a one-file edit; the exact edit task is not recorded. Cache use and a before/after latency comparison were also not recorded. The trace motivates avoiding a narration-only round trip when an objective postcondition verifies a bounded edit. It does not establish a token, latency or billing saving for every edit.

2026-09-02: Cerebras write/read observation

Source: the 2026-09-02 night merge record (DAILY-USE.md lines 105-112) and DAILY-USE.md lines 187-200.

The task was to write a file and read it back using gpt-oss-120b through Cerebras, with three model calls per run. The exact measurement time, binary revision, platform, and hardware are not stated for this table.

With a reused warm agent service, the record reports 1.15 seconds of server-turn time and 2.21 seconds of client wall time. When the service started, those values were 1.46 seconds and 3.30 seconds. The embedded cold run reported 5.96 seconds of server-turn time, including 3.7 seconds of teardown, and 13.3 seconds client wall time.

The record's "one-second turn" is server-turn time, not one-second end-to-end task completion. Its 17 ms post-turn gap is also not the entire client overhead. This is a historical small-task observation, not a guarantee for every provider call or edit.

Conflicting dates: 21:32 UTC project-build record

Sources: DAILY-USE.md lines 722-748 and config/rightnow.toml lines 171-197.

Date: sources conflict between 2026-09-01 and 2026-09-02. Provider: RunInfra. Model: not recorded. Build: not recorded. Platform and machine: not recorded. Workload: a project build; the exact project and prompt are not recorded.

The turn recorded 120,019 ms wall time and 96,873 ms of model time across 12 calls. The then-current 120-second limit stopped it while writing pyproject.toml, and the run did not claim success.

The shipped configuration now uses a 600-second time budget, 24 base model calls, and a 5,000,000-microcent spend guard (1 microcent = one millionth of a cent). The same historical run used five orientation calls and about 10 seconds of stream before its first action. The shipped configuration now enables a bounded turn-1 workspace map, but no post-change speedup is claimed from that run.

2026-09-02: other Windows observations

Source: DAILY-USE.md lines 655-679 and lines 703-720.

These tests used RunInfra. The model, binary revision, and hardware were not recorded unless an item says otherwise.

• A coding agent echo hi command measured 309 ms end to end, with about 250 ms attributed to the post-exit quiet period.
• The A/B used four task shapes with three runs each in both variants, alternating A/B per shape; each variant had its own product home and warm agent service. The 12 enabled-variant turns recorded zero speculative tool calls.
• The perception-path variant wrote an acknowledgement into one-shot stdout.
• Two of three enabled-variant edit turns returned exit code 22 even though the logged read succeeded and the edit reached disk. All three control edit turns returned exit code 0.
• With remote_fetch = false and --no-wait-for-background on the same small project, a cold run with a newly started service measured 6,964 ms end to end and 4,621 ms of model time; a reused-service run measured 5,860 ms end to end and 4,758 ms of model time.