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 harnesses 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 harness, 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. That’s all metadata. To read the messages themselves, turn on request logs for the harness. Open a request, pick an attempt, and its Messages tab shows the body sent to the provider and the body that came back.
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 harness 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 harness’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.
Configure a provider on the Limits page: Resend, Mailgun, or SendGrid. Enter the API key, domain, and notification address, then save. You can set the same thing with the EMAIL_* environment variables.Without an email provider, alerts are skipped. Blocking rules still work, since they don’t need to send anything.

​
Reading usage from your own code

A harness can query its own numbers with its 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.