Where to look
- Weave app — the Router report under AI reports, alongside the rest of your engineering data, with the standard team, engineer, and date filters.
- router.workweave.ai/dashboard — the same charts for teams that only use the router.
router_cost metric through the Weave MCP server, with the same user → session → model-pair hierarchy in drill-down mode.
If your team wants the underlying rows rather than charts, the analytics export streams every routing decision, unaggregated, into your own warehouse.
How savings are calculated
For each request, Weave prices the same tokens twice: once on the anchor model your agent requested, and once on the model that actually served the turn. The difference is the saving — positive when routing was cheaper, negative when the router deliberately upgraded the turn. One adjustment applies when the router switches models: cache writes caused only by the switch are priced as cache reads on the requested model, since staying put would have kept its prompt cache warm.Savings are measured against your own anchor model, not against another vendor or tool. A chart showing savings answers “how much cheaper than running everything on the model I asked for”, not “how Weave compares to another product”.
- It is a same-token comparison. It does not capture a cheaper model needing more turns to finish a task.
- Turns served on a subscription cost you nothing extra, so they show as no spend rather than as savings.
Tracing a single session
/router-sessionin Claude Code prints the session ID that correlates the session in Weave’s telemetry — include it when you report a routing problem.- For request-by-request rows, filter the analytics export on
session_id. There is no local decision log on the machine. /router-feedback <text>(/rf) sends feedback about a routing decision straight to Weave, attached to that session.
Reading a session’s cost from the API
Claude Code’s owntotal_cost_usd is a client-side estimate: it prices the response against Claude Code’s local table, so it cannot account for the model the router actually picked, a provider fallback, or Weave’s pricing. To get the real number, ask Weave:
$SESSION_ID is the session ID your client already has — the one Claude Code sends as X-Claude-Code-Session-Id and reports in its result. Any Weave public API key works; the key establishes which organization’s sessions you can read, so a session ID alone never exposes another organization’s spend.
The response gives the actual cost in USD micros, alongside what the same work would have cost on the model you originally requested:
request_count can exceed the number of requests you sent.
The response is a point in time. It covers everything committed when the query ran, so call it after your session has stopped issuing work if you need a final total. Telemetry is written asynchronously, so a session that just ended may briefly return
404 — retry if you expect data.Freshness
Spend and savings in the Weave app, the router dashboard, the analytics export, and therouter_cost metric — anything that flows through the reporting pipeline — normally land within about an hour of the request.
The /router/sessions/{session_id}/cost public API endpoint reads the primary router database directly, so it is current beyond the hour-long reporting pipeline: it returns everything committed by the time the query ran. There is no ClickHouse rollup, no denorm table, and no holdback. The latency budget is just “each indexed aggregate hit the primary Postgres”, typically tens of milliseconds.