Two settings on this page protect you from runaway costs and provider outages: a fallback model for when the primary fails, and per-agent token caps that hard-stop usage once thresholds are hit.
Find these settings under Settings → Performance on any agent.
Fallback model
Choose a second model the agent should switch to if the primary fails — for example a cheaper or faster option from another provider.
The fallback kicks in when:
- The primary model returns an error or rate-limits.
- The provider is temporarily unavailable.
The retry runs once. If both models fail, the customer sees an error. Token usage and the recorded Message.model reflect the model that actually answered, so analytics stay accurate.
Token monitoring
Turn on Enable Token Monitoring to put hard caps on per-agent token usage. Two windows are independently configurable:
- Daily token limit — resets at 00:00 UTC. Leave empty for no daily cap.
- Monthly token limit — resets on the 1st of the month at 00:00 UTC. Leave empty for no monthly cap.
Usage is summed from completed messages on this agent. When a cap is reached, the next request is refused with an HTTP 429 status — the customer sees a rate-limit response, and you get clear telemetry that a cap fired rather than a silent failure.
How limits compare
Two layers of usage protection apply in order:
- Plan limits (team-wide) — your subscription's monthly message and API quotas. Enforced first.
- Agent token caps (per-agent) — only fire if the plan check passed. These let you stop one chatty agent from consuming the team's whole budget.
Reading usage
Usage is tracked on every message via input/output/total token counts. You can query usage directly from the Messages table, or open the agent's analytics view to see daily totals broken down by model.