Resolve an agent's token guardrails and effective model
Resolve which model the agent’s next turn should run on given its token-denominated guardrails — a per-conversation token budget, a daily token cap, and a progressive model-downgrade ladder. The ladder steps the agent down to cheaper models as its daily token usage (summed over the current UTC day) crosses each configured utilization threshold. A reason of no_downgrade_step means a threshold was crossed but the matched rung names the primary model (nothing useful to step to), so the model stays put. The agent runtime reads this before every chat turn; authenticated with an internal service token.
Authorizations
Dashboard JWT token from Clerk
Headers
Sandbox opt-in for Clerk-session-authenticated requests. Set to true to route the call through the test-mode pipeline: no real provider delivery, no credits deducted, response meta.test_mode: true. Ignored for live API keys (dv_live_sk_*) — server-to-server clients must use a test-prefixed key (dv_test_sk_*) to exercise sandbox. Test-prefixed keys unconditionally enable sandbox regardless of this header.
true, false Path Parameters
Identifier of the agent whose token guardrails to resolve.