Put a hard stop on your AI agent's spend before a loop finds it

Before the agent ships, give it a budget that can stop itself. A production agent can burn an API budget before anyone notices, and the usual gap is a shared key, a shared project, a shared ceiling, and no owner to prove the stop works.

For a small team, the spend stop is unglamorous: a separate project and key, alerts, a hard cap, and a drill. A dashboard shows the number; the ritual makes the number stop.

The cap stops traffic; the ritual proves it

On July 22, 2026, OpenAI added monthly hard spending limits for organizations and projects. OpenAI's alerts leave traffic running, while a hard cap stops it. If the agent is in a loop, the alert is a note and the cap is the fuse.

A project over its monthly cap gets an HTTP 429 with code project_spend_limit_exceeded, and an organization over its cap gets organization_spend_limit_exceeded. The rejection is ugly, but it is the behavior that protects the budget when no one is watching.

The ritual controls the spend; the dashboard only reports it

A spend dashboard is useful after the fact, but it cannot stop a loop, guide the on-call person, or prove the cap is still set after a project change.

Build the ritual around a plan. The plan should be the number the team expects, not the number the team hopes for. The plan gives the alerts a reference, the cap a target, and the log a baseline. Without a plan, the alert thresholds and the hard limit have no shared meaning.

The checklist is the test you can run in a minute

Use this list before the agent ships, and again after any change to the budget, the key, or the project.

• The agent has its own project and its own key.
• Set alerts at 60, 75, and 90 percent of the plan, early enough to reach a human before the cap.
• Set the project hard limit near 110 percent of expected peak, knowing the recorded total may be slightly above the configured cap while the new state propagates.
• Set the organization ceiling above the project total plus a reserve.
• Keep a policy log that names the owner, the plan, the caps, and the last drill date.
• Treat spend-limit 429 errors as stop signals, not failures to retry.

A shared key exposes the whole account. If the agent misbehaves, the team can revoke that key instead of stopping every tool that uses the same account. A separate project keeps the agent's ceiling from hiding inside a shared budget, and the organization ceiling needs room for the rest of the account.

The drill is the proof you can show

A cap can be changed by accident, a key can be copied, and a project can be merged. The drill is the scheduled test that shows the stop still works. It is a meeting with the budget. It catches a broken control before a real loop uses it.

Run it on a calendar, not only when the spend looks odd. The expected result is the spend-limit failure that the cap produces. The owner records the result, the date, and the next review date in the policy log. If the response is not the expected spend-limit failure, the agent is paused until the control is fixed.

The test does not need to spend much real money. It can be a dry run against a staging key, or a review of the last response that hit the limit. The owner writes what happened, what was expected, and what changed. If the control was changed without a note, treat it as broken until the note exists. The date and owner are the proof.