Omnigent's spend cap is enforced before the call, and is a downgrade gate rather than a ceiling
Read at the v0.7.0 tag, cost_budget gates cumulative session spend at the request phase (before the LLM turn, so text-only turns count) and at the tool-call phase (where a native PreToolUse hook blocks before the action runs). So it enforces rather than reconciles, which is the better half of the answer. But max_cost_usd does not stop a session: the module states it "forces a model downgrade" and DENYs only while the session is on a model in the operator-supplied expensive_models list, becoming "a downgrade gate, not a hard stop." It also fails closed when token usage is present but priced cost is absent, so unpriced models cannot silently bypass the cap, and it notes that a single expensive turn can overshoot between checks.
What this changes for operators
- An operator who sets max_cost_usd expecting spend to stop at that number has not configured that. Spend continues past the cap on any model outside expensive_models. Set the cap and the expensive_models list together, and treat the number as the point where the session gets cheaper rather than the point where it ends.
Run: 2026-08-03-weekly-digest-2026-07-27_2026-08-03-frontier-v0
Schema: bitter.frontier_signals.v0 / ID: 2026-08-03-omnigent-max-cost-usd-is-not-a-ceiling
Research evidence and publication history are open in the repository.