Know what it cost, where it ran and how long it took
Every request writes a row: model, provider, tokens, cost, latency, attempts, cache outcome and your own tags. No prompt text, no completion text — the schema has nowhere to put them.
- 0
- prompt bodies stored
- OTLP
- export to your own tracing stack
- CSV
- export of any filtered view
- Per-request
- cost, tokens and latency
What it actually does
What each row holds
Model, provider, HTTP status, prompt and completion tokens, cost in micros, time to first token, total time, attempts, finish reason, and the routing trace of what was tried before it succeeded.
What no row holds
There is no column for prompt or completion text anywhere in the requests table, so there is no setting to get wrong and no retention window to trust. Cache entries are keyed by hash; the prompt is not recoverable from one.
Filter and facet
Narrow Activity by status, model, provider, API key or your own metadata tag, with counts beside each value so you can see where the traffic actually is.
Cost attribution
Spend rolls up by key, project, model and provider, and your request metadata is stored in its own column so a tag named after a customer or a feature can be summed.
Signed webhooks
Balance low, balance depleted, key spend limit reached, spend threshold crossed, credit added and request failed, POSTed with an HMAC signature and retried on failure.
OTLP traces
One span per gateway request to any endpoint that speaks OTLP/HTTP, with a sampling rate you set. Counts, ids, timings and money only — message content is never exported.
Fair questions
Do you store prompt bodies?
No. Not optionally, not by default, not for a retention window — the requests table has no column for message content. What we keep is metadata: model, provider, tokens, cost, timings and the tags you sent.
Can I get the data out?
Any filtered view of Activity exports to CSV, and an OTLP exporter streams a span per request to Datadog, Grafana Tempo, Honeycomb or anything else that accepts OTLP/HTTP.
Does the exporter slow my requests down?
No. It is called after the request row is written, fire-and-forget, with its own timeout. An exporter that is down or slow cannot affect a customer's response.
Works with the rest of the platform
Name a model, name the ones to try if it cannot be served, and set which providers you prefer. Multigrid retries transient failures on each provider and moves down the list when it runs out of attempts.
Add your own provider keys and Multigrid routes through them — your rates, your billing relationship. We charge nothing on that traffic and it does not touch your credit balance.
Six rule types, evaluated inside the request path. A client that forgets to call them still gets them, and a rule can run in warn mode against real traffic before it is allowed to refuse anything.
Bring your own provider keys and pay us nothing for that traffic
Requests served on your own key are not charged and do not touch your credit balance. You still get the routing, the logging and the cost record.