Skip to main content
A spend cap limits what one project’s proxied requests can cost you at your LLM providers in a calendar month (UTC). Once the month’s spend reaches the cap, the proxy refuses the project’s requests instead of sending them, until the month ends or you raise the cap. It counts the provider’s list price for the usage the provider reported, the same figure each event records as its upstream cost. It does not know about discounts, credits or committed-use contracts, so your provider’s own console remains your bill.

​
Set a cap

In the dashboard, open the project’s Overview and use Upstream spend cap. It shows this month’s spend against the cap and warns at 80%. Project admins can set or remove a cap, as an organization admin sets a budget at OpenAI or Anthropic; anyone who can see the project can read it. Every change is in your audit log. With the dashboard API:
cap_usd is a decimal string, not a number. GET on the same path returns the cap, the month, spent_usd and reserved_usd, whether you may change it (can_manage), and the bounds a cap must keep; DELETE removes the cap.

​
How the proxy holds you to it

Before each request is sent, the proxy reserves the most it could cost, and it never estimates low:
  • Input: every byte of the request as sent, plus 1,024 for the provider’s framing, as input tokens (no tokenizer makes more tokens than bytes), plus the most one image can cost for each image or file in it, because one sent by URL is a few bytes in the request and thousands of tokens at the provider.
  • Output: the request’s max_tokens (or max_completion_tokens, max_output_tokens on the Responses API, generationConfig.maxOutputTokens on Gemini), capped at the most the model can generate. A request that sets none reserves the model’s own maximum.
  • Every answer: a request for n answers (or best_of, or Gemini’s candidateCount) reserves that many times over.
It refuses the request if this month’s spend, the reservations of requests still in flight and this reservation together would exceed the cap. The reservation is never trimmed to fit what is left. Reservations are made one at a time per project, so many requests sent at once cannot together go past the cap. When the answer arrives, the reservation is settled to what the request actually cost: Because a request with no max_tokens reserves for the longest answer the model can give, near the cap it is refused sooner than it needs to be. Set max_tokens on capped projects to reserve only what you allow. If PromptGuard stops while a request is in flight, its reservation keeps counting at its full amount for 15 minutes, and is then counted as spent at that amount, since nobody can say what the provider billed. A reservation counts in the month it was made, in UTC. One made just before midnight UTC at the end of a month settles into that month, even if the answer arrives in the next.

​
What a cap cannot see in advance

Conversation state the provider keeps for you is billed as input but is not in the request: the Responses API’s previous_response_id or a stored conversation. The proxy cannot count those tokens before sending, so such a request is settled at what it actually cost and can take the month past the cap by that much; the next request is then refused. The same holds for a document or audio file sent by URL or file ID that costs more than one image.

​
When a request is refused

Models PromptGuard cannot price include every model on Azure OpenAI, Bedrock, Gemini, self-hosted servers and OpenAI-compatible endpoints, whose prices depend on your own contract or deployment. A project with a cap can only use priced models; one without a cap is not affected. The dashboard lists these providers beside a cap once one is set. See Error handling for every code.

​
What a cap covers

Monitor mode included. A project in monitor mode is still held to its cap. Monitor mode means threats are recorded and never block; it does not mean spend is uncapped, and the cap is a limit you set on your own spend, not a security verdict. One project, through PromptGuard. A cap counts only the requests this project sends through the PromptGuard proxy. It does not cover your other projects, which each have their own cap, or any use of the same provider key that does not go through this project: your provider still bills those, and the cap never sees them. To cap a key’s total spend, set a budget at the provider too.

​
Where caps apply

On PromptGuard Cloud and on Air-gapped installs. A project in an Organization with a Hybrid data plane cannot set a cap (409 upstream_spend_cap_unavailable_on_hybrid), because the data plane sends requests to your provider itself and the cap would never see that spend. See Self-hosted vs Cloud. If your Organization registers a Hybrid data plane after a project’s cap was set, the cap stays and still holds every request sent through PromptGuard Cloud, but the data plane’s requests are not counted against it. The dashboard and GET say so (unenforced, with the same code).