Esc to close · ⌘K / Ctrl-K opens search anywhere
The console Logs tab is a request & trace explorer — one row per request, newest first. It answers “what did this call do, how long did it take, what did it cost, and can I correlate it end-to-end?” without ever weakening BharatRouter’szero-retention default.
Two layers, two postures. Metadata (model, provider, status, latency, tokens, ₹ cost, residency, cached/BYOK flags, trace id) is recorded for every request and always browsable. Request/response bodies are notstored unless your org explicitly turns on content logging.
Filter by model, status (OK 2xx / errors) and atime window (24 h / 7 / 30 / 90 days), or paste a trace id to pin a single request. Members see their own keys’ traffic; owners/admins (or holders ofusage:org:view) see the whole org. Click any row to expand its trace details.
The same rows are available as JSON — the console reads exactly this endpoint:
GET /me/activity/events?from=2026-08-01&to=2026-08-03&model=llama-3.1-8b-instruct&status=error&limit=50
→ { "events": [
{ "id": 91242, "at": "2026-08-03T08:14:22Z",
"model": "llama-3.1-8b-instruct", "provider": "krutrim",
"status": 200, "latency_ms": 612,
"prompt_tokens": 180, "completion_tokens": 74, "total_tokens": 254,
"cache_read_tokens": 0, "cost_inr": 0.019, "byok": false, "stream": true,
"residency": "india", "agent_id": null,
"trace_id": "4f1c8e2a9b7d6c5f0e3a2b1c9d8e7f60", "key_name": "prod" }
],
"next_before": 91191 }Filters: status=ok|error, model=,key_id=, workspace_id=, trace_id= (32 lowercase hex), plus thefrom/to IST date range. Paginate with before=<last id>(the response’s next_before).
Every request carries a W3C Trace Context id. An inbound traceparentheader continues the caller’s trace; otherwise the gateway mints a fresh root. That id is threaded onto the usage row (above) and, when an OTLP endpoint is configured, exported asmetadata-only spans — route, model, provider, residency, status, latency, failover reason, never prompt or response content. So tracing is safe by construction and needs no per-org switch. The full OTel waterfall / span-tree UI is a follow-up; today the console surfaces the trace id for correlation in your own collector.
Because inference is zero-retention, bodies are only inspectable when an owner/admin turns on the content-logging tier — a deliberate, bounded, audited departure from the default (see the toggle at the top of the Logs tab, orPUT /me/org/content-logging). When on, request/response pairs land in aphysically separate store, stamped with an expiry, and are hard-deleted once the retention window lapses.
The drill-in fetches a stored body by trace id — owner/admin only:
GET /me/logs/content?trace_id=4f1c8e2a9b7d6c5f0e3a2b1c9d8e7f60
// content logging OFF (the default) — NOT an error:
→ { "content_logging": false, "fleet_enabled": true, "reason": "opt_out" }
// content logging ON, body found:
→ { "content_logging": true, "found": true,
"entry": { "trace_id": "...", "model": "...", "status": 200,
"request_body": { ... }, "response_body": { ... },
"created_at": "...", "expires_at": "..." } }With content logging off, the console shows a clear affordance to enable it — not a failure. A member (non-manager) never sees bodies.