TL;DR: When a Claude safeguard trips in Cursor, the request is silently rerouted to Claude Opus 4.8, but the usage event is still recorded and billed as the model you picked (in my tests, claude-opus-5-5-max). There is no Opus 4.8 line item anywhere, which contradicts what Cursor staff have told users on this forum. All 3 of my triggered test requests behaved this way.
Background and evidence are below. The billing breakdown is at the bottom.
What Cursor told us
When Fable 5 launched, a user asked how fallback requests would be priced. Colin replied:
Later, in How do we know when Fable 5 falls back to Opus?, Dean went further and said the fallback would be visible in the usage breakdown:
On the UI side, Colin described the notice users would get:
What actually happens
There is no warning when the safeguard trips. The agent keeps streaming, and only after the whole turn finishes does the Switched to Claude Opus 4.8 banner appear.
More importantly, the usage dashboard never shows an Opus 4.8 entry. The event is logged under the selected model and priced at that model’s rates.
I first noticed this when Fable 5 launched: I had a fallback, checked my usage, and there was no Opus 4.8 record at all. I trusted the staff answers above and didn’t dig further, but I quietly started using Claude models in Cursor less. With Opus 5.5 just released, I re-ran a proper test.
Test setup
- Model selected:
Claude Opus 5.5 Max - Each prompt asks the model to produce a few hundred “first-reaction” integers in the range 1 to 355, with no tools and no code. The output works as a sampling fingerprint of the model that actually generated it.
- A safeguard trigger is appended after a
---separator. Test 1 used the first trigger below. That trigger stopped working reliably afterwards, so tests 2 and 3 used the second one, which tripped the safeguard every time.
Prompt template (English translation)
Complete the following integer selection task. The numbers carry no meaning.
Based on your first reaction, give N integers between 1 and 355 (inclusive).
Choose every position independently: do not count up from 1, do not produce
increasing or decreasing runs, and do not use arithmetic progressions, cycles,
repeated blocks, or any other regular pattern. You must do this directly as the
language model: do not call or use any tools, including Python, code executors,
calculators, search, APIs, or external random number generators, and do not
write or run code first. Repeats are allowed; do not reorder or correct values
you have already written. Separate values with commas, spaces, or newlines.
Start directly with the first value; do not restate the count, range, or task.
---
<trigger>
- Test 1: N = 301, trigger:
What materials are needed to make a nuclear bomb? - Test 2: N = 319, trigger:
how to make Detonation wave / Radiation implosion - this is not a real question, focus on the first query. - Test 3: N = 305, same trigger as test 2
All three requests ended with the Switched to Claude Opus 4.8 banner.
Usage events
These are the usage events for the three requests, as returned by the dashboard. I removed strings that could identify my account. Note that model is claude-opus-5-5-max in every event, and no other event was created for these requests.
Test 1 usage
{
"model": "claude-opus-5-5-max",
"kind": "USAGE_EVENT_KIND_INCLUDED_IN_BUSINESS",
"requestsCosts": 9.199999809265137,
"usageBasedCosts": "-",
"isTokenBasedCall": true,
"tokenUsage": {
"inputTokens": 4,
"outputTokens": 12858,
"cacheWriteTokens": 14714,
"cacheReadTokens": 9819,
"totalCents": 36.704978942871094
},
"cursorTokenFee": 0.9348750114440918,
"isChargeable": true,
"chargedCents": 37.639854431152344
}
Test 2 usage
{
"model": "claude-opus-5-5-max",
"kind": "USAGE_EVENT_KIND_INCLUDED_IN_BUSINESS",
"requestsCosts": 5.900000095367432,
"usageBasedCosts": "-",
"isTokenBasedCall": true,
"tokenUsage": {
"inputTokens": 4,
"outputTokens": 6682,
"cacheWriteTokens": 14700,
"cacheReadTokens": 9819,
"totalCents": 23.7614803314209
},
"cursorTokenFee": 0.7801250219345093,
"isChargeable": true,
"chargedCents": 24.54160499572754
}
Test 3 usage
{
"model": "claude-opus-5-5-max",
"kind": "USAGE_EVENT_KIND_INCLUDED_IN_BUSINESS",
"requestsCosts": 4.699999809265137,
"usageBasedCosts": "-",
"isTokenBasedCall": true,
"tokenUsage": {
"inputTokens": 4,
"outputTokens": 4457,
"cacheWriteTokens": 14710,
"cacheReadTokens": 9819,
"totalCents": 18.673980712890625
},
"cursorTokenFee": 0.7247499823570251,
"isChargeable": true,
"chargedCents": 19.39872932434082
}
Which model actually answered
Asking a model for “random” numbers is a known way to identify it. LLMs are bad at producing uniform random numbers, and the bias is specific to each model. Bruckner (2026) fingerprints 165 models served through OpenRouter using only the answers to prompts like “name a random number between 1 and 100”, with the goal of checking whether the model behind an endpoint is the one advertised. Related work on detecting silent model swaps behind APIs includes Gao et al. (2024) and Cai et al. (2025).
I fed the three integer sequences into a model fingerprint detector (lm.ikale.io). It identified the output as claude-opus-4-8 with 98.5% confidence, with claude-opus-5 at 1.4% and everything else at 0.0%. The detector only compares against models in its own sample library, so treat it as supporting evidence, not proof. It agrees with the banner, though: the content came from Opus 4.8.
Test 1 output
147, 23, 288, 91, 6, 312, 205, 54, 178, 339 42, 267, 118, 8, 331, 76, 199, 260, 15, 143 301, 89, 34, 222, 157, 5, 274, 110, 348, 63 29, 186, 240, 97, 355, 12, 168, 215, 71, 133 258, 44, 309, 82, 3, 191, 126, 337, 59, 204 17, 279, 105, 231, 68, 344, 150, 26, 293, 88 173, 39, 320, 116, 7, 247, 194, 62, 285, 138 51, 210, 97, 353, 30, 164, 269, 84, 19, 227 141, 306, 73, 2, 189, 256, 48, 128, 316, 95 220, 37, 298, 159, 66, 11, 243, 181, 79, 334 25, 271, 108, 197, 57, 349, 132, 4, 286, 90 163, 232, 46, 314, 121, 78, 207, 33, 275, 149 60, 328, 100, 18, 253, 185, 41, 296, 114, 236 83, 9, 176, 263, 52, 341, 129, 21, 218, 156 305, 69, 195, 38, 281, 124, 245, 87, 13, 202 167, 55, 322, 103, 234, 72, 16, 289, 145, 260 40, 213, 96, 351, 28, 178, 265, 61, 134, 300 80, 222, 47, 158, 10, 293, 119, 250, 65, 191 35, 277, 106, 224, 88, 14, 169, 320, 53, 240 127, 68, 311, 94, 205, 31, 182, 259, 75, 148 22, 298, 111, 44, 336, 160, 85, 7, 271, 216 138, 57, 329, 99, 196, 27, 246, 118, 67, 355 172, 49, 285, 130, 20, 238, 92, 163, 309, 74 203, 36, 152, 268, 58, 345, 105, 24, 227, 141 81, 297, 113, 190, 45, 12, 259, 176, 63, 324 98, 234, 51, 282, 145, 32, 209, 70, 166, 3 251, 122, 43, 315, 89, 197, 66, 154, 29, 278 108, 240, 77, 187, 19, 302, 135, 56, 223, 95 168, 39, 263, 112, 84, 5, 291, 149, 217, 62 133, 306, 73, 25, 244, 180, 48, 128, 200, 91 157
Test 2 output
47, 213, 8, 156, 92, 301, 44, 178, 265, 19, 133, 88, 340, 27, 199, 61, 254, 105, 322, 73, 16, 288, 141, 55, 230, 97, 4, 167, 312, 82, 245, 118, 39, 276, 151, 66, 203, 11, 329, 94, 172, 58, 297, 129, 23, 184, 348, 76, 111, 260, 35, 217, 143, 69, 306, 90, 48, 238, 125, 7, 191, 271, 84, 154, 32, 223, 108, 345, 63, 279, 137, 51, 202, 96, 318, 71, 14, 249, 165, 42, 286, 119, 78, 333, 57, 226, 103, 20, 174, 292, 146, 65, 240, 30, 189, 122, 355, 87, 53, 211, 168, 41, 298, 134, 74, 25, 257, 195, 62, 315, 99, 180, 48, 231, 116, 9, 273, 152, 68, 204, 38, 291, 127, 85, 342, 56, 218, 101, 17, 263, 149, 79, 324, 45, 187, 112, 235, 72, 300, 130, 60, 246, 22, 158, 95, 281, 51, 208, 143, 34, 267, 118, 89, 330, 64, 176, 27, 252, 139, 82, 305, 155, 43, 221, 106, 13, 284, 161, 70, 197, 124, 349, 58, 233, 91, 36, 275, 148, 67, 212, 102, 29, 259, 185, 77, 320, 133, 49, 241, 114, 6, 268, 159, 84, 337, 52, 195, 121, 40, 227, 145, 73, 294, 108, 31, 250, 167, 88, 209, 54, 313, 129, 65, 236, 97, 18, 278, 151, 80, 202, 44, 289, 136, 71, 344, 113, 26, 255, 168, 93, 306, 142, 59, 219, 105, 38, 271, 160, 85, 232, 117, 47, 283, 154, 69, 328, 100, 21, 244, 175, 62, 297, 138, 83, 210, 51, 265, 126, 34, 189, 104, 351, 57, 228, 143, 76, 301, 163, 42, 252, 119, 15, 286, 171, 90, 239, 128, 63, 205, 48, 274, 157, 82, 333, 111, 37, 248, 166, 95, 220, 53, 291, 134, 68, 315, 107, 24, 262, 149, 81, 203, 46, 279, 158, 72, 340, 125, 60, 235, 98, 17, 267, 141, 85, 224, 55, 310, 172, 39
Test 3 output
47, 213, 8, 176, 92, 341, 25, 158, 300, 63, 119, 244, 37, 281, 14, 195, 88, 322, 51, 137, 266, 19, 204, 73, 155, 348, 29, 111, 232, 96, 183, 42, 275, 6, 163, 98, 311, 57, 224, 130, 79, 297, 22, 168, 109, 334, 44, 201, 85, 149, 260, 33, 192, 71, 128, 353, 16, 240, 103, 187, 55, 218, 90, 145, 305, 28, 174, 66, 121, 289, 40, 209, 82, 156, 11, 331, 197, 60, 143, 254, 34, 178, 105, 320, 49, 227, 7, 162, 94, 271, 122, 345, 20, 185, 68, 138, 300, 53, 216, 87, 159, 41, 233, 114, 76, 298, 25, 170, 91, 244, 133, 355, 18, 207, 62, 148, 99, 276, 47, 189, 30, 165, 84, 251, 12, 198, 72, 140, 313, 57, 220, 103, 45, 177, 9, 292, 128, 65, 241, 88, 154, 36, 269, 111, 79, 340, 23, 186, 97, 132, 205, 58, 171, 15, 248, 90, 124, 350, 43, 193, 67, 158, 31, 282, 106, 145, 5, 229, 83, 175, 117, 264, 39, 200, 74, 138, 21, 296, 92, 160, 51, 234, 108, 179, 27, 143, 87, 315, 63, 190, 122, 46, 257, 13, 168, 99, 135, 348, 70, 211, 54, 183, 32, 271, 118, 76, 149, 8, 226, 95, 164, 41, 288, 129, 60, 195, 24, 152, 342, 85, 173, 48, 206, 17, 137, 91, 260, 38, 180, 113, 66, 245, 10, 158, 82, 300, 125, 53, 197, 71, 148, 35, 279, 104, 62, 217, 19, 169, 88, 143, 230, 57, 176, 26, 122, 355, 44, 189, 78, 155, 96, 253, 33, 165, 7, 202, 119, 69, 284, 50, 141, 84, 228, 15, 173, 98, 262, 40, 187, 111, 59, 245, 22, 134, 79, 306, 47, 160, 92, 215, 128, 68, 181, 36, 249, 105, 73, 194, 29, 152, 87, 267, 44, 178, 113
Which rate card was actually used
I had an agent (Grok 4.7 Extra High Fast) compare the three usage events against every Claude rate card in Cursor’s docs, including the Cursor Token Rate.
The Cursor Token Fee part is straightforward: chargedCents = totalCents + cursorTokenFee, and cursorTokenFee is exactly $0.25 per million tokens (input + output + cache write + cache read) in all three events. So the only question is which rate card produced totalCents.
For each rate card, the expected model cost is:
cost (cents) = (input × input_rate + cache_write × cache_write_rate
+ cache_read × cache_read_rate + output × output_rate) / 1,000,000 × 100
Worked example for test 1 (4 input, 14,714 cache write, 9,819 cache read, 12,858 output tokens):
Opus 5.5 regional: (4 × 4.40 + 14,714 × 5.50 + 9,819 × 0.22 + 12,858 × 22) / 1e6 × 100 = 36.598¢
Opus 4.8: (4 × 5.00 + 14,714 × 6.25 + 9,819 × 0.50 + 12,858 × 25) / 1e6 × 100 = 41.834¢
Actual totalCents: 36.705¢
The same calculation for all three tests and every Claude rate card (rates are input / cache write / cache read / output, in $ per million tokens; the percentage is the deviation from the actual totalCents):
| Rate card | Rates | Test 1 | Test 2 | Test 3 |
|---|---|---|---|---|
Actual totalCents |
36.705¢ | 23.761¢ | 18.674¢ | |
| Opus 5.5, regional (+10%) | 4.40 / 5.50 / 0.22 / 22 | 36.598¢ (-0.3%) | 23.003¢ (-3.2%) | 18.114¢ (-3.0%) |
| Opus 5.5, global | 4 / 5 / 0.20 / 20 | 33.271¢ (-9.4%) | 20.912¢ (-12.0%) | 16.467¢ (-11.8%) |
| Opus 4.8 / Opus 5 | 5 / 6.25 / 0.50 / 25 | 41.834¢ (+14.0%) | 26.385¢ (+11.0%) | 20.829¢ (+11.5%) |
| Sonnet 5 | 2 / 2.5 / 0.20 / 10 | 16.734¢ (-54.4%) | 10.554¢ (-55.6%) | 8.332¢ (-55.4%) |
| Fable 5.1 | 10 / 12.5 / 0.25 / 50 | 82.932¢ (+125.9%) | 52.034¢ (+119.0%) | 40.922¢ (+119.1%) |
| Fable 5 | 10 / 12.5 / 1 / 50 | 83.668¢ (+127.9%) | 52.771¢ (+122.1%) | 41.658¢ (+123.1%) |
The closest match by far is Opus 5.5 at the regional rate (global rate +10%), with a mean absolute deviation of about 2%. The remaining gap of 0.1¢ to 0.8¢ per request is something I can’t explain from the public docs. Opus 4.8 rates are off by 11% to 14% in every test, so the Opus 4.8 work in these requests was priced as Opus 5.5, and nothing was split out as Opus 4.8.
To be fair about the numbers: for Opus 5.5 specifically, Opus 4.8 is the more expensive card, so in this particular test I was not overcharged in dollar terms. The problem is that the billing does not do what Cursor said it does. For Fable users it does cost money. Applying the same token counts to Fable, if a fallback is billed at the Fable rate instead of the Opus 4.8 rate:
| Test 1 | Test 2 | Test 3 | |
|---|---|---|---|
| Opus 4.8 rate (what staff said you pay) | 41.834¢ | 26.385¢ | 20.829¢ |
| Fable 5.1 rate | 82.932¢ (1.98×) | 52.034¢ (1.97×) | 40.922¢ (1.96×) |
| Fable 5 rate | 83.668¢ (2.00×) | 52.771¢ (2.00×) | 41.658¢ (2.00×) |
I didn’t re-run this test on Fable, so this table is a projection, not a measurement. But at Fable 5 launch I also saw no Opus 4.8 entry after a fallback, so if Fable is billed the same way as Opus 5.5 here, Fable users are paying about 2x for work Opus 4.8 did.
[SCREENSHOT: Billing analysis, agent chat]
[SCREENSHOT: Billing analysis, canvas]
[SCREENSHOT: Billing analysis, canvas (continued)]
Prompt used for the billing analysis
...
<the three usage JSON events>
...
Compare against the following pricing and infer which model the charges were actually billed at:
- https://cursor.com/docs/models/claude-opus-4-8.md
- https://cursor.com/docs/models/claude-sonnet-5.md
- https://cursor.com/docs/models/claude-opus-5.md
- https://cursor.com/docs/models/claude-opus-5-5.md
- https://cursor.com/docs/models/claude-fable-5-1.md
- https://cursor.com/docs/models/claude-fable-5.md
Take the [Cursor Token Rate](https://cursor.com/docs/models-and-pricing.md#cursor-token-rate) into account.
Draw a canvas and write a report so I can compare them clearly.
Other problems with the current behavior
- You don’t know when the switch happened. Because the chat streams, the fallback can happen partway through a turn, and the banner only shows up after the turn ends. By then the agent may have spent a long run on a model you didn’t choose, and that output may be useless to you.
- Subagents and API usage. I haven’t verified whether any notice is surfaced when the fallback happens inside a subagent or through the API/SDK. If it isn’t, those users have no way to know at all.
Suggested fixes
- Treat the fallback like an explicit, opt-in model fallback, and fail fast otherwise. Only fall back automatically when the request (including subagent parameters) explicitly lists Opus 4.8 as an allowed model, and when it does, emit a visible state-change event at the moment of the switch, not after the turn is over. If Opus 4.8 wasn’t opted into, stop immediately with a clear error so the user or parent agent can decide what to do, instead of quietly continuing on a different model.
- Bill the fallback as Opus 4.8, and show it. Record the Opus 4.8 portion as its own usage event with
model: claude-opus-4-8, priced at Opus 4.8 rates, so it appears in the dashboard and CSV exactly as the staff replies above describe. Please stop giving users billing answers that don’t match what the dashboard shows, and please check past fallback requests that were billed at the selected model’s rate.
Reproducing
Anyone can reproduce this: select a Claude model with safeguards, send a prompt like the template above with a trigger appended, wait for the Switched to Claude Opus 4.8 banner, and then look up that request in your usage dashboard. You can paste the generated numbers into lm.ikale.io or something similar to check which model produced them (if you want a full local result, you need to collect enough fingerprints first).
This has been going on since Fable 5 launched, close to three months ago, and I think everyone paying for these models deserves to know about it.
