FinOps for AI & COGS Attribution

Inference is the dominant COGS line at Cursor. The whole job reduces to one sentence: own the unit economics of running an AI product at 1M+ DAU.

The domain round opens here because everything else hangs off it. Capacity plans, chargeback models and R&D-prioritization debates all assume you can build the cost stack from the bottom. A weak candidate quotes a monthly cloud bill. A strong one starts at the token and rolls up.

The trap is collapsing these levels. "Cost per request" and "cost per inference" diverge the moment a request triggers retrieval plus a routing call plus generation. If you can't keep the fan-out straight, every downstream number inherits the error.

Production COGS is not R&D spendgoverned differently, reported differently

Serving a user is COGS, it scales with usage and lands on gross margin. Training a model or running an experiment is R&D, it's an investment bet governed on a different cadence with different owners. Conflating them is the fastest way to lose credibility with Finance.

Where Cursor's cost actually livesmap the product to the bill

The revenue-vs-cost-per-user view is what turns this into a business answer. A flat-priced seat that costs $4/month to serve a casual user and $40 to serve a power user has wildly different margins under the same price. That spread is the single most useful chart you can bring to a margin conversation.

Cloud FinOps was built for workloads that sit still. AI workloads don't. That mismatch is the heart of this round.

Classic FinOps assumes spend maps cleanly to durable cost centers, that month-over-month comparisons are meaningful and that the monthly bill is timely enough to steer by. Each of those assumptions cracks under an experimental, GPU-heavy AI product. Naming exactly how they crack is what separates a FinOps-for-AI answer from a generic one.

Cost-per-resource vs. cost-per-outcomethe metric that survives a changing product

Cost-per-resource - dollars per GPU-hour - is stable but says nothing about whether the spend is productive. Cost-per-outcome - dollars per accepted edit, per completed agent task, per retained user - survives a model swap because it's anchored to value, not to the resource that happened to produce it.

A concrete example sells this. If a routing change cuts cost per token by 20% but tanks acceptance rate, cost-per-resource looks like a win and cost-per-outcome reveals the loss. The outcome metric is the one that catches the false economy.

Showback shows a team what it spends. Chargeback makes that spend its budget. Knowing which to ship first is the whole design question.

The instinct to jump straight to chargeback is the rookie move. Chargeback on bad data starts a fight over the data instead of the spend and you lose the room. Showback first builds trust in the numbers and surfaces the attribution bugs before money is on the line.

The phased rolloutearn the right to charge back

1. 1Instrument tagging. Attribute every inference at request time to team, feature and environment. No tag, no attribution - make untagged spend visible as its own line so it can't hide.
2. 2Ship showback. Give teams a dashboard of their own cost. Let them challenge it. Fix the attribution bugs they find - this is where data quality actually gets built.
3. 3Reconcile and trust. Tie attributed totals back to the real bill. When the sum of showback matches the invoice within a tight tolerance, the numbers are defensible.
4. 4Graduate to chargeback where ownership is clear. Apply budget accountability only to features with a single clear owner. Leave genuinely shared costs in showback or a fair-split pool.

Allocating shared and contested costwhere the fights happen

Anticipate gaming. If you allocate shared cost by request count, a team will batch requests to look cheaper. If by tokens, they'll trim outputs in ways that hurt users. The defense isn't a perfect rule, it's a rule that's transparent and a forum where disputes get resolved out loud.

The take-home or whiteboard cost model is where this loop is won or lost. Cursor wants the artifact, not the ceremony - build the model, write the recommendation.

Under time pressure the failure mode is a sprawling spreadsheet with hidden assumptions and no conclusion. The winning move is a model that's legible: it starts at the unit, labels every input and ends with one recommendation and the tradeoff named. Structure beats polish here.

1. 1Start from the unit. Anchor on cost per inference or cost per active user. Everything else is a multiplier on or a rollup from that unit.
2. 2Label every input known vs. estimated. GPU hourly rate is known; requests per user per day is estimated. The interviewer trusts a labeled estimate far more than a confident guess.
3. 3Run sensitivity on the 2-3 dominant variables. Utilization, model mix and request volume swamp everything else. Show how the answer moves across a plausible range of each.
4. 4Show the bridge. Walk how a routing or batching change flows through the model to COGS, so the recommendation is traceable, not asserted.
5. 5Cross-check with back-of-envelope. Before trusting the sheet, sanity-check one cell against a napkin number. If they disagree by 10x, the sheet has a bug.
6. 6Land one recommendation, tradeoff named. Not a menu - a call, with the cost of being wrong stated.

A worked skeletonthe shape of a defensible model

# --- INPUTS (known | estimated) ---
gpu_hourly_cost      = 2.50    # known: reserved instance rate
gpu_throughput_tok_s = 3000    # known: from serving benchmarks
util_target          = 0.55    # estimated: sustained, post-batching
active_users         = 1_000_000   # known
reqs_per_user_day    = 40       # estimated: blended tab + chat
tokens_per_req       = 350      # estimated: blended in+out
days                 = 30

# --- DERIVE cost per token ---
eff_tok_per_hour = gpu_throughput_tok_s * 3600 * util_target
cost_per_token   = gpu_hourly_cost / eff_tok_per_hour       # ~ $4.2e-7

# --- ROLL UP to monthly COGS ---
tokens_month = active_users * reqs_per_user_day * tokens_per_req * days
monthly_cogs = tokens_month * cost_per_token                # the headline

# --- SENSITIVITY: the 2-3 that dominate ---
# util_target 0.45 -> 0.65 : COGS swings ~30%
# model_mix (share routed to large model) : each +10pt ~ +X% COGS
# reqs_per_user_day +/- 20% : linear pass-through to COGS

Notice utilization sits inside cost per token, so it's the most impactful input in the whole model. A model running at 55% vs. 35% utilization changes the headline by more than most feature decisions ever will. That's the variable to sensitize first and to interrogate hardest.

Half this role is interpreter. Engineers talk utilization and batching; Finance talks COGS and capex. You're the one who makes each side legible to the other.

The JD calls this translating between technical and financial domains and it's not a soft skill - it's the mechanism by which your analysis becomes a decision. A perfect cost model that Finance can't reconcile to their reporting is a model that never leaves your laptop.

Agree the dictionary up frontkill the re-litigation

Most cost disputes are definition disputes wearing a costume. Does "cost per user" mean per active user or per paid seat? Does COGS include the idle reserved baseline or only used capacity? Nail these once in a shared metric dictionary and you stop re-arguing them every month.

Make the tradeoffs legiblethe recurring decisions Finance must own with you

• Latency vs. cost: a faster small model is cheaper but may lower acceptance; price the quality delta, don't just quote the savings.
• Reserve vs. on-demand: reserved cuts unit cost but bets on sustained demand; show the breakeven utilization where the commitment pays off.
• Build vs. buy: an in-house model trades upfront R&D for lower recurring COGS; give Finance the payback period, not a vibe.