Observability records a trace of every request: how long it took, what it cost, which model and provider served it, and which pipeline stages ran. Each stage is its own timed span, so a trace is a true breakdown of where the time went. Recording happens after the response, so it never adds latency.
trace · spans · metrics
A request runs through guard, memory, retrieval, the firewall, routing, and the model, and all you see is one number at the end. Was it the retrieval step, the firewall, or the model itself? Without a per-stage breakdown you cannot tell, so you cannot fix the slow part or the expensive one with any confidence.
Turn it on and every request is recorded from the next call. Recording runs on a background queue, so it never slows the response your user is waiting on.
Traces are written on a background queue after the response is sent. If recording ever fails, your request is unaffected. Observability is read-only over your traffic.
Spans record stage names, timings, and status, never your prompts, completions, or the content of retrieved context. The trace shows shape, not data.
One billable event per recorded trace, and reading traces and dashboards is always free. Sample a fraction of traffic to control volume on high-throughput tenants.
Some tracing slows every request, leaks sensitive content into a third-party tool, or bills you to look at your own data. This does none of those.
Create a key, enable Observability, and see every request broken down stage by stage from the next call.
We use privacy-friendly, EU-hosted analytics to understand how Akumi is used. Accept analytics cookies, or continue without them. See our cookie policy.
