How do I set spending limits for coding agents?

To set spending limits for coding agents, choose the scope to count, set warning and stop thresholds, and verify that an enforcement point can block new work. Combine agent-level controls with provider billing controls where available. An alert is not a stop, and recorded-cost gates may allow in-flight work to overshoot.

Last checked against Omnigent v0.19.0 · 2026-10-23

Which spending limits should I use for coding agents?

Choose coding-agent spending controls by scope: a run limit for one task, an agent policy for managed sessions, or provider controls for account-wide spending. A per-session allowance does not cap every session a developer opens. An elapsed-time or turn limit can bound activity, but it is not equivalent to a dollar limit when models and request sizes differ.

Provider controls cover a different boundary from agent controls. OpenAI documents both budget alerts and an optional enforced hard limit for organization or project spending. Alerts do not stop requests; enforcement can still lag and allow overshoot. These aggregate controls differ from a per-agent-run allowance. Check the configured mode rather than assuming the word “budget” means billing will stop.

For a single headless Claude Code run, --max-budget-usd is a native estimated-cost limit; --max-turns bounds turns instead. Both have narrower scope than account spending. A per-response output-token limit is narrower again: it does not count every request in an agent loop.

Omnigent’s contextual budget policies can pause or deny observed work at supported turn or tool-call gates, with session and cross-session user scopes. Compared with a single-run flag, they let you reuse spend rules across managed sessions; unlike provider controls, they cannot control unrelated clients using the same API key. For unattended work, verify both the usage data and the blocking behavior instead of relying on a dashboard number.

How do I cap coding-agent spending in Omnigent?

To cap a coding-agent session’s recorded spending in Omnigent, attach a cost_budget policy to the session, declare it in an agent specification, or use applicable administrator policies. Contextual policies let you structure limits per session or delegated subtree, apply user-wide daily or period budgets, and configure approval checkpoints or model-specific gates. Declaring a policy in an agent specification reuses it for that agent’s sessions; it does not create a single pooled allowance for every instance of the agent. This fragment requests a $5 session cap with $1 and $2.50 checkpoints; it belongs in an otherwise configured agent, not a standalone agent file.

policies:
  session_budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.0
      ask_thresholds_usd: [1.0, 2.5]
      expensive_models: []

In v0.19.0, both an omitted value and [] select an all-model stop. A non-empty expensive_models list instead matches model-ID substrings case-insensitively. A list containing “opus” gates matching models over budget while allowing unmatched models. That is a downgrade gate, not a total-spend cap; it does not automatically switch models.

How do Omnigent spending checkpoints and hard caps work?

An Omnigent session’s soft spending checkpoint returns ASK at the next supported gate; an all-model hard cap on the root session (the original conversation) returns DENY. Approval remembers the highest acknowledged checkpoint; declining blocks that attempt without acknowledging it. Approving $1 in this example allows progress toward $2.50, not beyond $5. The root cap covers the original session and its delegated agents.

Checks gate new user turns and tool calls using reported usage; they do not gate every internal model API call. An in-flight turn can overshoot before the next check. Denying a native tool call does not itself terminate the turn. If tokens lack catalog pricing, the policy asks whether to continue untracked; approving permits spend that cannot count toward warnings or the cap.

What spending does each Omnigent budget cover?

Omnigent child-agent budgets cover a delegated subtree, user budgets span sessions, and scheduled-task caps are requested per firing, with best-effort attachment in v0.19.0. A root-session budget counts the original conversation and all agents it delegates to, directly or indirectly, and is checked by descendants too. A separate subagent_cost_budget counts one child and that child’s descendants. Its all-model over-cap path returns ASK to lift that child cap. Approval does not lift an inherited root-session cap; a non-empty expensive_models list instead uses model-specific DENY behavior.

Use user_daily_cost_budget or user_period_cost_budget for spending across sessions. The daily policy uses a UTC day; the period policy supports configurable windows. A scheduled task’s max_cost_usd requests a cap for each firing, not one shared allowance. In v0.19.0, attachment is best-effort: a missing policy store or attachment error can leave a run without that cap. Verify the fired session’s policy.

This is not a provider billing limit, an infrastructure budget, or control over agents launched outside managed sessions. Omnigent fits recorded-cost enforcement at its supported gates. Use separate provider-side controls where available, and check pricing and enforcement before relying on a cap unattended.