LLM quotas
An agent can call an LLM far more often than a single query does: once for
its own reasoning steps, again for any tool that overrides the LLM it
runs on, again during compaction and memory extraction, and again for any
enrichment tool that itself calls an LLM. llm_quota puts a ceiling on that
total spend so one agent cannot exhaust a shared LLM's capacity or run up
an unbounded bill.
What a quota limits
llm_quota accepts seven optional integer fields, each enforced
independently of the others.
| Field | Counts | Window |
|---|---|---|
requests_per_second | LLM requests the agent makes (1-10000). | Per second |
input_tokens_per_minute | Input (prompt) tokens, as reported by the provider, including cached prompt tokens. | Per minute |
output_tokens_per_minute | Output tokens (completion plus reasoning). | Per minute |
input_tokens_per_day | Input tokens. | Per UTC calendar day |
output_tokens_per_day | Output tokens. | Per UTC calendar day |
input_tokens_per_month | Input tokens. | Per UTC calendar month |
output_tokens_per_month | Output tokens. | Per UTC calendar month |
An omitted field applies no limit for that field. Every token field must be at least 1. Day and month windows reset on UTC boundaries, not the agent's local timezone.
Output tokens are defined the same way wherever a session reports them.
session_context_usage.output_tokens.count, on the context_consumed event
and on the agent session, includes reasoning tokens. Its reasoning_tokens
is a subset of count, not an addition to it.
This mirrors the per-LLM request and token limits you can set on an LLM configuration itself, but the two are independent and serve different purposes: an LLM's quota bounds that LLM's total capacity across every caller, while an agent's quota bounds what one agent spends regardless of which LLMs it calls.