Last quarter our OpenAI bill went from $620 to $2,480 in 23 days.
No new features shipped. No traffic spike. Zero error alerts. Deployment logs were clean.
Just a number climbing in silence while five engineers stared at dashboards that gave us totals and nothing else.
This is what we found. And why "cost monitoring" is completely the wrong mental model.
The dashboard that answers the wrong question
First thing I did was open the OpenAI usage dashboard.
It showed me a total. A graph going up. A model breakdown.
I knew we spent $2,480. I still had no idea which feature spent it, which service triggered it, or which user was responsible. The dashboard was answering "how much" while we were desperately asking "what caused it."
Those are completely different questions. Almost every cost tool on the market only answers the first one.
That distinction matters more than most engineering teams realise until they are staring at a bill like ours.
Three features, zero visibility
We had three features hitting GPT-4o:
- A document summariser, triggered manually by users
- An inline suggestion engine, triggered on keystrokes
- A batch report generator, triggered on export
Any one of them could be the problem. Or all three. Or one specific user hammering one endpoint in a loop nobody noticed.
Without attribution at the feature, service, and user level, we were just guessing. So I did what most engineers do: optimised the feature that felt most expensive. Added caching to the one that ran most often.
Two weeks later the bill was still climbing.
Guessing at cost problems without attribution data is exactly like debugging a performance issue without a profiler. You move things around and hope.
48 hours of real data
A teammate dropped CostReveal in our Slack. I set it up that evening.
The Node.js SDK wraps your existing provider calls. You instrument each one with a feature name, service context, and user ID. That is the entire integration for the base case:
import { CostReveal } from '@costreveal/node';
const cr = new CostReveal({ apiKey: process.env.COSTREVEAL_API_KEY });
const response = await openai.chat.completions.create({
model: 'gpt-4o',
messages: prompt,
});
// one call after your existing OpenAI call
await cr.track({
provider: 'openai',
model: 'gpt-4o',
feature: 'batch-report-generator',
service: 'report-service',
userId: req.user.id,
inputTokens: response.usage.prompt_tokens,
outputTokens: response.usage.completion_tokens,
});
48 hours of data. Dashboard showed this:
Feature Cost Share
batch-report-generator $1,847 74%
document-summariser $421 17%
inline-suggestion-engine $212 9%
I had been optimising the wrong two features for two straight weeks.
The actual bug: zero error rate, $1,847 cost
Back into the batch report generator code.
Found it in under ten minutes.
The export trigger was also wired into our autosave hook. Every time a document autosaved, which happens every 30 seconds by default, it was silently generating a full GPT-4o batch report in the background.
The feature worked perfectly. No errors. No timeouts. No failed requests. Nothing in our alerting. Nothing in our logs that looked wrong.
It was just calling GPT-4o every 30 seconds per active user session. Silently. Invisibly. Expensively.
This is what a $0 bug looks like. Zero error rate. $1,847 a month.
One line fix: move the report generation call back to the manual export button only. OpenAI bill dropped 61% the following month. No model downgrade. No feature removal. No rate limiting that would have degraded the product.
The thing I did not expect: it changed how we price
Once attribution was running across features, services, and users, I stopped thinking about cost as an infrastructure problem.
I started thinking about it as a pricing problem.
CostReveal breaks cost down by feature, by service, and by user. For the first time I could see what each user's activity was actually costing us to serve:
Plan tier Avg cost to serve/month Our price
Starter $3.20 $49 ✓
Growth $31.00 $49 ✗
Enterprise $89.00 $49 ✗✗
Our Growth and Enterprise users were hitting the batch report feature heavily. We were losing money on both plan tiers at flat $49 pricing.
We repriced. Growth moved to $99. Enterprise moved to usage-based custom. We had the per-user, per-feature attribution data to build the case internally and explain the change to customers without a single guess involved.
That is not a cost monitoring outcome.
That is a pricing strategy outcome that only becomes visible when you have attribution at the right level of granularity.
The question worth asking right now
Can you answer this in under 30 seconds:
Which feature is most expensive to run, for which users, and is that number healthy for your unit economics at your current pricing?
If the answer is no, you do not have a cost problem. You have a visibility problem that looks like a cost problem.
Total spend is not attribution. Per service spend is not attribution.
Attribution is: Feature X, used by User Y, via Provider Z, cost exactly this much this month. Is that sustainable or not.
We had 23 active users when we found this bug. At roughly $80 average unattributed cost per user, that was quietly compounding every single month.
CostReveal fixed ours. Took one evening to instrument, 48 hours to get real data, one line to fix the bug.
Worth a look: costreveal.com
Docs if you want to go straight to setup: docs.costreveal.com
Have you ever found a silent cost bug like this? Drop it in the comments, curious how common this pattern actually is.
Top comments (2)
Quick question on the SDK setup.
When you tag by tenantId and userId both, does CostReveal let you pivot the dashboard by either dimension independently?
Like can you see all spend for a specific tenant across all features, or only feature first then tenant breakdown?
To clarify on the tenant pivot: the dashboard breaks down by Feature, Service, and User independently.
So you can go By User and see every feature that user touched and what it cost, or go By Feature and see which users are driving spend on that specific feature.
The Unit Economics section then rolls this up into cost per user which is what exposed the pricing gap in the post.
No separate tenant grouping out of the box but user level attribution gets you there.