Blog · Product and FinOps · 20 Aug 2026

What Happens When Every Prompt Picks a Different Model?

In Cursor a private person can toggle the model per prompt, turn internet on or off, and try a new Grok release on one turn and a cheaper model on the next. Companies now ship the same flexibility in product routers. ConvoMargin does not pick the model. It measures margin on whichever model actually ran.

Why does per-prompt model choice break a monthly AI bill?

A monthly invoice answers “how much did we spend on the vendor?” It does not answer “was this support ticket, this codegen loop, or this research agent still profitable?” When every prompt can be a different model, the blend gets worse. Last week’s cheap completions and this week’s premium agent with web search land on the same line.

That is true inside an IDE and inside a SaaS feature. Cursor is the vivid case because the human sees the model picker. Product teams hide the picker behind a router, a fallback, or “use the new release for hard tickets.” The P&L still needs a row per call: model ID, tokens, tools, user, revenue.

TLDR: Flexibility per prompt makes blended spend less useful. Log the model on the row. See our build log.

What is ConvoMargin if the model keeps changing?

ConvoMargin is LLM FinOps at conversation grain. You connect usage signals, map them to revenue per conversation or plan, and read gross margin. The offering is not “we will choose Grok or Claude for you.” It is “whatever you chose, here is cost vs money earned.”

Three delivery paths stay the same. The on-page calculator is a three-tier planning sketch (budget, mid, premium) because a public page cannot know your Cursor toggle. An Audit Sprint reads the logs you have, including model names if they are in the trace. Waitlisted middleware is meant to stamp model and tokens at the API or SDK boundary so the next prompt’s different model is just another row.

TLDR: The product is prompt-level margin, not a recommended model. See offerings.

How should you track Cursor-style work in public?

Cursor does not hand a third-party site an invoice per chat. Headroom can measure tokens if traffic goes through its proxy. If the proxy is down, measured spend is $0 even while the agent is working. The honest public record is: log the session, name the model you used, estimate tokens, price them on a published rate card, and label the dollars modeled.

That is how we now treat convomargin.pages.dev itself. Older rows used a mid-tier blend with the model unlogged. From 20 Aug 2026, new rows name the Cursor model (this site’s recent work is Grok 4.6) and whether web or deploy tools ran. Same margin math as the calculator. Not a Cursor bill. The gap between those two numbers is exactly why customers need prompt-level logs in production.

TLDR: Name the model, price the tokens, label modeled until you have invoices. Try the preview.

What belongs on each prompt row?

Minimum useful receipt: model ID, input tokens, output tokens, tools (web, code exec, retrieval), user or cohort, and the revenue you assign to that conversation. Optional but high value: retries, failed deploys, cache hits, and whether internet was enabled. You can still roll up by vendor or department later. You cannot recover a per-prompt mix from a blended total.

If a founder says “we cannot explain the product because people switch models,” the answer is the opposite. Switching models is the job to be measured. Unlimited AI features, enterprise seats, and support loops all inherit the same row shape.

TLDR: One row per prompt. Roll up later. Do not start from the blend. SaaS margin post.

Measure the model that actually ran

Stress-test a tier in the preview, then book an Audit Sprint if you want a cohort read from logs that include model names. The build log is the public version of the same habit.

Try the preview Read the build log