Skip to main content
Every request through the gateway is recorded: which model served it, what it cost, how long it took, and what failed. The dashboard is built on that record, and you can query the same numbers from your own code.

​
Requests and provider attempts

Manifest tracks two things, and the difference matters once fallback is involved: A request that succeeds on the first try is one Request with one attempt. A request that fails twice before succeeding is still one Request, with three attempts. A request Manifest blocked itself, like a hard limit or a malformed body, is one Request with zero attempts, since no provider was ever called. This is why the request count and the provider call count don’t match, and why cost is attributed to attempts: a failed attempt can still burn tokens.

​
The dashboard

Overview

Spend, tokens, and request volume over time, across all agents or one. Includes the provider and model mix.

Requests

The full log, newest first. Filter it, then open any row for the request body, every provider attempt, and the routing decision.

Providers

Per-provider usage, spend, and error rates. Useful for spotting one provider degrading.

Limits

Threshold rules per agent, plus email provider setup.

​
What’s on each request

Opening a request in the log shows the whole story: the tier that routed it, the model and provider that served it, input and output tokens, computed cost, latency, the auth type used (API key, subscription, or local), and every fallback hop with its own status. Failures carry an error code, so a Manifest rejection like M100 reads differently from a provider’s own 500.
Local models record cost = 0 with real token counts and latency, since nothing was billed. Custom providers do the same, because Manifest can’t infer pricing for a model it doesn’t know.

​
Spend alerts

A limit rule watches one metric for one agent over a rolling period, and acts when the threshold is crossed. Blocking is the gateway half of this and is covered in hard limits. The rest of this section is the alerting half.
1

Open the Limits page

Navigate to your agent’s Limits page in the dashboard.
2

Create a rule

Click + Create rule.
3

Configure it

Pick the metric, threshold, period, and whether it should notify, block, or both.
4

Save

The rule takes effect immediately.
Alerts are evaluated hourly, so an email can lag the threshold by up to an hour. Blocking is not: it’s checked on every request. Each rule emails once per period, so a rule that stays over its threshold won’t flood your inbox.

​
Email delivery

Alerts go to your account email. Check it’s current in your profile settings.

​
Reading usage from your own code

Agents can query their own numbers with their mnfst_ key, which is useful for showing a budget in your own UI or stopping work before a limit blocks you.
Self-hosted installs swap the base URL for their own host.

​
Anonymous telemetry

Separately from your dashboard, each self-hosted install sends a small daily report so the project can see version adoption and which providers deserve attention. It’s aggregates only, never prompts or content, and one environment variable turns it off. Full field list and opt-out: Data and telemetry.