ah-1cx.8 [bug] cost_usd is 0 for every live run — pi prices from its own registry, the litellm provider has none Lined Up

Split out of ah-tqc's second finding so that bead can close on its first finding.

/api/v1/status reports cost_usd=0 for ALL runs on agent-1, including real multi-minute ones (observed on tasks 1-2 during the 2026-07-19 Q&A smoke). The run row's CostUSD comes from ParseEvents summing message.usage.cost.total over assistant message_end events.

RULED OUT: the parser. A real pi 0.82.1 capture against the DIRECT deepseek provider (deepseek/deepseek-v4-flash) puts cost.total exactly where ParseEvents reads it, and the summation is arithmetically correct (proven per-message, not cumulative — see ah-1cx.4).

LEADING HYPOTHESIS: pi computes cost itself from a per-provider model pricing registry. agent-1 runs every role through a CUSTOM OpenAI-compatible provider named 'litellm' (role models are 'litellm/<model>'), and a custom provider carries no pricing metadata, so pi emits cost{input:0,output:0,total:0} while token counts are still real. If that holds, nothing in agent-hub is broken and the fix is to stop trusting pi for cost: either derive it from token counts against a locally configured price table, or read spend from the LiteLLM proxy (it tracks per-key spend), or drop the field from the status API rather than reporting a confident zero.

Settle the hypothesis BEFORE writing code. Needed evidence, from agent-1 (the local ssh probe is blocked by the permission classifier — needs an operator '!' handoff):

1. A real events.jsonl from a completed run: jq -c 'select(.type=="message_end" and .message.role=="assistant") | .message.usage' over the archived stream. Are totalTokens non-zero while every cost.* is 0? That confirms the hypothesis outright.
2. The pi provider config on the box (how the 'litellm' provider is declared) — does pi's config format accept per-model pricing for a custom provider? If it does, the cheapest fix is config-only, on the box, with no code change at all.

Only if both come back negative does this become a parser/shape bug.

Either (a) pi is configured/patched so cost.total is real for the litellm provider and a live run reports a non-zero cost_usd, or (b) cost is sourced from somewhere trustworthy, or (c) the field is explicitly documented+surfaced as unavailable rather than a silent 0. In all three cases SPEC and the status API description must match what is actually reported.

OPERATOR HANDOFF — the ssh probe from this dev session is blocked by the local permission classifier, so these need a '!' handoff or a human at a terminal. Run on agent-1 (or via ssh from the mac):

1. Find a completed run's event stream and look at what pi actually reported:
   ssh agent-1.lab.internal
   sudo -u agenthub bash -lc 'ls -t /opt/agent-hub/work/*/task-*/.task/events.jsonl 2>/dev/null | head -3'
   sudo -u agenthub bash -lc 'jq -c "select(.type==\"message_end\" and .message.role==\"assistant\") | .message.usage" <PATH>'
   The decisive question: are input/output/totalTokens NON-ZERO while every cost.* is 0? That confirms the hypothesis outright — pi is reporting real token counts and no price, i.e. it has no pricing metadata for the custom 'litellm' provider.
   (If the worktrees are already pruned, the archive lane keeps tarballs — check archive_dir, default <work_root>/archive, for task-<id>.tar.gz.)

2. Look at how the litellm provider is declared in pi's config on the box:
   sudo -u agenthub bash -lc 'ls ~/.pi; grep -rn litellm ~/.pi 2>/dev/null | head'
   Does pi's config format accept per-model pricing for a custom provider? If it does, the cheapest fix is CONFIG-ONLY, on the box, with no code change in agents-dev at all — and this bead closes as 'not our bug, fixed in pi config'.

3. Cross-check what LiteLLM itself thinks the spend was, since it tracks per-virtual-key spend. If pi cannot be taught the prices, LiteLLM is the trustworthy source and the fix becomes 'read cost from LiteLLM, not from the event stream'.

Only if step 1 comes back with cost fields that are populated-but-mis-shaped does this become a parser bug — and in that case capture the events.jsonl and add it as a testdata fixture, the way ah-1cx.4 did for the 0.82.1 shape.

For reference, a REAL pi 0.82.1 capture against the DIRECT deepseek provider (local mac, 2026-08-05) has cost exactly where ParseEvents reads it: message.usage.cost = {input, output, cacheRead, cacheWrite, total}, all non-zero, and the arithmetic checks out against flat per-Mtok rates. So the parser is not the problem on a provider pi has prices for.