Omnigent’s cost_budget policy caps spend, but the enforcement is unusually humane. At the hard limit it does not end the session. It denies further tool calls only while the session is running an expensive model, and tells the user to switch:
_DEFAULT_EXPENSIVE_MODELS = ("fable", "opus", "gpt-5")with the cheap variants (-mini, -nano) carved back out as “not expensive.” So “out of money” becomes “switch to a cheaper model with /model and keep going.” The cap degrades the session’s cost profile instead of terminating it. An unknown model fails closed (treated as expensive), so the gate can’t be slipped by naming a model the catalog doesn’t know.
Before the hard limit there are soft ASK checkpoints, so the user sees it coming rather than hitting a wall.
Why this is non-obvious
The default mental model for a budget is binary: under it you run, over it you stop. But a hard stop mid-task throws away in-flight work and trains users to raise the cap or turn it off — both of which defeat its purpose. Reframing the cap as a quality/cost lever (“you can continue, but not on the premium tier”) preserves the work, preserves user agency, and keeps the guardrail credible. The cap changes how you continue, not whether you do.
When NOT to use it
If the goal is a hard financial ceiling no one can exceed (a shared org budget, a prepaid pool), you want the kill switch — graceful downgrade still spends. The downgrade gate is right for per-session cost discipline, not for absolute spend caps.
Sources
-
omnigent/policies/builtins/cost.py:103✓ verified