> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Router reporting

> Where to see routed models, spend, and savings, and how savings are calculated

Every routed request is recorded with the model that served it, its token counts, and its cost. You can see that data in two places.

## 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](https://router.workweave.ai/dashboard)** — the same charts for teams that only use the router.

Both show request volume, cost saved, model mix, spend by model, cumulative savings, savings rate, and a cost breakdown. Router-cost drilldown is nested as **user → session → requested/decision model pair**, so you can move from an identity's total to the sessions and routing decisions behind it. Router identities linked to the same Weave account are combined; otherwise recorded email or router identity is used.

Router cost is also exposed as the `router_cost` metric through the [Weave MCP server](/integrations/mcp), 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](/router/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.

<Note>
  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".
</Note>

Two caveats worth knowing:

* 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.

**Models & routing → Cost comparison model** sets the model the comparison chart reprices your usage against, if you want a baseline other than the default.

## Tracing a single session

* `/router-session` in 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](/router/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 own `total_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:

```bash theme={null}
curl -H "X-API-Key: $WEAVE_API_KEY" \
  https://app.workweave.ai/api/v1/router/sessions/$SESSION_ID/cost
```

`$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](/api-reference) 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:

```json theme={null}
{
  "session_id": "a2c7f8a4-6bcb-4c17-a0c1-e2c3d0877fc1",
  "request_count": 7,
  "actual_cost_usd_micros": 23418,
  "actual_cost_usd": 0.023418,
  "requested_cost_usd_micros": 81227,
  "requested_cost_usd": 0.081227,
  "input_tokens": 129844,
  "output_tokens": 4102,
  "cache_creation_tokens": 84211,
  "cache_read_tokens": 45633,
  "last_recorded_at": "2026-08-13T23:41:02.184Z"
}
```

The cost includes router-originated work your client never asked for, such as handover and compaction summaries, so `request_count` can exceed the number of requests you sent.

<Note>
  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.
</Note>

## Freshness

Spend and savings in the Weave app, the router dashboard, the analytics export, and the `router_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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.