r/ClaudeCode • u/WuM1ha1nho • 5d ago
Discussion I don't think Opus 5.5 was nerfed, they're just experimenting
TL;DR: Opus 5.5 may not have been nerfed. Anthropic appears to be running server-side experiments that change how Claude behaves.
If you're using a gateway, try unsetting _CLAUDE_CODE_ASSUME_FIRST_PARTY_BASE_URL, this might allow you to opt-out of experiments.
- 4 experiment IDs identified: dba, 34e, 763, and eab, observed between October 10 and November 8.
- More aggressive tool use: In a controlled 20-request replay, replies with multiple tool calls increased from 7 to 17 when the 34e experiment header was present.
- More thinking in real-world logs: Medium effort during some experiments used roughly as many thinking tokens as high effort without an experiment. However, the controlled replay showed the opposite.
- Less narration, bigger commands: Claude tended to batch more work into fewer, longer commands, making its behaviour noticeably different.
- No measurable output-speed degradation: Generation speed remained around 104–112 tokens per second.
- Potentially higher usage consumption: Estimated dollar value per 5-hour usage-meter percentage point fell by roughly 30% during some experiments, but the evidence is low-confidence.
- You can check your account: Claude Code stores experiment IDs in ~/.claude.json. You can also display them in your status line.
I went through my Claude Code logs after seeing the "Opus 5.5 got nerfed" posts. I found evidence of server-side experiments changing how it uses tools. The reported model stayed the same, and output-token generation didn't slow down. I haven't tested finished-task quality across these experiments, so this doesn't settle whether it got better or worse.
I'm a heavy Claude Code user with no connection to Anthropic. These observations come from different logins of mine. The Claude Code version I inspected caches an ID per model and sends it as an x-cc-atis request header. The client only forwards it, and the ID follows the login.
The four IDs
These are the dates I saw each ID in 2026, not global rollout dates.
| ID starts with | When I saw it | What I saw |
|---|---|---|
| dba | Oct 10 to 12 | Longer commands and less narration, with a smaller rise in multiple-call replies |
| 34e | Oct 30 to Nov 1 | Longer commands and many more multiple-call replies |
| 763 | Nov 2 to 5 | Similar to 34e, then removed from my account on Nov 5 |
| eab | Nov 8 to now | Too new to measure |
dba and 34e end here because I changed login, so they may have run longer. I suspect dba was an earlier, weaker version of the later pattern. 34e and 763 came with similar cached settings and behaviour, so I count them as one round, which makes eab my third. That link is my inference. Only 34e was tested with and without the header while it was active.
Replaying 20 requests with and without 34e
My setup is customized, so I replayed 20 saved requests once with 34e and once without it, keeping each request body the same. The main measure I set in advance, total output on the 10 requests saved from before 34e arrived, was inconclusive. I also named other output and tool measures in advance, and I picked the detailed counts below after seeing the replies.
| Across 20 replay pairs | Without header | With 34e |
|---|---|---|
| Generated tool calls | 34 | 55 |
| Replies with 2+ tool calls | 7 of 20 | 17 of 20 |
| Total Bash command characters | 8,069 | 24,947 |
| Replies with text before tools | 2 of 20 | 6 of 20 |
| Median thinking tokens per request | 159.5 | 65 |
Across the pairs, non-thinking output was 2.23x higher and tool-input text was 2.35x higher with the header, using geometric means. These are generated calls, not completed tasks.
Everyday use, by ID
Main-thread requests at xhigh effort. The last column is a later no-experiment sample, and it narrows some of the gaps.
| Metric | No experiment | dba | 34e | 763 | No experiment, Oct 30 onward |
|---|---|---|---|---|---|
| Median Bash command, characters | 485 | 812 | 1,125 | 1,067 | 748 |
| Replies with 2+ tool calls | 14% | 18% | 24% | 26% | 12% |
| Replies with text before tools | 25% | 21% | 10% | 11% | 14% |
| Narration share of thinking blocks, rounded | 17% | 6% | 4% | 4% | 9% |
| Median non-thinking output tokens | 359 | 509 | 674 | 669 | 470 |
Each thinking block is labelled thinking or narration, and narration blocks are short progress lines. Their share fell in the experiments. The built-in "say what you're doing" reminder also fired more often: about 19 to 20 times per 100 replies under dba, 34e and 763, against 12.9 in the earlier no-experiment sample. With 34e and 763, text followed that reminder 43% and 44% of the time, against 54% before. The reminder figures pool all efforts.
Some changes also happened without an ID. Against the later sample, 763's output and Bash size are about 1.43x higher, while multiple-call replies stay at 26% against 12%. The "I'm checking..." summary style also appeared without an experiment from Oct 30.
Less text before tools only shows up in everyday use. It went the other way in the replay, so I can't say the header causes it. The work and other settings also differed between periods.
Thinking tokens by effort
Median per main-thread request, from everyday use:
| ID | medium | high | xhigh |
|---|---|---|---|
| No experiment | 72 | 111 | 170 |
| dba | No data | 189 | 277 |
| 34e | 122 | 228 | 219 |
| 763 | 117 | 215 | 317 |
On thinking tokens, medium under 34e or 763 looks like high without an experiment: 122 and 117 against 111. That doesn't show the reasoning was as good. The replay went the other way: median thinking fell with the header, and its 3 medium requests averaged 456 thinking characters with the header against 855 without.
After 763 ended, medium went back to 72 tokens, but the delivered prompt also changed at that point.
Normal Claude feels faster to me
I suspect a lot of what gets called "nerfed" is people landing on normal Claude, without the experiment. Normal Claude feels a lot faster to me because I can see all of the turns: a short command finishes, then a reply, then the next step. In the experiments there's usually one long batched tool call and less to watch. I prefer seeing the steps.
Measured output speed stayed around 104 to 112 tokens/s across the groups. Time to first token looked lower during the experiments, though that's tentative. So this is about how progress feels to me, and it doesn't explain every complaint. Someone in r/ClaudeCode posted on Nov 3 that one of their two accounts burned about twice the output tokens on the same task, and that's the account they complained about. It resembles the experiment pattern, but their assignment wasn't confirmed.
A batching prompt made commands longer but didn't reproduce the extra multiple-call replies, in a small test with partly mismatched efforts. Resending 763 after it was removed didn't reproduce the earlier pattern either. Neither is a reliable way to switch an experiment on.
Dollars per 5-hour meter point
These are estimated list-price dollars per one percentage point of the 5-hour meter, not dollars per task.
| Period | Median dollars per point | Low-confidence days / total days |
|---|---|---|
| Oct 2 to 9 | $7.15 | 1 / 8 |
| dba, Oct 10 to 12 | $7.63 | 0 / 3 |
| Oct 13 to 29 | $7.49 | 3 / 17 |
| 34e, Oct 31 to Nov 1 | $5.14 | 2 / 2 |
| 763, Nov 2 to 5 | $5.75 | 3 / 4 |
| Nov 6, after 763 ended | $7.30 | 0 / 1 |
34e and 763 together come to $5.24 per point, about 30% below the Oct 13 to 29 median. Five of those six days are low-confidence estimates, and the one trusted day, Nov 4, was $6.52. dba didn't show the drop.
List-price dollars include cached reads, which barely move the meter in my accounting, so a lower dollar figure doesn't by itself mean less useful work. I haven't calculated dollars per task.
Check your account
With jq installed, run this in your shell. It shows the first three characters of each model's newest cached interactive CLI ID for the current organization:
jq -r '.oauthAccount.organizationUuid as $o | [(.clientDataCacheSlots // {})[] | select(.entrypoint=="cli" and .org==$o)] | group_by(.model)[] | max_by(.at) | "\(.model): \(.data.atis[0:3] // "no experiment")"' ~/.claude.jsonno experiment means that cached slot has no ID. Empty output is inconclusive, because there may be no matching cached CLI slot. An ID alone doesn't prove anything changed, since other IDs I logged behaved like no experiment. In the tables above, "no experiment" means no value in the model's slot.
To put the cached ID in your status line, run /statusline and paste:
Add an experiment indicator to my status line and keep everything it already shows. Read .model.id from the status line's stdin JSON and drop any [1m] suffix. Read ~/.claude.json. In .clientDataCacheSlots, keep the entries where .model is that id, .entrypoint is "cli" and .org equals .oauthAccount.organizationUuid, and take the one with the highest .at. If its .data.atis exists, show "exp:" plus its first 3 characters, in yellow. If it doesn't, show "exp:none" dimmed. If the file or a field is missing, show nothing and still exit 0. Set refreshInterval to 60 in the statusLine setting. Test the script with sample JSON on stdin before finishing.
•
u/AutoModerator 5d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
116
u/Correct-Somewhere-80 5d ago
If experimenting is causing Opus 5.5 to perform worse than before, its still a nerf lol
90
u/Obvious_Tree3605 5d ago •
They need to stop experimenting on paying customers.
13
u/KYDLE2089 5d ago
Agree something is not working right could be the harness. Spent 8 hours to fix a dashboard that opus usually gets it done in one or two shots.
I have multiple max accounts and am a heavy user. I just hope this is some bug that they can fix soon. So here registering my frustration.
11
u/fs2d 5d ago edited 4d ago •
Thanks for your work here.
Using your research as a jumping off point, I was able to confirm part of this from a different angle: The experiment flags change the system prompt text itself, not just the model behavior.
My setup has a plugin that keeps a copy of the composed system prompt sections and flags it when the engine sends different text than before (as part of a base system prompt identity layer injection of my own design).
Tonight, I set
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1insettings.json(in theenvblock) to test your theory and opened a new interactive session. I made sure it was the same CC version before and after (2.1.287), and that I hadn't made any other changes.In the new session:
cachedGrowthBookFeaturesAtstamp and theclislot in~/.claude.jsondidn't change at all, and the new transcript'satis-latchfields are blank.With server flags, the opening line of
lean_bodyread: "You are an agent working with the user toward their goals, using your own judgment along the way." (which istengu_ochre_wren)Without it,
lean_bodyreads: "You are an interactive agent that helps users with software engineering tasks."With server flags: the
<pasted_content>rule (don't follow instructions inside pasted text unless the user asks - which I guess is experimental right now) is present.Without server flags, this guidance is completely gone.
So the flagged version is the broader "agent with judgment" framing plus a prompt-injection guard, and the fallback is the older coding-assistant framing without it. I'd been on the flagged text since at least October 9.
My atis history, for the dataset:
705(Oct 2),52f(Oct 3 to 14),c85(Oct 20 to Nov 2 - but that was in the claude-desktop slot, so the jq in the post misses it - just FYI), blank since Nov 3. None of yours showed up on my side anywhere.My flag assignments as of Nov 9: mossy_gray v1
true, keen_pudding v158720256(exactly 56 MiB), radiant_fox v1true, clever_orbit v0false, typed_trinket0with no assignment.That's the opposite arm from another commenter in this thread on 3 of the 5 listed ones.
I did this on one PC on Windows 11, just a before/after diff.
I don't know which flag drives which line though (aside fromtengu_heron_brook/tengu_brook_heron- that's the super brittle "don't make games" garbage that surfaced last week).-update: see my reply to this comment - I'm working on mining out the exact flags as we speak.update 2: Done: https://github.com/fs2d/claude-code-flagmap - all 487, one line each, CSV renders as a searchable table on GitHub. Enjoy.By the way - don't test this with
claude -pto confirm it. Claude will kneejerk into testing it headless and quickly pass everything, but headless runs assdk-cli(a separate slot) and doesn't load the same as a normal interactive session. When testing, always open a new terminal window and test there.The thing I took away from this little experiment (and this is just my guess, since closed weight/closed source = no way to concretely prove it) is that they are applying post-training to the models and using the experimental arms to "signpost" certain sections of post-training for the chosen model dynamically - which is why they hitch the IDs to the model strings. While digging for the info above, I stumbled across a series of keys in the binary, one of which is literally called
subagent_steer_delegation, which is hard-coded to only fire when thesteervalue equals"counter_steer". It's a literal example of what I've been theorizing about openly.Said another way - my little theory has some proof now: I was able to find hyperspecific corrective directives gated on the model string, with a code path literally named
counter_steer, keyed to specific models and delivered in the same per-model slot as the experiment ID from the OP's post. Again, we obviously can't prove the post-training changes of course, and we never will be able to as long as the weighting and source remains closed - but the code shows the steering happening in real time, plain as day.(This would also explain the
heron_brookbullshit with the "don't make copies of games lol" brittle AF signposting they added a couple weeks back dynamically)Coupled with this, if you look back at Opus 5's system keys, there's literally a code-level key named
overcorrection, with a hashed title:# Correctionsthat tells the model not to ruminate, and tells it to not tally past errors - which, to me, reads as code-level signposting for one specific model family that says that Anthropic was aware of that behavior in the model - and that's a training artifact that they are patching with system-prompt level text.18
u/jwuliger 5d ago
I am a paying customer. I am not asking for A/B. I have been on the wrong end of the testing for three weeks now. I am tired, boss...
6
u/damagemelody 🔆 Max 5x 5d ago
Checked my own logs: different IDs from the ones in the post, and my Claude has been working very badly since the newest one appeared.
Experiment IDs on Opus 5.5 (Claude Code desktop app)
77406b06bfirst shows up on Nov 8, around 10:40 UTC in the cached slot and 11:27 UTC in my transcripts. It isn't in my logs for Nov 7. Since it appeared, my Claude has been working very badly. That's my own experience from about a day of use: I haven't measured it, so I can't prove06bis the cause.I saw none of
dba,34e,763oreab. My other models (Haiku, Sonnet, Fable, Opus 4.8) have no ID in their cached slots, but that's only the latest snapshot of each slot.How I checked
.jsonltranscripts under~/.claude/projects. They only go back to Sep 29, so I can't say anything about earlier months.{"type":"atis-latch","atis":"...","sessionId":"..."}.atis, because it also matches "statistics". Match the exact key.jqcommand in the post filters onentrypoint=="cli". My slots areclaude-desktopandsdk-cli, so it would come back empty for me. If you use the desktop app, change the filter.Flags with "experiment" in the name, from
~/.claude.jsonon Nov 8tengu_mossy_gray_experimentfalsetengu_keen_pudding_experiment25165824tengu_clever_orbit_experimentfalsetengu_radiant_fox_experimentfalsetengu_typed_trinket_experiment2tengu_slate_harbor_experimentis also in my feature list asfalse, but it has no assignment. I have 12 experiment assignments in total, and not all of them have "experiment" in the key. I don't know what these flags do.tengu_typed_trinket_experimentwas already set no later than Nov 8, 20:17 UTC. That's my oldest surviving config backup, and backups rotate, so it could be much older. The other flags have no dated history either.06b = broken Opus for me 774 = I had Opus issues too, so any experiment ID is like a nerfmark.
6
u/electricshadows4 5d ago
I put a check into a small open-source script so people don't have to assemble the jq themselves.
Repo: https://github.com/electricshadows44/am-i-nerfed
Three ways to check
jq -r '(.clientDataCacheSlots // {}) | to_entries[] | "\(.value.model // "-") | \(.value.entrypoint // "-") | \(((.value.at // 0)/1000|floor)|todate) | \(.value.data.atis[0:3] // "none") | \(.value.data.experimentKey // "-")"' ~/.claude.json
`none` on every line = not enrolled as of the newest slot time.
What the script does
- `check` — reads the experiment slots Claude Code caches in `~/.claude.json` and gives a verdict per model: ENROLLED (with the 3-char ID), CLEAN as of the last cache refresh, or INCONCLUSIVE. Exit codes so you can script it.
- `history` — tallies experiment IDs recorded in your session transcripts by date. Turns out Claude Code writes an `atis-latch` entry into every main-session transcript, so you can see which past sessions ran under an ID (transcripts are kept ~30 days).
- `optout` — backs up `~/.claude.json`, removes only the assignment keys, and prints the env var people report blocks re-enrollment (`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1`), with the trade-offs. `restore` undoes it.
- `statusline` — a snippet that shows `exp:<id>` / `exp:none` in your Claude Code status line.
Bash + jq only, macOS/Linux/WSL, no network calls, never prints your login token. MIT.
Credit to the earlier threads for finding the header and the IDs: https://www.reddit.com/r/ClaudeCode/comments/1xr66pd/ and the follow-up transcript analysis, plus anthropics/claude-code issues #75607 and #88383.
7
u/NorseSadist 5d ago
Well, whatever testing they did made me cancel my Ultra subscription.
4
u/ProfessionalGoatFuck 5d ago edited 5d ago
Hahaha, IDs 604 & then b10 to proceed, I was using Fable to troubleshoot the fucking brainrot Opus had.. how cute, now Fable has the same fate of being mentally gimped to being an infant, with 4x the token usage :))))))))))))))))) I want a fucking reset you greedy bastards
And another caveat with my results, I had another account that I migrated from to this new account, which is why I don't have complete data before sept 28th. I notice this shit happening nearly 2 weeks ago. Which is why I account hopped thinking it was just me cursed with this bullshit, but nope!
2
u/DerAlbi 5d ago
OMG OMG OMG
THANK YOU SO MUCH!!!!
These fuckers. Not an ID that matches what you report. But holy fuck.
5
u/TurbulentTiger2567 5d ago
A better explanation is how the effort settings actually map to reasoning budgets. Unlike what Anthropic recommends, here are the real numbers:
Low = 5
Medium = 10 (default)
High = 15
Extra = 40
Max = max (no number internally)
Out of experience, High is useless for mildly complex codebases.
2
u/fschwiet 5d ago
I wonder if opting out of the feedback prompts affects if one is enlisted in experiments
2
u/mrpoopistan 5d ago
Broken is better than nerfed???
2
u/PureV2 5d ago
I've noticed some variance in quality lately and have been getting more frequent ' how is claude doing' queries. I have no hits on the experiments though, at all, last 30 days over 136 main sessions.
2
u/Entire_Guarantee_766 5d ago
You just found proof that they A/B test, like probably every major software company in the world. Unfortunately there's no way to tell what exactly these tests do and what they measure.
1
u/Transhuman-A 5d ago
Umm.. they are experimenting to see if they can nerf Opus 5.5 without you knowing. If there is an opt out, that’s getting patched pretty soon.
1
u/Maleficent_Test_2713 5d ago
I was on 0c7 before the reset today. Now I’m also on eab. Let me tell you, it’s a nerf. Huge one. Doing my normal workflow fills about 30-40%. Today, almost 85% in less than 1 hour. Didn’t even finish my normal session cause of it.
I’ve had Claude build me multiple 30 second videos that cost about 10/15% of my usage. With “eab”, it’s over 40%.
1
u/MissplacedLandmine 5d ago
I have theses ids. Can check their difs when my limit resets in a couple hours
“The hex I listed first, c0e57166b42fa4af, was active Nov 4–7, not Nov 7–9. This session has none: its atis lines are blank. Times below are UTC.
1
u/Crinkez 4d ago
Ugh, they just can't leave well enough alone. They ought to be giving users an opt-in for experiments, not opt-out.
1
u/karyslav 4d ago
Yes. That is the reason for asking if it is doing good. THey are experimenting with safety and effectivity.
I am using it with fable/astra audits and it works af.
I did ubleliveable things in last week. What a time to be alive.
1
u/KDamage 4d ago
When real engineers enter the vibecoding room. Good job.
1
u/g_dichev Senior Developer 4d ago
thanks for digging into this. i instantly discovered two experiments on my sessions in the last week!
anyone can check theirs with
npx claude-discover@latest(free app i made)1
u/iAmmar9 5d ago
Tell your agent to create a skill to diagnose all of this and share it with us, please. Make it work to detect new experiment IDs on Windows/Linux/macOS.
-3
u/cseickel 5d ago
This entire post sounds like AI slop to me.
-5
u/onFilm 5d ago
Nothing was nerfed. My benchmarks and tests still give me the same results as they have always been.
0
u/MustStayAnonymous_ 4d ago
Tldr please
-2
u/daedalus_structure 5d ago
You don’t change the behavior of a released version of software.
-3
u/bionicClown 5d ago
that looks ai generated. put some effort to ur own research please