# What is cost per prompt version? > Cost per prompt version splits model spend by which revision served the call. Why a prompt edit is a pricing decision, with worked math. URL: https://getculpa.com/what-is-cost-per-prompt-version Last reviewed: 2026-08-01 ## Answer Cost per prompt version is model spend split by which revision of a prompt served each call. Without a version stamped on the call at request time, an edit and the cost change it caused can't be connected afterwards. Culpa, a local-first LLM cost, margin, and forecast ledger, names the prompt version behind every call, so an edit reads as a priced change rather than a mystery. ## Why this happens Prompt edits get reviewed for quality and never for price, because the two live in different places. A reviewer can see that the new version answers better. Nobody in that review can see that it added 1,300 input tokens and 280 output tokens to every call the feature will ever serve. The information needed to connect them has to be captured at the moment of the call, because a version identifier can't be reconstructed from a bill or from a git history after the fact. ## What this usually looks like - Prompt changes ship through review with no cost number attached to them. - Cost per call moved and the only way to test a suspected prompt is to roll it back in production. - Two versions of a prompt run concurrently in an experiment and only quality is measured on both arms. - Nobody can say which prompt version served a call from last Tuesday. ## Common mistakes - Reviewing prompt edits for quality only. Why it hurts: Every added token bills on every call forever, so a quality-only review approves an unpriced increase. Do instead: Put token delta and projected monthly cost in the pull request, next to the quality evidence. - Storing the prompt text in the log instead of a version identifier. Why it hurts: You end up storing prompt content you didn't need to keep, and grouping by it gets fragile and slow. Do instead: Hash or tag the template, log the identifier, and keep the text where it belongs, in version control. - Running a prompt experiment without splitting cost by arm. Why it hurts: The winning arm gets chosen on quality alone and its unit cost only surfaces after full rollout. Do instead: Report cost per call per arm alongside the quality metric, and decide on both together. ## Self-check - Pick your highest-volume prompt and find the last three edits to it in version control. - Count tokens on each of those three versions. The deltas are what you shipped without pricing. - Multiply the largest delta by last month's call count for that feature. That's the unpriced decision. - Check whether a call record carries a prompt version identifier. If it doesn't, none of this is answerable. - For any live prompt experiment, confirm cost per call is reported per arm rather than only in aggregate. ## One prompt edit, measured for quality, never for price (illustrative) A feature on Gemini 2.5 Pro at real rates of $0.00125 per 1k input and $0.010 per 1k output. Version 4 was replaced by version 5, which added three few-shot examples and asked the model to explain its reasoning. Token counts and call volume are modelled. v4: 1,800 input, 240 output = (1.8 x $0.00125) + (0.24 x $0.010) = $0.00225 + $0.00240 = $0.00465 v5: 3,100 input, 520 output = (3.1 x $0.00125) + (0.52 x $0.010) = $0.003875 + $0.00520 = $0.009075 Cost per call rose by $0.004425, which is 95% At 900,000 calls a month: v4 = $4,185, v5 = $8,168 Monthly increase = $3,983, from an edit whose review recorded a quality score and no price The quality gain was measured to two decimal places and the $3,983 wasn't measured at all. Both numbers were available at the same moment, and only one of them was being collected. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - $0.00465 to $0.009075 — modelled cost per call across two versions of one prompt on Gemini 2.5 Pro [estimated] Source: Both endpoints at real Gemini 2.5 Pro rates per 1k tokens from the price book, effective 2026-07-02. A range because the token counts on each version are modelled. - $3,983 — modelled monthly increase produced by a single prompt edit at 900,000 calls [calculated] Source: (900,000 x $0.009075) minus (900,000 x $0.00465), using real Gemini 2.5 Pro rates per 1k tokens. Call volume and token counts are modelled. ## FAQ Q: How do I track cost per prompt version? A: Attach a version identifier to the template and log it with every call. A hash of the template text works well, because it changes exactly when the prompt does and needs nobody to remember to bump a number. Q: Can I work out prompt cost after the fact? A: Only roughly, by correlating a spend step change with a deploy date. That works when one prompt changed on that day and fails completely when several did, which is why the version has to be captured at call time. Q: Should prompt cost block a merge? A: Not usually block, but it should be visible. Putting the token delta and the projected monthly figure in the pull request turns an invisible increase into a decision somebody makes on purpose, which is all the gate needs to do. ## Sources - Gemini API pricing: https://ai.google.dev/gemini-api/docs/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=what-is-cost-per-prompt-version&cluster=metric Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.