Metering and budgeting model usage
How to measure language model usage per feature and per customer, set limits before a bill surprises you, and handle the errors that limits produce.
Most software costs roughly the same whether a user clicks once or a hundred times. A feature built on a language model does not. Providers bill by usage, usually counted in tokens, so the cost of a feature depends on how long the inputs are, how long the outputs are, how often it runs and how many times a failed call is retried. A prototype that is cheap to run with one tester can become expensive when real users arrive, without any change in the code.
This article describes what to measure, which limits exist at the provider and in your own code, and how to handle the errors those limits produce. It draws on vendor documentation and the OWASP Gen AI Security Project as read on October 10, 2026. It quotes no prices and no usage limits, because both change and both are on each vendor’s own pages; wherever a number matters, look it up on the day you decide.
Start by counting tokens, from the right place
A token is the unit the model reads and writes. Google’s page says that for its models a token is equivalent to about 4 characters, so the relation to words is approximate and vendor-specific. Two practices follow from the vendor pages.
First, record usage from the response, not from an estimate. Anthropic’s token-counting page describes an endpoint that counts the tokens in a message before you send it, to help you proactively manage rate limits and costs, and notes that the count is an estimate that can differ by a small amount from actual use. The same page says the Messages API response reports the tokens used in its usage object, and Google’s page points to the usage fields of a response for actual token usage. Use the pre-flight count to decide whether to send; use the response to decide what you were charged for.
Second, do not carry a count from one model to another. Anthropic’s page says the token counting endpoint counts under the tokenizer of the model you pass, that usage on newer models reflects that tokenizer’s counts, and that when migrating you should not reuse counts measured on the older model to estimate costs or context window fit. Count with the model you plan to use. Whichever vendor you pick, a model change is a cost change until you have re-measured.
What to record on every call
A useful usage record is small. For each call, store the time, the feature that made it, the customer or account, the model identifier, the prompt version, input tokens, output tokens, whether it was a retry, and how long it took. With those fields you can answer the questions a budget depends on: which feature costs the most, which customer is an outlier, and whether yesterday’s prompt change moved the cost.
Use separate API keys, or separate projects, for development, testing and production, and for distinct features where the provider allows it. Anthropic’s deprecation page describes a usage export in its console that breaks usage down by API key and model, which is only as informative as your key structure. That attribution tip is this article’s suggestion, built on the export the vendor describes. Keep the keys themselves out of code and chat; the security baseline checklist asks whether secrets are held in a secrets manager.
Budget in units you can control
Convert the provider’s pricing, from its own page and dated in your records, into a cost per task. The arithmetic is simple: tokens in times the input rate, plus tokens out times the output rate, plus anything else the vendor charges separately. Then multiply by the number of tasks a typical customer runs in a month and compare the result with what that customer pays you. If the margin is thin, the feature’s design is the lever: shorter prompts, fewer retrieved passages (see retrieval-augmented generation), a cap on output length, or a plan tier that limits use.
The limits that exist, and who sets them
| Layer | What it does | What the source says |
|---|---|---|
| Provider spend limit | Stops usage when a monthly cost ceiling is reached | Anthropic describes spend limits as a maximum monthly cost an organization can incur, and says you can set your own limit below your tier cap |
| Provider rate limit | Caps requests or tokens in a time window | OpenAI lists requests, tokens and images per minute or day, defined at the organization and project level, not user level |
| Your per-user limit | Stops one user from consuming the shared allowance | OpenAI advises setting a usage limit for individual users within a daily, weekly or monthly time frame |
| Input and time controls | Bounds the size and duration of one request | OWASP lists input size limits, rate limiting and user quotas, and timeouts and throttling |
Two of these layers are invisible to your customers and shared between all of them, which is the argument for the other two. A provider limit is set at the organization or project level, so one customer’s burst can use the allowance that the rest need. A per-customer quota in your own code is the only control that treats customers separately. OpenAI’s guidance goes a step further, suggesting a hard cap or a manual review process for users who exceed the limit.
What happens when a limit is reached
The two failure modes look similar and need different responses.
A temporary rate limit. OpenAI’s guide says the API returns a 429 error, and the response can include a retry-after header. It tells you to treat that value as a minimum, to wait at least that long and add a small random delay so multiple clients do not retry together, and to limit both the number of attempts and the total time spent retrying. It also warns that if you manage retries in your application, nested retry loops can multiply requests, so disable SDK retries or account for them.
A spend cap. Anthropic’s page describes a different case: when you reach your tier’s spend cap, API usage pauses until 00:00 UTC on the first day of the next month unless you request a higher limit sooner. Requests return HTTP 429 with the same error type as a rate limit, but the response has no retry-after header, and retrying, including the SDK’s automatic retries, fails until access resumes. The response carries an error code that tells the two apart.
Treat that as a design requirement, not a footnote. A retry loop that handles a rate limit well will hammer a paused account, and OpenAI’s guide says not to retry quota, billing or other errors that require you to take action. Distinguish the two, alert a person for the second, and decide what a customer sees when the feature is unavailable. The article on choosing a model provider lists the questions to ask about limits before you sign up.
Cost is also a security matter
OWASP’s entry on unbounded consumption treats uncontrolled inference as a vulnerability. It names denial of wallet: by initiating a high volume of operations, attackers exploit the cost-per-use model of cloud-based AI services. Its mitigations include input validation to keep inputs under reasonable size limits, rate limiting and user quotas that restrict how many requests a single source can make in a given period, timeouts and throttling for resource-intensive operations, logging to detect unusual patterns of resource consumption, and designing the system to degrade gracefully under heavy load. A public endpoint with no per-user limit is exposed to this. The article on prompt injection and the OWASP Top 10 places it among the other entries.
What this article cannot tell you
It does not say what any provider charges or what your costs will be; it quotes no prices, rates or limits, and the vendor pages it cites change. It does not recommend a provider, and it does not describe features, such as caching or batch processing, that some vendors offer to reduce cost, because it did not review those pages. It covers hosted provider APIs, not the cost of running models yourself.
The article’s suggestions on record fields, key structure and routines are its own, not vendor guidance. It is general information, current as of October 10, 2026, and is not financial or accounting advice.
In the data
These figures describe U.S. businesses in general, not WE’s results. Each one names its source.
- LLM01:2025 Prompt Injection
- LLM02:2025 Sensitive Information Disclosure
- LLM03:2025 Supply Chain
- LLM04:2025 Data and Model Poisoning
- LLM05:2025 Improper Output Handling
- LLM06:2025 Excessive Agency
- LLM07:2025 System Prompt Leakage
- LLM08:2025 Vector and Embedding Weaknesses
- LLM09:2025 Misinformation
- LLM10:2025 Unbounded Consumption
Show the data as a table
| Code | Risk |
|---|---|
| LLM01:2025 | Prompt Injection |
| LLM02:2025 | Sensitive Information Disclosure |
| LLM03:2025 | Supply Chain |
| LLM04:2025 | Data and Model Poisoning |
| LLM05:2025 | Improper Output Handling |
| LLM06:2025 | Excessive Agency |
| LLM07:2025 | System Prompt Leakage |
| LLM08:2025 | Vector and Embedding Weaknesses |
| LLM09:2025 | Misinformation |
| LLM10:2025 | Unbounded Consumption |
Source: OWASP Gen AI Security Project, Top 10 for LLM Applications 2025 , 2025 list
Retrieved 2026-10-16. Codes and names are copied as published.
Sources
- Token counting, Anthropic . Accessed October 10, 2026.
- Understand and count tokens, Google . Accessed October 10, 2026.
- Rate limits, Anthropic . Accessed October 10, 2026.
- Rate limits, OpenAI . Accessed October 10, 2026.
- LLM10:2025 Unbounded Consumption, OWASP Gen AI Security Project . Accessed October 10, 2026.
- Model deprecations, Anthropic . Accessed October 10, 2026.
Spotted an error? Read how we handle corrections in our editorial policy.