Spending limits and reservations

A model request needs both enough prepaid credit and enough room under the project's monthly limit. These checks happen before admission and include reservations for concurrent work.

Available creditCopy Anchor Link

available credit = posted balance − open reservations

Suppose the project has $10 in posted balance and $3 reserved for running requests. It has $7 available for new reservations. When a reserved request settles below its bound, the unused portion becomes available again.

The reservation is not an extra fee. If a request reserved $0.05 and ultimately cost $0.02, the final charge is $0.02 and $0.03 of capacity is released. The completed job still records that its original reservation was $0.05.

Monthly capacityCopy Anchor Link

Admission also checks that current-month settled spend, all open reservations, and the new reservation fit within the hard limit. The limit defaults to $100 for a new project and can be changed in Settings.

A project with plenty of credit can still receive spend_limit_exceeded. Buying more credit does not raise the cap. Conversely, raising the cap does not buy credit. Resolve the specific failed condition rather than changing both values without inspecting them.

Calendar boundariesCopy Anchor Link

Monthly spend uses calendar months in UTC. Settled usage is attributed when settlement occurs. Open reservations remain relevant across a month boundary; the calendar reset does not free money held by unfinished work.

The Usage page shows a recent 30-day view rather than exactly the current calendar month. Its total can differ from the amount used by the monthly-limit check when the period crosses two months.

Pause new spendingCopy Anchor Link

Set the monthly limit to $0 to prevent new paid admissions. Existing jobs continue and can settle. Lowering the limit below already-spent or reserved amounts has the same practical effect for new work; it does not cancel jobs or rewrite the ledger.

Revoking a key is a credential action, not a project-wide budget pause. Other valid keys can still submit if budget allows. Use the spending limit when the intended control is to pause the whole project.

Reduce avoidable reservationsCopy Anchor Link

Choose a sensible maximum output size. A large output ceiling reserves more even if answers are usually short. Do not reduce it so far that reasoning consumes the allowance before the final answer can be produced.

Limit application concurrency when many requests compete for available balance. Serialize dependent learning updates for version correctness as well as budget predictability. Unresolved reconciliation jobs retain their reservations until the outcome is established; repeated submissions do not make that balance available.

For exact prices, see Credits and pricing. For an unexpectedly held amount, inspect Activity and follow job recovery.