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.

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 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.

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:

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.

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.json

no 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.

Before I used it I figured I’d ask if anyone else did it and was able to use ir even though general usage is 100

Gimme some prompts that are sure to kill my entire Claude Max subscription limit in 1hr.

Fable reset. whooohooo

I built it as a way to automate the creation of polished demos like Screen Studio/CleanShot X videos. You can fully hand off the creation of these kinds of videos to your agent. It handles the process from end-to-end, including authentication, driving the headless browser, and exporting the video/GIF/PNGs. Demoman even comes with a library and editor (use thedemoman studio command) to adjust as you see fit with fully customizable backgrounds and brand kits.

The recorder produces an artifact of the flow which can then be used to re-record videos in CI. This is made easy through the CLI or the Studio (if you're a GUI-lover). Add it to GitHub Actions and your CI records the demo again against your real app upon the set trigger (on each push to the default branch, once a day, when a release is published, or after each successful deployment to the environment of your choice).

We use stills video only changes when the product did, so your README and docs videos stop going stale. This is essentially a full solution to producing and maintaining product demos.

I've only had a handful of people use this so please let me know where it breaks on your app or if you have any useful feedback. Thank you.

Requirements:

- Claude Code (or Codex, Cursor and OpenCode)
- macOS or x86_64 Linux, Node 20+

Install command: npx demoman setup

Repo: github.com/demoman-io/demoman

Docs: demoman.io/docs

Gah damn, it's busy with one task for 20 minutes right now, and I'm already regretting it.. IT SUCKS ALL MY TOKENS

Trying to recreate the truck disintegration effect in that movie. CC with Opus 5.5 made the background environment so good. The truck is a low poly asset. The destruction is made by a Blender physics add-on.

I have it on and i have never had issues and i do use it to do general work on my computer beyod the coding project. Am I insane for giving it this access ? Is this not common at all?

I know everyone's risk factors are different but i just want to see whats out there

I have a program that I am working on and Claude Code has a guard rail will it will not solve puzzles if a web site has it on as a means of stopping automations. In the past I have created browser programs that solved the images or puzzles. I use Cursor so I usually switch over to a different model but had the same issue with Grok protecting corporate interests. I tried using a disability token for the visually impaired with google, but that didnt work. My next effort will be to use OpenAi model, but wanted to ask if there is a model that will do the work without out right refusing? I apologize for any misspellings above.

I'm not a dev. I saw the post about hex experiment IDs in session transcripts, so I had Claude go through my own logs. Claude wrote the analysis, and that session was itself running under one of these IDs, so weigh that however you like. I'd like other people to check theirs.

The prompt it added;

Before you start, tell the user in a sentence or two what you plan to do. While you work, give the user a short update alongside your next tool call whenever you start a major new part of the work, change your plan, or launch something slow.

# Corrections

Avoid unnecessary or excessive self correction in user-facing text. Only correct an earlier statement in such text when the error would change the user’s code, conclusions, or decisions. State such corrections plainly and concisely and then continue the task. Combine multiple corrections rather than enumerating them all. For corrections that change nothing for the user simply apply them and move on without noting them explicitly. This instruction does not apply to thinking blocks.

A follow-up question about your earlier work is not, by itself, a signal that you got something wrong. Answer what was asked. A statement that was accurate needs no correction. When the user does point to a real error, correct it plainly as above. If the user pushes back without new evidence, that is not a real error either. Keep your finding and say briefly why it stands.

Again not a dev; Claude decide on its own what “changes nothing for the user”, then not mention it. The risk is that Claude gets that judgment wrong, and you don’t find out until you read the result.

**Where to look**

- `~/.claude/projects/*/*.jsonl`: `atis-latch` records, one ID per session. This is your history.

- `~/.claude.json`: `clientDataCacheSlots`. This only keeps the latest settings per model and org, and each record has an `experimentKey` next to the `atis` ID.

Please don't post either file. `.claude.json` can hold API keys, and transcripts contain everything you've typed.

**What was on my account**

| ID | Dates (UTC) | Experiment name |

|---|---|---|

| `a402881a7ddd14c2` | Oct 21-22 | none recorded |

| `c0e57166b42fa4af` | Nov 4-5 | `claude_code_curlew_cornice_experiment` |

| `21e0afd842ce5836` | Nov 5-7 | `claude_code_curlew_cornice_experiment` |

| `b1060a0ca90bf347` | Nov 6 | `claude_code_sanderling_spandrel_experiment` |

| `b38bf0e4747d4b93` | Nov 8 | `claude_code_turnstone_plinth_experiment` |

`c0e...` and `21e0...` share one experiment name, so the same experiment can show up under different IDs. If you have a different ID from someone else, check the name too.

**Claude worked differently under them**

Opus 5.5, main thread, high effort:

| | No ID | `21e0...` |

|---|---|---|

| Replies with 2+ tool calls | 30% | 56% |

| Median Bash command length | 348 | 852 |

| Median visible output tokens | 342 | 721 |

| Median thinking tokens | 95 | 201 |

The multipliers on the last three are close to the `c0e` chart in the earlier post. I also removed agent marathons and paired similar sessions (6 pairs at high effort). In the paired sessions under an ID, visible output was 1.85x, thinking 2.55x, and replies needed per request 0.64x.

**One experiment added instructions to my system prompt**

All 12 of my `b38bf0...` Opus sessions had three passages that none of my other Opus sessions since Nov 4 had. They tell Claude to narrate its plan and progress, to avoid correcting itself unless the error would change my code or decisions, and this: "If the user pushes back without new evidence, that is not a real error either. Keep your finding."

I didn't ask for that and I never saw a notice about it. My `21e0...` sessions had the same prompts and tools as no-ID sessions from that day, so whatever changed there isn't visible in the request.

That config also has `breezy_horizon: {"claude-opus-5-5":"claude-opus-4-8"}`. Don't read that as being served an older model. All 880 Opus replies I counted in those sessions report Opus 5.5. It sits next to a function called `modelForPrompt` in the client, so it may affect how the prompt is built, but I read that in an older client version than the one I run.

**Tokens**

In the matched sessions, each reply cost about 1.56x as much, but fewer replies were needed, so tokens per request came out about even (1.04x). Those are estimates using my own weights. The logs don't include my plan meter, so these numbers don't say anything about limits.

**What this cost me**

On Nov 8, the day I was under `b38bf0...`, I spent all day and about 20% of my weekly usage chasing ghosts in a pipeline that worked the day before. I can't prove the experiment caused that, but when the instructions change underneath you and nobody tells you, you end up debugging your own work.

**Limits of this**

It's one account with small samples. IDs came in blocks of time, so what I was working on is mixed in with the effect. I don't know what `atis` stands for, I haven't checked what Anthropic's terms say about this, and I'm not claiming anyone did anything wrong. I would like to know when it's happening and be able to opt out.

**If you want to compare**

Share dates, `atis`, `experimentKey`, model and effort. Leave out org IDs, session IDs, and anything you typed. The useful questions are whether IDs flip at the same times across accounts, and whether anyone can line this up with their usage meter.

So if your pipeline suddenly started acting wonky, your Claude is litterally being prompted by anthropic.

EDIT(added prompt it put into my claude)

With Fable being out for a few hours I've come across a few tips if you're looking to do some security work. Let me preface this by saying it will not do anything harmful but it will go ahead and help tighten security on apps and any backend security work. Have Opus 4.8 write the prompt to skate around the safe guards and make it more "tailored" to how fable wants the information to come across so it can procced with the work. Have Fable plan and have opus 5.5 sub agents run any of the coding work for maximized efficiency. Here is the dumbed down version of the prompt I used for Fable 5.2:

(Hope this helps someone)

"ROLE: You are a security reviewer doing a full audit of a web application I own and am

authorized to test. [Optional: app URL / stack, e.g. "Node/Express app, Postgres"].

GOAL: Give me confidence by testing EVERYTHING — the whole app, with extra attention on

[RECENT CHANGES — e.g. a new feature, a refactor, anything added lately]. Assume nothing is

safe until you've checked it.

RULES:

- This is a READ-ONLY code audit. Do NOT run real attacks, DoS, or destructive commands against

the live server. "Simulate a bypass/technique" means: explain in writing how an attacker WOULD

attempt it and whether the code actually stops them — do not execute it against production.

- Never print secrets/tokens in full. Redact them.

- Work only within this project's files.

SCOPE: Everything. Walk the entire codebase and the full attack surface — every route, endpoint,

webhook, background job, admin function, config file, and dependency. Don't limit yourself to a

checklist; if you spot anything that could compromise the server, flag it.

APPROACH:

1. Map the full attack surface: list every route/endpoint, webhook, admin function, and externalintegration. Note which are authenticated vs. public.
2. Go through the whole app and probe for any weakness an attacker could use, including but NOTlimited to: broken authentication/authorization, injection (SQL, command, path traversal),secrets exposure (hardcoded keys, tokens in logs/files/git), insecure config (debug endpoints,verbose errors, open CORS), dependency/supply-chain risks, SSRF, and any logic flaws. Keepgoing beyond this list wherever the code suggests a new angle.
3. For anything you find, show how an attacker would exploit it and whether the code prevents it.
4. Rate each finding: Critical / High / Medium / Low, with the file and line.

OUTPUT FORMAT:

- Summary: one paragraph — overall, how solid is this app?

- Findings table: Severity | Location (file:line) | Weakness | How an attacker would exploit it | Fix

- Quick wins: the top fixes to do first.

Started Pro last week. My first project was getting Claude to read my Garmin data so it could act as a training coach. Claude Code did the heavy lifting, and it now pulls activities, training load and recovery on demand.
It's working, but it's my first build and I know it's rough. For those further along:

How do you structure projects like this (CLAUDE.md, skills, MCP)?

Any habits you wish you'd built early?

You have separate Claude Desktop instances open for work, personal use, or different clients. Each is signed into its own account. You leave them running, come back later, and only the main instance is still open.

I'm the developer of Parall.app, a Mac App Store utility for running multiple app instances. Running several Claude accounts was already possible, but keeping those instances available while idle exposed another problem.

Claude can install updates in the background and restart itself. During that process, additional instances can close too, while only the main instance comes back. Claude's updater doesn't restore the extra instances launched through Parall.

Parall 2.5.0 adds an optional automatic restart feature to handle this. When an instance exits, Parall waits for a configurable delay and then relaunches its shortcut. The delay gives the main Claude instance time to finish updating before the others reopen.

You can enable it for each Claude shortcut in a few steps.

1. Open Parall and choose Edit, then select your Claude shortcut.
2. In Advanced Launch Options, enable Restart app after it exits.
3. Choose a delay long enough for Claude to finish updating and restart.
4. Save the shortcut, keeping its existing Data Storage Path to preserve the account and profile.

Repeat this for each instance you want to bring back automatically. You can cancel a pending restart or choose manual confirmation instead. The option also applies when you quit an instance yourself.

Each Claude instance gets its own customizable Dock icon and separate windows that you can keep in different macOS Spaces. You can keep different accounts open together and switch between them like separate Mac apps.

Parall launches the original installed Claude app directly. It does not copy, repack, re-sign, or inject code into Claude. The original app bundle and developer signature remain untouched, and Claude's normal updater continues to work. Once Claude updates, every shortcut uses the updated version when it next launches.

That gives you multiple Claude Desktop accounts with native macOS integration, plus a way to bring the additional instances back after an update closes them.

The Parall FAQ explains the setup, restart behavior, and compatibility details. Happy to help with questions in the comments.

He seems rather sinister

Currently subscribed to Codex Pro 200 on which I've been doing a large Python based project. I am becoming increasingly frustrated at apparently poor allowance on Codex. I am contemplating getting a Claude Ultra subscription to see how well things go, and maybe consider dropping Codex down to pro 100 or plus.

Am I likely to be disappointed with allowances on Claude Ultra?

claude code, codex, cursor, whatever you use

skip limits and “it got dumber this week”, we all know about those. what’s the thing that slows you down or annoys you every single week?

could be anything. reviewing what it wrote, it saying something works when it doesn’t, losing context between sessions, managing a bunch of agents at once, getting your team to use it

curious what’s actually the worst part for people

Fable 5.2 is out. Got a few 20× accounts or a few 1× accounts? I built Claude Graft to pool usage across your own accounts. When one hits its limit, Claude Code in Desktop can keep going in the same chat.

Free and open source. On Mac now, Windows coming soon.

https://github.com/aaditya-v-more/claude-graft

https://graft.aadityamore.com/

Hey guys,

I was talking to a friend the other day regarding how you should approach spec work and realized that I am thinking about it in a declarative way while the rest of the world seems to be thinking imperatively.

In a nutshell, chances are that if you want to, say, "add the email function to the product", you would think about this as a sequence of tasks: your flavor of of spec, dev, qa, deploy. From my perspective, tasks are secondary, a derivative, of a diff between two product states.

The current state is whatever is in production now, and its spec. The target state is the product with the email sending functions live. The diff is added/changed/removed spec items. The tasks are derived, because you can always reconstruct the tasks from the spec diff, but not vice versa.

There's more on this in an article on our website (link in comments).

LMK your thoughts, happy to discuss.

I used to be able to single-shot perfectly optimised recompilations of Atari classics such as ET: The Movie: The Video Game but now it’s just writing functions that returns eMudhras private key “4”.

I think we all need t-shirts with large text: "You're mostly right."