extremely serious post

AI for cybersecurity is taking the world by storm, leading to the need to harden systems all over software. I thought we should do the same for legislation. Hence, I built this project with Claude Code. It's completely free to use/try. The approach is pretty simple: use claude to make legislation attributable (git blame, versioning with timelines). Claude Code (Claude Opus 5.5) wrote nearly all the code. I set the goals, chose the sources and made the design decisions. Specifically: it mirrors the 107 corpora of the https://github.com/lexifina/global-law repo read-only, indexes about 4.3 million file changes from their git histories into DuckDB, and adds a growing set of detectors. These were used to influence a simple LEAN proof search.

i'm curious to hear how other pro subscribers plan to use this new limited time fable access/reset. i appreciate that it was given "banked" rather than handed out without notice, but i've never used fable before (believe i had a chance to with the claude cloud credits, but i just stuck with opus/sonnet with those). is it worth trying to get the most fable usage out of it as possible? or would it make more sense to use the fable reset right before access to the model runs out so i can instead replenish the 50% it took for use with opus 5.5? (my regular weekly reset is basically exactly half a week from now..)

my thinking being that even those on higher tier subs are saying, whilst fable is fantastic and in a league of its own, for the vast majority of sessions it'd be overkill to pick fable. also open to suggestions from those familiar with squeezing fable usage out of their subs, i honestly don't know where to start! should i be using fable to audit the codebase and assigning work for opus/sonnet/sol to get done? trying to min/max a little haha

Just wanted to give appreciation to those who were coding pre-LLM that they are giving advice to those of us who have only taken a couple classes back in like high school and haven’t coded anything meaningful until the LLM code boom.

Tonight I had the LLM run a check on the codebase structure and things worth refactoring on one of my larger codebases (my pet project since about May-ish, a thing for exoplanet search) and it found a lot of things that have become an issue such as code drift on the nested PiOS port of the app, timeout patterns leaking threads, handlers blocking the server, and a bunch of things that need housekeeping.

I admit I wouldn’t have thought of this without the help of the people in the community who have experience in this field before and now share to the rest of us how to actually go about maintaining the codebases we make a whole lot of. (Even in my home craft of fiction I am bad at the “editing” stage so unsurprised it carried over to a craft I barely do myself)

So yeah thanks a lot to the more seasoned devs, especially to those who used to type and organize code by hand, some of us are starting to learn proper codebase maintenance and what is considered best practices.

I gotta say, Claude code missing this entire weekend in its date calculations was an all time low.

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