Prompt Diff Viewer
Compare two versions of a prompt word by word, and see what the edit costs — token delta, monthly bill, and the share of the total it accounts for.
Before
0 tokens · 166 BAfter
0 tokens · 391 BWhat the edit costs
GPT-4oLoading the o200k_base vocabulary — 965.7 KB, once per browser.
Token change
+0
no baseline
Cost per month, before
$1,500
Cost per month, after
$1,500
Difference
+$0.00
+0.0% of the bill
Word-level diff
47 added, 7 removed, 28% unchangedYou are a helpful assistant.support assistant for Acme Cloud. Answer the user's question using only the documentation provided.provided below. If the answer is not present in the documentation, say youso doclearly notand know.offer to open a support ticket instead of guessing.
Be concise.concise: aim for under 150 words unless the user explicitly asks for more detail. Never invent an API name, a pricing figure or a rate limit.
Changes
11- replace−assistant.+support
- insert+assistant for Acme Cloud.
- insert+only
- replace−provided.+provided
- insert+below.
- insert+present
- replace−you+so
- replace−do+clearly
- replace−not+and
- replace−know.+offer to open a support ticket instead of guessing.
- replace−concise.+concise: aim for under 150 words unless the user explicitly asks for more detail. Never invent an API name, a pricing figure or a rate limit.
Diffed and counted in your browser — no prompt is uploaded. For comparing code or documents rather than prompts, the Text Diff Checker does line-level diffs with a unified-diff export.
About the Prompt Diff Viewer
Paste two versions of a prompt and this prompt diff shows what changed word by word — and what the change costs. A text diff tells you a prompt got longer. This one tells you it got 340 tokens longer, which is $102 a month at 10,000 requests a day, and 5.7% of the bill.
That pricing is the reason it exists as its own tool rather than as a mode of the Text Diff Checker. Prompt edits accumulate: a clause added here, an example there, each one small and each one paid for on every single request forever. The edit that adds a paragraph of instructions is usually cheaper than the one that adds a single worked example, and nothing about the diff itself makes that obvious.
Token counts come from a real BPE tokenizer running in your browser, so for models with a public tokenizer they are exact rather than a characters-divided-by-four estimate. Where a model has no public tokenizer, the count is a calibrated estimate and is labelled as one — and the delta between two versions is more reliable than either absolute figure, since the calibration error largely cancels.
The changes list pairs a deletion immediately followed by an insertion into a single replacement, because "replaced X with Y" is the shape a prompt edit actually takes, and reading nine changes is better than reading eighteen halves of them.
- Word-level diff with insertions and deletions marked inline
- Exact token count for both versions, and the delta as a percentage of the original
- Cost before, after and the difference — per day, per month or per year at your own request volume
- The change expressed as a share of the whole bill, not just of input, so it is not overstated
- Prompt cache modelled, since a cached prefix changes what an edit actually costs
- A warning when the new version no longer fits the model's context window
- Whitespace-only changes identified as such, so reflowing a paragraph is not mistaken for churn
- A collapsed list of changes, with deletion-then-insertion paired into one replacement
How to use it
- Paste the previous prompt on the left and the new one on the right.
- Set your model, requests per day and typical output length. The defaults are a placeholder, not a guess at your workload.
- Set the cache hit rate if you use prompt caching — it changes the cost of an edit substantially, since a cached prefix is charged at about a tenth of the normal rate.
- Read the difference as a share of the bill rather than in isolation. A 15% longer prompt on an output-heavy workload is a 2.5% larger bill.
- Use the changes list to review the edit itself, and the word diff to see it in context.
Real-world use cases
Prompt engineers
Review a proposed system-prompt edit before merging it, seeing both the semantic change and its exact cost impact in one view instead of eyeballing a text diff.
AI product & engineering leads
Decide whether a prompt change that improves output quality is worth its cost at production volume, with the answer expressed as a share of the actual bill rather than a raw token count.
Code reviewers
Check a pull request that touches a prompt template for accidental bloat — a duplicated instruction, a leftover example — before approving it.
Backend & platform engineers
Confirm a prompt edit still fits the model's context window before shipping it, catching a version that would start failing in production rather than just becoming more expensive.
AI QA & evaluation engineers
Track exactly what changed between two prompt versions during A/B evaluation, separating genuine wording changes from whitespace noise that a naive diff would flag as churn.
Examples
A prompt made more specific
Before: 42 tokens After: 108 tokens
Token change: +66 (+157% of input) Cost per month, before: $1,626 Cost per month, after: $1,646 Difference: +$19.80 (+1.2% of the bill)
A prompt more than twice the size for a 1.2% increase in the bill, because output dominates this workload. Worth knowing before rejecting the clearer prompt on cost grounds.
The same edit on an input-heavy workload
Output tokens: 20 instead of 500
Cost per month, before: $186 Cost per month, after: $206 Difference: +$19.80 (+10.6% of the bill)
Identical edit, identical absolute cost, and now a tenth of the bill. This is why the tool asks for your output length rather than assuming one.
Whitespace only
Before: one paragraph After: same text, rewrapped
Only whitespace differs — no word changed, and the token count barely moves. Token change: +2
The diff looks busy and the cost impact is nearly nil. Reported explicitly so you can tell this case apart from a real edit.
An edit that breaks the context window
After: 140,000 tokens, on a 128K model
The new version no longer fits GPT-4o's 128,000-token context window on its own.
Not a cost problem — a correctness one. The request would be rejected before it was billed.
Common errors
| Message | Cause | Fix |
|---|---|---|
| The bill went up after a prompt change and nobody knows why | A system prompt is sent on every request, so any addition to it is multiplied by your entire request volume. | Diff the two versions here with your real volume. The monthly difference is usually the number that makes the case for or against the edit. |
| The token delta looks small but the cost delta is large | High request volume. At a million requests a day, 50 tokens is 50 million tokens of billed input. | Nothing to fix — that is the arithmetic. It is the reason to check an edit before shipping it rather than after the invoice. |
| The cost delta is zero even though the prompt grew | The cache slider is at 100%, so the added tokens are priced at the cache rate and round to nothing at your volume. | Check the cache rate is realistic. Caching only applies to a prefix that is identical between requests, and an edit near the start of the prompt invalidates the cache for everything after it. |
| Two prompts that look identical are reported as different | Invisible characters — a non-breaking space, a zero-width joiner, or smart quotes from a word processor. | Run both through the Prompt Cleaner first. It finds and names exactly this class of character, which is also a real source of token-count differences. |
| The added and removed word counts seem too high | Punctuation stays attached to its word, so appending to a sentence reads as replacing the final token rather than as a pure insertion. | Expected behaviour. Splitting punctuation into separate tokens would make the diff noisier on ordinary prose; the token counts are unaffected either way. |
| The count here does not match the provider's usage figure | Either the model has no public tokenizer and the count is a labelled estimate, or the request includes per-message framing this page is not counting. | Use the Context Window Calculator to include chat framing, and compare against the usage block of a real API response. |
Frequently asked questions
›Is my prompt uploaded anywhere?
No. The diff and the token counting both happen in your browser. The tokenizer vocabulary downloads once and is cached, after which the page works offline — which matters here, because a system prompt is often the most sensitive part of an application.
›How is this different from the Text Diff Checker?
The diff algorithm is literally the same code — there is one LCS implementation on this site and both tools use it. What is different is everything around it: this one counts tokens, prices the change at your volume, checks the context window and pairs edits into replacements. The Text Diff Checker does line-level diffs, hunks and unified-diff export, which is what you want for code and documents and is not what you want for a paragraph of instructions.
›Why price the change against the whole bill instead of just input?
Because the share of input is not the number that matters to anyone. An edit that adds 15% to input tokens on a workload where output is four times input adds about 2.5% to the bill. Quoting the input share would overstate the impact roughly sixfold, and someone would reject a clearer prompt on the strength of it. Both numbers are shown, and the percentage is of the total.
›Does the diff work on very long prompts?
Yes. The word-level diff is quadratic in the number of differing words, which is fine for prompts of a few thousand words — the practical limit is well beyond anything that fits in a context window. Unlike the line-level diff in the Text Diff Checker, there is no fallback mode here, because prompts do not reach the sizes that make one necessary.
›Which models can be counted exactly?
Those with a public tokenizer — the OpenAI models on cl100k_base and o200k_base. Anthropic does not publish one, so Claude counts are calibrated estimates and are labelled as such wherever they appear. For comparing two versions this matters less than it sounds: the same calibration is applied to both sides, so the delta is considerably more trustworthy than either absolute count.
›How does prompt caching change the answer?
Substantially, and in a way that is easy to get backwards. A cached prefix is charged at roughly a tenth of the normal input rate, so adding tokens to a cached region is nearly free. But an edit near the start of the prompt invalidates the cache for everything after it, which can cost far more than the edit itself. The slider models the steady state; it cannot model the invalidation, so treat an early edit as more expensive than it appears.
›Should I be optimising prompts for cost at all?
Usually not first. A shorter prompt that produces worse output is not a saving, and output tokens are typically priced several times higher than input, so the response length is the bigger lever. What this tool is genuinely for is catching the edits that cost real money without buying anything — a duplicated instruction, an example that was never removed, a tool schema sent on every call when it is needed on one.
›Can I use this to review prompt changes as part of a code review process?
Yes — that is a common way teams end up using it. Paste the before and after versions from a pull request diff, read the collapsed change list for what actually changed semantically, and check the monthly cost delta at the team's real request volume before approving. It answers the two questions a raw text diff cannot: what changed in meaning, and what that change is worth.
Last updated