Inspect routing decisions — which provider served your request, why, and at what cost.
Not yet available. Router metadata is on the roadmap.
When OpenDunes routes a request to a model, it makes decisions you can't see: which backend provider was selected, whether a fallback occurred, what the raw latency was. Router metadata surfaces those decisions in the response so you can observe, debug, and optimize your routing configuration.
Router metadata is returned in the response body under x_opendunes.routing:
| Field | Type | Description |
|---|---|---|
provider | string | The backend provider that served the request |
region | string | Infrastructure region used |
latency_ms | integer | Time from request received to first token (or full response) in milliseconds |
fallback | boolean | Whether the primary provider was unavailable and a fallback was used |
attempt | integer | Which attempt number served this response (1 = first try) |
cost_da | string | Total cost of this request in DA (same as billed) |
When a fallback occurs, the routing object includes additional context about what failed:
fallback_reason mirrors the error code that triggered the fallback — one of upstream_timeout, upstream_error, temporary_unavailable, or no_provider.
By default, a summary routing object is always included. You can request a more verbose payload with per-attempt breakdowns:
The verbose payload includes a attempts array showing the result of each routing attempt, useful when debugging retry behaviour.
If you log responses, include x_opendunes.routing.provider and x_opendunes.routing.latency_ms in your structured log output. Over time this lets you:
Router metadata is also recorded in your activity log — you don't have to capture it yourself if you just want visibility without log infrastructure.
The cost_da field in metadata is the actual billed amount for that request. It will match the ledger entry for the same request ID (X-Request-Id header). Use it to reconcile your own cost tracking against your OpenDunes balance.