When the monthly cap is already spent

The monthly ceiling you wrote down has been crossed, and the feature is still answering. Tonight, in this order: attribute the dollars to this feature before you edit a prompt. Stop the path that can grow without a new user — the retry, the loop, the largest context — and leave a bounded path only if it still meets the case you called safe. Refuse new work over the cap in words the user can see. Do not clear the alarm by minting another key that has no ceiling. If you cannot do the first step, you are not over a cap. You are reading an invoice you cannot yet explain, and turning anything off would be a guess.

This is the money rule on a live feature. It is not the design argument about why an AI feature gets expensive, and it is not the rule for a harmful answer. Cheaper tokens, caching, and which model runs which step are decisions you wish you had made before launch. Whether the next answer can hurt someone, and whether a person can stop it, is a different meeting, and it is allowed to fire on a night when you are still under the cap. Teams lose the evening by holding one call that tries to be both. The bill does not tell you the answer is wrong. A wrong answer does not wait for the bill.

The price fell. That is not why the cap broke. Stanford's Institute for Human-Centered Artificial Intelligence, in the 2025 AI Index, states: "The cost of querying an AI model that scores the equivalent of GPT-3.5 (64.8) on MMLU, a popular benchmark for assessing language model performance, dropped from $20.00 per million tokens in November 2022 to just $0.07 per million tokens by October 2024 (Gemini-1.5-Flash-8B)—a more than 280-fold reduction in approximately 18 months" (Stanford HAI, Artificial Intelligence Index Report 2025, published 7 April 2025). The next sentence is the caveat the headline drops: "Depending on the task, LLM inference prices have fallen anywhere from 9 to 900 times per year." Read $20.00 and $0.07 as one comparison, the price of a model that scores 64.8 on MMLU, named as equivalent to GPT-3.5, with Gemini-1.5-Flash-8B as the October 2024 example. The report prints 64.8 in that parenthetical; it is a benchmark score, not a dollar. The 280-fold figure is that comparison over about 18 months, not a rate for every task, which is why the 9-to-900 range is in the same paragraph. Hardware cost and energy efficiency elsewhere in the report are different claims. Do not fold them into the token price.

A cap written against last year's price per token is not a cap on tokens per task. If the unit price fell and the invoice still crossed the number you wrote down, the volume moved. Volume here is not only "more users." It is more steps per user: a retry, a second pass, a context that grew because yesterday's turns are still in the request. Why that multiplier exists, and why a quote in cents per thousand tokens does not tell you next month, is what it costs to run an AI agent in production per month. This article starts where that one ends. The month is already spent. The feature is still serving. The question is what you stop tonight, not how the architecture should have been drawn.

Attribute the dollars before you touch the prompt. A shared key's invoice is not this feature's bill. One vendor's console shows why a ceiling can exist and still not name the feature, and the details are that vendor's. Anthropic distinguishes two brakes. "Spend limits set a maximum monthly cost an organization can incur for API usage." Rate limits set how many requests you can make. On the tiers it publishes: "Each of the Start, Build, and Scale tiers carries a monthly spend cap, which is the maximum your organization can spend on the API each calendar month." The table lists Start at $500 USD, Build at $1,000 USD, and Scale at $200,000 USD. "Organizations on the Custom tier have no monthly spend cap." When a tier cap is hit, "API usage pauses until 00:00 UTC on the first day of the next month, unless you request a higher limit sooner" (Anthropic, Rate limits). Those three dollar figures are that page's tier caps, not a budget for your feature and not a figure from our own pricing. A limit you set yourself cannot exceed the tier cap, and hitting it is a different error from the tier pause. Waiting for the vendor's monthly reset is not a product decision. It is what happens when the only ceiling is the one they imposed.

The organization cap is not the same object as a per-feature cap, and the same vendor's workspace page names the hole. "You can set workspace limits lower than (but not higher than) your organization's limits." Then three bullets: "You cannot set limits on the Default Workspace." "If not set, workspace limits match the organization's limits." "Organization-wide limits always apply, even if workspace limits add up to more." And the reporting line: "Usage and costs attributed to the Default Workspace have a null value for workspace_id" (Anthropic, Workspaces). A key in that default workspace can spend until the organization tier stops it, and the cost report will not name a workspace. The organization-level limit you set yourself lives on the billing page, which is a different screen from the workspace panel, so a person who only opened one of them has not seen both ceilings. That is a description of one console, as its documentation publishes it, not a map of any other provider. The test you can perform anywhere is the same: name the key, name the project or workspace, name the feature, and lower that project's ceiling without waiting for a human at the vendor. If you cannot, stop guessing which prompt to trim.

Stop the path that grows without a new user. A retry loop, an agent that re-reads its own answer, and a context window that resends the whole thread will cross a cap on a quiet afternoon, with no launch and no campaign. Those are the paths to cut first, because cutting them does not require you to decide that the product is a failure. Leave a bounded path in place when it still does the safe thing: a single call, a draft a person will read, a refusal when the input is outside the cases you scored. If the only path you have is the unbounded one, then the feature comes down for the night. That is not a verdict on the model. It is the absence of a cheaper safe path.

Do not confuse this cut with the harm rule. Turn the feature off — or turn off the part that acts — when the next answer can hurt someone and nobody awake can stop it. That decision has its own triggers, and it does not wait for a finance threshold. When to turn a live AI feature off is that rule. A cap breach can happen while every answer is still inside the behavior you accepted. A harmful answer can happen while you are at 10 percent of the cap. Running one checklist for both will either leave a bad answer up because the bill looks fine, or take a safe draft offline because the invoice surprised you. Write down which one you are in before you change a setting.

Refuse in the product, in words. A silent swap to a smaller model, once the cap is crossed, is a different product wearing the same button. The user asked the system they were shown. If you can no longer afford that system, say so: the assistant is paused, a person will pick this up, try again next month. A queue with an honest wait is a product decision. A cheaper answer presented as the same answer is how a cap breach becomes a quality incident you will not be able to reconstruct, because the prompt and the model both moved on the same night. The record of what the customer was shown, if you later need it, is a different article. Make the record before you edit.

Minting a second key to get through the month fails the same test. The new key has no ceiling, the old alerts do not watch it, and the invoice arrives as two lines nobody added together until the following week. If the business decision is to raise the cap, raise the cap you already have, in the same project, with a named person and a date you will look again. A second key is not a raise. It is a hole next to the alarm.

There is a version of this night where calling in a rescue team is the wrong purchase. You have not attributed the invoice, so you do not yet know which feature crossed anything — read the report before you buy a rebuild. Nothing is in production; a bill from a developer's laptop is a key-management problem, not a stalled pilot. The question on the table is how the feature should have been designed so the bill could not do this, and the system is not yet serving customers. That is a design review, and it belongs before launch, in what makes an AI feature expensive to run. A customer has already seen another customer's data. That is an incident with its own first hour, and a spend cap will not close it. You never wrote down the metric the feature had to move, so "the cap broke" is the only number you have. A rescue priced against a metric you have not named is a template, and you should not buy one.

When the attribution is done and the feature is the thing that crossed, the engagement that fits is the one that starts by saying what is salvageable. An AI pilot failed to reach production is scoped after an audit, not before it, and the audit is the first one to two weeks of an engagement that runs eight to twelve. The build is unpaid if the metric you agreed does not move. Rollout, when it happens, sits behind a human-review gate. If you do not yet know whether the pilot can be saved, a two-week AI readiness assessment hands you the findings either way. Those are the terms. They are not a promise that a cap breach is always a rescue, and they are not a rate.

What a bounded path looks like, when one already exists, is a system that can stop itself without a new key. A support agent for a DTC ecommerce brand escalates on confidence and hands a person the conversation, and it measures resolution with an evaluation suite before and after a release. That case is not a story about an invoice, and nothing here is a ticket rate, a headcount, or a duration. The shape is the point: there is a path a person still approves, so "stop the unbounded path" has something left to stand on. If your feature has no such path, tonight's honest move is to stop serving, not to hope the next model is cheaper.

Before midnight, do the four steps in order and write down which one you reached. Name the key and the feature. Cut the retry, the loop, or the resend, or take the feature down if that is all you have. Put a sentence in the product if you are refusing. Do not create a second uncapped key. The number the engagement has to move, once you are past the alarm and into a rebuild, is the same discipline as AI evaluation and observability: a metric you can miss, checked on a cadence shorter than the invoice. The cap is how you notice. It is not the repair.