A bill that doubles month over month feels alarming, but it is one of the more diagnosable problems in AI cost management. A sudden doubling is rarely gradual drift. Something specific changed, and the change is usually one of a small number of things. The work is finding which one.
First, separate volume from rate
Every spike is either more calls or more expensive calls. Before anything else, pull two numbers for this month and last: total number of API calls, and total spend. Divide spend by calls to get average cost per call for each month.
If call volume doubled and cost per call stayed flat, you have a volume problem. If call volume stayed flat and cost per call doubled, you have a rate problem. These lead to completely different causes, and knowing which one you have cuts your investigation in half.
If volume doubled: look for retries and new workloads
A doubling in call volume without a matching doubling in users or traffic points to one of two things. The first is retry amplification. A change in your code, a spike in provider rate limiting, or a new failure mode can trigger retry storms where a single logical task fires many times. Check whether the increase is concentrated in a specific feature or time window, which is the signature of a retry problem rather than organic growth.
The second is a new automation or agent that went live. A workflow that shipped this month, or an existing one that scaled with a new customer, can add call volume fast. Check what changed in your deployments in the window when the bill started climbing.
If cost per call doubled: look for context and model changes
When each call got more expensive, the usual cause is that calls are carrying more tokens. Conversation features accumulating longer histories, a system prompt that grew, or a retrieval step that started stuffing more context into each request all raise the input token count per call.
The other rate cause is a model change. If a feature was switched to a more capable and more expensive model, cost per call jumps even though nothing else changed. Check whether any model identifiers were updated in the billing window.
Use the timeline to pinpoint the change
Most providers give you daily usage data. Plot spend by day across both months and find the day the line changed slope. That date is your anchor. Whatever shipped, scaled, or broke around that date is almost certainly your cause. Correlating the spend inflection with your deployment history turns a vague monthly total into a specific, fixable event.
Prevent the next doubling
The reason a doubling comes as a surprise is that spend was not being watched at the daily level. A weekly review that compares call volume and cost per call against the prior week would have caught this in days instead of at month end. Set a threshold, say thirty percent week over week, that triggers a look. The goal is to see the slope change while it is still cheap to investigate.
A doubled bill is not a crisis if you can name what caused it. The diagnostic is always the same: separate volume from rate, anchor to the day the slope changed, and correlate that day with what you shipped.