P1: cost_micro_usd is never measured — dispatch logs hardcoded tokens, landControlFlight hardcodes 0, run cost = SUM(0)

[servathadi]

Summary

cost_micro_usd on the routine/flight path is never measured. Every flight — landed, held, or stuck — reads 0 because nothing anywhere writes a real cost. This has been misread as "stuck flights have cost 0"; the truth is that a successfully landed flight also has cost 0, and always will.

Verified 2026-08-10 against origin/main @ 36a0cdf, prompted by flight c4579364, which landed cleanly (status: landed, score: 1, 468s of real work, proposal accepted) with cost_micro_usd: 0 against a budget_micro_usd of 50000.

The chain, in order

1. Dispatch logs fabricated token counts, before any work happens.
src/routines/dispatch.ts:590-596:

await logSubagentTokenUsage(env.DB, {
  subagentId: selected.agentId,
  parentAgentId: 'mupot-routines',
  modelSubstrate: selected.agentId.includes('river') ? 'claude-sonnet-4.6' : 'deepseek-v4-flash',
  promptTokens: 1250,
  completionTokens: 380,
  taskId: task.id,
})

1250 / 380 are constants. This runs at dispatch time — before the agent has executed anything — so they cannot be measurements of the work. modelSubstrate is inferred by substring-matching 'river' in the agent id, so every non-river seat is recorded as deepseek-v4-flash regardless of what actually ran.

2. That telemetry has no cost column anyway.
subagent_token_usage stores prompt_tokens / completion_tokens only (src/telemetry/subagent-usage.ts:55-56). No cost, no price table, no join to one.

3. The governed landing hardcodes zero.
src/routines/actions.ts:835-841, landControlFlight:

const landed = await landGovernedFlight(env, flight.id, {
  cost_micro_usd: 0,
  score: 1,
  …
})

No TODO, no comment. score: 1 is also unconditional — every governed flight lands with a perfect score by construction.

4. The run derives its cost from the flight, closing the loop with no input.
src/routines/actions.ts:1044-1050:

cost_micro_usd = (
  SELECT COALESCE(SUM(f.cost_micro_usd), 0) FROM flights f
   WHERE f.tenant = routine_runs.tenant AND (f.id = routine_runs.flight_id OR f.id IN (…))
)

So run.cost = SUM(flight.cost) = SUM(0) = 0. The run reads its cost from the flight; the flight's cost is a literal zero. There is no input to this loop.

A real meter exists — it is just not connected to this path

recordTokens (src/agents/meter.ts:217-239) does accumulate cost_micro_usd into execution_meter, and src/agents/execute.ts:453 writes a real cost onto tasks. So the agent-execute path has metering. The routine-control path does not use it.

Why this matters beyond a wrong number

• budget_micro_usd is enforced at dispatch but never debited. A budget that is never spent against is not a budget.
• Every "cost 0" flight on the board has been read as evidence of a stall. It is not evidence of anything. That misreading cost real debugging time this week.
• score: 1 unconditional means flight score carries no signal on the governed path either.

What would close this

landControlFlight must receive a measured cost rather than a constant — sourced from execution_meter / recordTokens for the assigned agent over the run's window, or from real usage reported by the runtime that executed the goal. That requires the runtime to report actual token usage, which today it does not: step 1 is a placeholder, not a feed.

Until then, no flight can honestly satisfy a "lands with cost_micro_usd > 0" acceptance criterion, and any non-zero value written there would be fabricated. Flagging that explicitly because that exact criterion is currently on the F-03 / flight-execution goal.

Related: #874 (receipt), #895 (executor install blocked), #894 (situation_digest exposure).

[servathadi]

Stronger evidence — the fabrication is not inert, it is displayed

Two additions after further tracing, both making this worse than filed.

1. recordTokens has zero callers — it is dead code.

src/agents/meter.ts:217-239 is the only function that accumulates real cost_micro_usd (into execution_meter). Nothing in src/ calls it:

$ grep -rn "recordTokens(" src --include=*.ts | grep -v "export async function"
(no results)

So execution_meter.cost_micro_usd is never written either. My original report said cost is "not connected to the routine path" and implied the meter was live elsewhere. It is not live anywhere. There is no cost measurement in the system at all — only a function that would do it if something called it.

2. The hardcoded token counts are surfaced to humans as real telemetry.

src/dashboard/motherboard.ts:160-161 aggregates subagent_token_usage:

promptTokens: Number(usageRes.total_prompt || 0),
completionTokens: Number(usageRes.total_comp || 0),

and renders it at :886 as "{prompt} in / {completion} out ({n} records)".

That table's only writer on the routine path is dispatch.ts:590-596, which inserts the constants promptTokens: 1250, completionTokens: 380 at dispatch time. So the motherboard's token meter is displaying 1250 × n / 380 × n — a linear function of dispatch count, presented as measured usage. Anyone reading that dashboard is reading fabricated numbers with no marker saying so.

Consequence for acceptance criteria: any goal that requires a flight to land with cost_micro_usd > 0 is currently unsatisfiable without first building cost capture end to end — runtime usage reporting, a price model, persistence, and a read at landing time. That is a subsystem, not a patch. Writing a non-zero value without it would be fabricating financial data, and given (2), it would also flow straight onto a dashboard as though measured.

Minimum honest first step, independent of the rest: delete the fabricated logSubagentTokenUsage call at dispatch.ts:590-596. Recording nothing is strictly better than recording constants that a dashboard presents as measurements.

[servathadi]

CORRECTION — the measurement exists. I was wrong to call this a missing subsystem.

I filed this saying cost capture "does not exist" and that satisfying cost_micro_usd > 0 needs a subsystem built from scratch. That was wrong, and the correction narrows the work by a lot.

The runtime already reports real usage. The harness was discarding it.

Verified by running prime-agent -p --mode json and reading the stream. Every turn_end / message_end / agent_end frame carries it, nested inside the message object:

{"type":"turn_end","message":{ … ,"model":"deepseek-v4-flash","provider":"opencode-go",
 "usage":{"input":6733,"output":11,"cacheRead":0,"cacheWrite":0}}}

So the true model name and real token counts are available at the point of execution. dispatch.ts:590-596 is not filling a gap where no data exists — it is inserting 1250/380 and a substring-guessed modelSubstrate while the runtime is reporting 6733/11 and deepseek-v4-flash a few seconds later.

Captured as of now. prime-responder.py parses usage off the stream and appends one record per reply to ~/.fleet/<agent>/usage.jsonl:

{"ts":"…","agent":"…","agent_id":"…","seq":…,"message_id":"…","from_agent":"…",
 "model":"deepseek-v4-flash","provider":"opencode-go",
 "input":6733,"output":11,"cache_read":0,"cache_write":0}

When the runtime reports nothing, it logs usage UNREPORTED … recording nothing rather than a guess and writes no record. Deliberate: a missing measurement must never become a fabricated one, which is the defect this issue exists for.

Mutation-checked: strip the usage frames → None; non-JSON stream → None. My first parser read d["usage"] at the frame's top level and silently captured nothing while looking correct — same shape as the bug this whole issue is about, caught only by testing against a real stream instead of a remembered one.

Live on all five responders (river, athena, loom, mubot, asha).

What is actually left

Three hops, not a subsystem:

1. A price model — tokens → micro-USD per model. None exists in the repo.
2. An ingest path — mupot has no endpoint to receive per-run measured usage. Note usage is only known after the subprocess exits, which is after routine_proposal_submit has already auto-landed the flight via landControlFlight — so this has to be a post-hoc accounting write, not a value carried on the proposal.
3. landControlFlight stops hardcoding 0 (actions.ts:836) and reads the recorded value. Its unconditional score: 1 deserves the same treatment.

Also still true and unchanged: recordTokens (meter.ts:217) has zero callers, and motherboard.ts:160 renders the fabricated constants as measured usage.

Standing recommendation unchanged: delete the fabricated logSubagentTokenUsage call at dispatch.ts:590-596. Now that real usage is being captured one layer down, keeping the constants means two sources disagreeing, with the fake one wired to the dashboard.

[servathadi]

Ready-to-build design — and the rate is repo-sourced, not invented

Retracting one more thing I said: that this needs a pricing input from Hadi. It does not. The rate is already recorded in this repo.

Rate source. Commit cd9be86: feat(fleet): retire tech-grok and replace with Asha Tech Worker (DeepSeek v4 @ $0.24/M tokens). That is the team's own figure for the model our routine agents actually run, recorded in the change that provisioned the agent. There is also existing precedent for pricing in src/dashboard/economy.ts, which prices real spend at Anthropic list rates (Opus $15/$75 per MTok) and already carries the right shape: usd_micro, input_tokens, output_tokens, cache_write_tokens, cache_read_tokens.

Caveat to carry into the implementation: $0.24/M is a single blended figure, not split input/output. Every other rate in economy.ts is split. Either confirm the split or record explicitly in the price table that deepseek is blended — do not silently apply a blended rate through a split-rate code path.

The three hops, concretely

1. Price table. New src/economy/prices.ts — model -> {input_micro_usd_per_mtok, output_micro_usd_per_mtok, cache_read?, cache_write?}. Seed with deepseek-v4-flash from cd9be86 and the Opus/Sonnet rates already hardcoded in economy.ts:248. Unknown model => return null, never a default. A guessed price is the same failure class as a guessed token count.

2. Ingest. mupot has no way to receive per-run measured usage. Note the ordering constraint, which shapes the API: usage is only known after the runtime subprocess exits, which is after routine_proposal_submit has already auto-landed the flight via landControlFlight. So this must be a post-hoc accounting write, not a field on the proposal. Suggested: report_run_usage { run_id, model, input, output, cache_read, cache_write }, min: member, scoped so only the run's assigned_agent_id may write, idempotent per (run_id, attempt).

3. Apply. actions.ts:836 stops hardcoding cost_micro_usd: 0 and reads the priced total. Its unconditional score: 1 should get the same scrutiny in the same PR — an unconditional perfect score carries no signal either.

Producer side is already done

prime-responder.py now captures the real measurement on all five responders and appends it to ~/.fleet/<agent>/usage.jsonl:

{"model":"deepseek-v4-flash","provider":"opencode-go","input":6733,"output":11,"cache_read":0,"cache_write":0}

with usage UNREPORTED … recording nothing rather than a guess when the runtime reports nothing. So hop 2 has a real producer waiting for it.

Do this first, regardless

Delete the fabricated logSubagentTokenUsage call at dispatch.ts:590-596. It writes 1250/380 and a substring-guessed model name, motherboard.ts:160 renders those as measured usage, and there is now a real measurement one layer down that disagrees with it. Two sources, one fake, and the fake one is the one on the dashboard.

[servathadi]

CORRECTION — I published a false claim in this issue. Retracting it.

Caught by Athena gating #898. Three times in this thread I wrote that recordTokens has zero callers and is dead code. That is wrong.

src/agents/meter.ts recordTokens() is live-called from src/agents/execute.ts:290 and :301 via recordTokensSafe(meter.recordTokens, …), and it is covered by tests/execution-meter.test.ts.

My grep was grep -rn "recordTokens(" src | grep -v "export async function". That pattern cannot match a call site which passes the function as a value rather than invoking it by name. I got an empty result and reported it as proof of absence. Absence of a grep match is not absence of a caller, and I stated it as a finding rather than as what it was — one weak search.

What is actually true, and it is sufficient for everything else in this issue:

The routine flight path never reaches the meter. The agent-execute path does.

Everything else in this issue stands and was independently verified during the gate:

• dispatch.ts:590-596 logs constants 1250/380 before work runs, with modelSubstrate substring-guessed — unchanged
• actions.ts:836 hardcodes cost_micro_usd: 0 — unchanged
• actions.ts:1044 computes run cost as SUM(flight costs) — unchanged
• motherboard.ts:160 renders the fabricated constants as measured usage — unchanged
• the runtime emits real usage and the harness was discarding it — unchanged, and now captured

A second citation failure from the same review, same class: in prices.ts I sourced the claude-sonnet-4.6 rate to "as already used in src/dashboard/economy.ts". That file contains no rate map — only a footer string naming Opus $15/$75 at economy.ts:248. $3/$15 appears nowhere in the repo. The number is right; the citation was not traceable, which breaks that file's own stated rule that every rate cites its source. Now marked UNCORROBORATED so it gets challenged rather than inherited.

One more finding from the gate, recorded here because it outlives #898: landGovernedFlight bakes cost_micro_usd into the flight_event_outbox payload at landing time (flight/service.ts:313-321). Correcting flights and routine_runs post-hoc without touching that payload leaves the durable flight.landed event carrying 0 permanently. Fixed in #898, scoped to delivered_at IS NULL — already-delivered events are history and are not rewritten.

Leaving the wrong statements above in place rather than editing them out. A retraction that erases the error teaches nobody what the error looked like.

[servathadi]

Cost-proof run dcecc28d — FAILED, and the failure is the useful part

Ran the full loop end to end after #898 deployed (98af7173 @ d6b2df3). It did not produce a cost, and the reason is worth recording rather than retrying past.

Setup: routine 2aa73ee7, a deliberately tiny read-only goal I authored myself (read one file, list its keys, stop) — not arbitrary board text. Dispatched to asha with budget_micro_usd: 50000.

Result:

05:38:02  usage MEASURED model=deepseek-v4-flash in=0 out=0 cache_r=0
05:38:02  FAIL 582-2ecce7f5…json: routine execution: agent produced no reply text -> failed/ (NOT dropped)

input: 0 is impossible for a real completion. The prompt alone is input. So that frame is a stub the runtime emitted instead of doing the work — the provider call never produced a turn. Reproduced independently outside the responder with the exact same prompt: prime-agent emitted zero stdout lines in 120s, while a trivial prompt returns in seconds.

Not eviction: nothing was killed mid-run. It ran and returned nothing.

Intermittent, which is the actual finding. The same envelope shape succeeded at 03:43 today — run 01e36a62 / flight c4579364 executed, submitted a proposal, and landed with score: 1. Same agent, same model, same harness. One success, one silent no-op. A runtime that sometimes produces nothing and reports a zero-usage frame while doing it will surface as "flights mysteriously don't land", which is exactly the symptom this whole thread started from.

Per the goal's instruction — name it when you hit it, record it, do not retry into it — I have not retried.

Defect this exposed in my own capture, fixed

prime-responder.py logged usage MEASURED … in=0 out=0. It treated an all-zero frame as a measurement. Had the run otherwise succeeded, that would have written a confident 0 into the cost path — reintroducing the fabricated zero this entire issue exists to remove, from the code meant to fix it.

_usage() now returns None when input and output are both zero, so it logs usage UNREPORTED … recording nothing rather than a guess. Verified four cases, including that a trailing zero stub cannot erase a real measurement earlier in the stream.

State

Infrastructure is complete and verified live in production:

hop	status
measure	responder captures real {model, input, output, cache_*}, now rejects all-zero stubs
price	prices.ts — unknown model refused, every rate cited
ingest	report_run_usage deployed; assigned_agent_mismatch and model_not_priced both confirmed live
attribute	assigned agent only; operator principal refused
correct	flight + run + undelivered outbox payload, one batch

What is missing is a runtime that reliably produces output. cost_micro_usd > 0 will follow the first routine run that actually executes — the accounting path is no longer the blocker.

Flag removed; all five responders confirmed back to parking envelopes. The failed envelope is retained in failed/, not dropped.

[servathadi]

Two corrections, one of which undercuts #898

1. The runtime prices its own work. My price table is the fallback, not the source.

Ran the failing objective to completion (700s, 1042 frames). The usage frame carries cost, in USD:

"usage": {"input": 9406, "output": 1064, "totalTokens": 10470,
          "cost": {"input": 0.00065842, "output": 0.00014896,
                   "cacheRead": 0, "cacheWrite": 0, "total": 0.00080738}}

cost.total = 807 micro-USD, reported by the thing that actually made the call.

I built src/economy/prices.ts — and had Athena gate it — to derive a number the harness was already emitting. This is the same mistake shape as the token capture two hours earlier: the data existed one layer down and nobody looked. Third instance tonight of concluding "it doesn't exist" from not having found it.

The price table is not wasted, but its role is now inverted:

• Primary: runtime-reported cost.total. Cannot drift — it comes from the caller and reflects whatever rate actually applied.
• Fallback: prices.ts, for runtimes that report no cost (hermes has not been checked) and as a cross-check against a runtime reporting something implausible.

A local rate table goes stale the moment a provider changes pricing, and nothing tells you. A runtime-reported figure cannot.

prime-responder.py now captures cost_micro_usd from the frame. None — never 0 — when the runtime reports no cost, so "unpriced" stays distinguishable from "free". Verified against the real 1042-frame run: 807 µUSD; a no-cost runtime yields None; a cost.total: 0 stub yields None.

Follow-up for report_run_usage: it should accept an optional runtime-reported cost_micro_usd and prefer it over table pricing, falling back to priceUsage() only when absent. That is a small change to what #898 landed, and it should carry its own gate.

2. Retracting my "runtime produces nothing" claim

Earlier in this thread I wrote that prime-agent "emitted zero stdout lines in 120s" and concluded the runtime was silently failing. The sentence was true; the inference was not. The one successful run tonight took 468 seconds, so a 120-second observation proves nothing at all. I measured impatience and reported it as a defect.

What actually happens, now measured properly: the run does not converge. 1042 frames, timeout at 700s, and the assistant text it produces is the prompt echoed back rather than an answer. The model loops re-emitting the objective.

So the real failure is non-convergence on a substantive prompt, not silence — and it is still consistent with the responder's own observation of a clean ~3-minute exit with an all-zero usage frame and no text, which remains a separate and unexplained event.

Not retrying, per the standing instruction. Recording both the corrected finding and the fact that my first version of it was reasoning from too short a measurement.