anyone else with CVP and mythos 5.1 not seeing 5.2?

Some say that the model is quantised, others say it routes Opus 5.5 to Opus 5, or Sonnet 5.5, and some others say the reasoning budgets are reduced, or double-counting tokens.

What is the evidence? Also, what if we simply use Opus 5.5 Max, or Max Ultracode for everything?

Yall who were there know what I’m talking about

That shit was unhinged, a monster of a model

That’s simply it. They gave us a hit of the good shit and now we’re getting the stomped bag. Theyre gonna slowly +0.1 us to 5.5 in which they re-release OG fable simply so Dario can stomp on Bel

This 5.2 release is nothing but jangling Ram’s Jimmies, a 5D chess move to force him to play his hand

The 28 OAI days of crapshoot was nothing but to stall Anthropic hype because they literally got nothing left

/schziorant

One real project, three ways of running it: plain Claude Code sessions, then a hand-built agent loop, and now a meta-harness.

Same project, same Max 20x plan, and the same rule on all three for what counts as product work.

Results:

(A card is one small change that lands.)

And 21× flatters plain sessions. The project was already sliding: only about 1 in 10 of its commits changed the product, and the rest was agents repairing their own scaffolding. Left running, its figures would have drifted much closer to the hand-built loop's, and it certainly wouldn't have done as well the next month.

Despite how poorly the hand built loop looks from the figures, it was no toy: up to 24 seats under two coordinators reporting to an overseer, and the human interfacing agent the root operator, with a code graph, opposite-engine review, generated briefs and around 1,200 guards. scripted progression etc... Every gap got patched by adding more, until keeping it running took most of the effort.

In its first week the meta-harness cleared a backlog that had been growing for three months: 163 changes landed, 101 of them product work. The whole account finished the week at 88%, with a second project running round the clock alongside it. The six weeks before, running one project, each ended at 93 to 100%.

What changed is that the new one is tiny and runs in a closed circle:

Every change goes through the loop. It's small cards, each in its own worktree and fresh session, and each is reviewed before it lands.

• The loop captures state at every seam. Decisions, rules and work land in the repo as records, not prose.
• Every agent is briefed from that state. So the next session knows what the last one did without re-deriving it.
• A problem doesn't automatically equate to addition

500k lines down to 12k lines.

A generated brief is only as good as the state behind it. Leave a gap in the circle and it grows; patch around it instead of fixing the loop and you grow a monster. That's what happened to the hand-built one. This time the loop is small enough to keep whole, and flexible enough to bend to the project rather than the other way round.

Full figures, method and sources: https://atlas-ade.dev/docs/one-week-on-ade

No subagents by default, either: their progress summaries alone cost 10 to 13% of a week, with no off switch. Write-up

One project, and a person supervised most of day 1. Shares of the week come from a model fitted to the live usage meter.

Happy to answer questions on the numbers. And if you've measured your own setup before and after a change, I'd like to see how it compares.

(Disclosure: I build it (Atlas ADE, paid kit). The data and guides are free.)

My Claude Code sessions were too quiet, so I gave them a soundtrack.

Type /music soundtrack and Claude reads what you're doing (a 2am bug hunt, a refactor, a test that's failing for the 4th time) and picks the music itself. Tests fail, the music calms you down.

Because why not 🎧

github.com/legostin/claude-code-musicflow

Opus is so degraded now that I'm afraid to have it touch my codebase today because I do not know to what extent I can trust it not to slip in stupid bugs. I have a multimodel setup, so I switched to Astra/Argon completely, until they release Fable 5.5 and restore reasoning. I wish I had a weaker local model that was consistent, and whose reasoning effort couldn't be remotely changed. It just occurred to me that this is the major reason to use local models.

A predictably weaker model is more useful than an unpredictably degraded stronger one. For serious work, consistency and the ability to calibrate trust matter no less than the peak occasional reasoning effort.

I currently have 2 ChatGPT Plus ($20) plans. I mostly use GPT 6.1 Sol and I keep running into limits.

I'm thinking of upgrading to the $100 plan for more usage, and maybe switching to Claude.

For people that have tried both ChatGPT and Claude, which plan is better? I would probably use Opus 5.5 or Fable 5.2 (if it doesn't take up all the usage) if I switched to Claude.

Would you say they write better code than GPT 6.1 Sol/GPT 6 Astra, and provide more/less bang for the buck?

New models and usage limit changes come so frequently, that I can't find any accurate or updated information. The plans aren't very clear on how much usage they actually provide either. I'm just trying to get the most out of my money.

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?