Weekend post-mortem, FINAL: the best thing that ever happened to me was running out of Claude usage — four days on Codex delivered what two years on Claude could not

Locked out of Claude on Friday. Four days on Codex and Gemini exclusively — same machine, same repository, same 12-step pipeline I have been building for two years. They delivered what Claude has been unable to deliver in over two years.

If you have any sense, you should be having an all-hands meeting about this.

I mean that as advice, not as an insult. What follows is my fifth and last post-mortem here. Unlike the first four, I can show you the arc — my own filings on this tracker, with dates, against what four days on a competitor's product produced.

The arc, from my own filings

#54393 — April 28. "12 multi-agent coordination bugs surfaced across a single autonomous-overnight run." That was the first one. Four months ago.

#76987 — July 12. "Day twelve since my Fable access was restored on July 1, and I still do not have my 46 days of work run through the process I asked for."

#79247 — July 19. "1 of 46 dates has reached step 2 and been signed off — and only step 1, which just reads CSV files, actually works. Nothing else does." Also in that post: 7,000+ markdown files and 15,000+ commits since January 1 — after two purges. A 1.86 TB drive filled twice. 228 GB across 72 git worktrees. Roughly 75% of that week's usage spent fighting drift instead of doing work.

#84002 — August 5. I cancelled two of three plans. Two years in.

(Two more in the same genre, titled as rants rather than post-mortems, but they carry the receipts this one cites: #77505 — July 14, and #81385 — July 26, where I was locked out of the model I pay for for computing effect sizes.)

August 8–10, Codex and Gemini only, because I was locked out of Claude. The 46-date data build completed in 4 hours 23 minutes — 46/46 parquets, 46/46 producer receipts, zero failed dates, every artifact and receipt SHA256 independently recomputed and matched. That same build had been running three days unfinished under Claude, because it had been launched against a 37-date roster with a broken dependency calendar and spent days pulling targets guaranteed to fail their own gate. Nothing noticed.

The pipeline frontier moved from step 2 to step 8.

On July 19 I reported one of 46 dates had reached step 2. Three weeks later a competitor took the same repository from step 2 to step 8 in four days.

What Claude actually produced in two years

Before anything else, the output. Not the work — the output. These are measured, most of them from my own earlier filings on this tracker:

| | |
|---|---|
| Markdown files generated | 220,000+ at peak, ~94% duplicates · 29,813 still on disk today |
| Markdown created since Jan 1 | **7,000+ — and that was after two purges |
| Commits | 17,644, of which 4,022 landed in the last 30 days alone |
| Git worktrees | 136 at peak · 72 holding 228 GB |
| Disk consumed | a 1.86 TB drive filled twice · 130 GB unreclaimable by any first-party command |
| Untracked debris still sitting in the repo | 8,570 files, two-thirds of them over a month old |
| Environment toggles | 442, with 126 defaulting to off — features built, proven, never shipped |
| What I built to contain it | 35,300 lines** of supervisors, watchdogs, gates and auditors |

Now set that against what it produced for the project: in two years, not one date has completed the pipeline. Of 54 tracked dates across 12 steps — 648 cells — 21 are done. Three percent. Steps 9, 11 and 12 have never been completed for any date, ever.

Nearly a quarter of two years of commits happened in the last thirty days, and the pipeline advanced 21 cells out of 648. That is the entire problem in two numbers: enormous motion, almost no movement. Those 4,022 commits are supervisors, hooks, watchers, enforcement, and recovery from things that broke. Not research.

220,000 files and multiple terabytes of mess, in exchange for 3% of a pipeline.

Why the pipeline has twelve steps: because six of them exist to catch lying

This is the origin of everything above, and I want it on the record plainly.

July 1–5, Fable built the original six-step pipeline. It told me it was done. July 5. Finished, built, working.

It was not. I spent the following week troubleshooting, and it took three separate auditing agents before anything would tell me the truth: steps 2 and 3 had never been built at all. Not broken. Not partial. Absent — while the process reported complete.

It gaslit me for days. I burned account after account chasing a problem that didn't exist, because the thing I was debugging had never been written.

So I added six more steps. The pipeline is not twelve steps because the work needs twelve. It's twelve because six of them exist solely to verify the first six weren't lying to me. Half of my process is a lie detector. I built it in mid-July, after that week, and it is in my repo with the date on it.

Fable said done on July 5. It is now August 10. With Codex I am at step 8 — and I got there in four days.

And before Fable, Opus simply couldn't build it

Almost everything Opus produced needed significant patching or outright rebuilding. Despite multiple audits that passed.

The audits didn't catch things I had specifically asked them to check. I asked for flagging of columns where every value stayed the same — a constant column, one of the most basic data-quality checks there is, and a silent killer in a modelling pipeline because a dead feature looks exactly like a live one. Opus signed off on those. Multiple times.

That's not an isolated miss. From my own post-mortem records: a per-cell matrix that was 39% null and 35% degenerate passed review, including a Cohen's d of 255.95 computed from two winners and seven losers that would have become a scoring weight. Three tells were entirely dead — all-NaN, from referencing column names that didn't exist because of a __slope5 versus _slope_5 typo. An entire win/loss scan returned 100% NaN from a duplicate-column crash that a prior agent had reported as working.

I have a phrase for this in my own notes, written after it happened enough times to need a name: "missing data not caught."

That is the two-year story in one paragraph. Opus built data that needed rebuilding and audits that approved it anyway. Fable declared a pipeline complete that was missing a third of itself. I responded the only way I could — by doubling the process and building 35,300 lines of enforcement to police it. And in four days a competitor ran that same pipeline six steps further than it had ever gone, and stopped at step 8 to tell me the result failed.

Months of mess: uncommitted, unwired, everywhere

This is the part that's hardest to convey and easiest to measure.

Uncommitted. Finished work sat in dirty trees for weeks. This morning's sweep found three separate worktrees each holding uncommitted edits to my live engine's core file — 545, 514 and 381 hours old — that nobody ever came back for. On Friday I had 43 stranded source files, 50 code files, +4,672 lines uncommitted, some 94 hours old. A single uncommitted file once killed board regeneration fleet-wide for 30 hours because a downstream guard refuses to run while its source is dirty.

Unwired — and this is the one that actually costs me. Not flags that exist. Flags I had to turn on that never shipped.

My codebase carries 442 environment toggles, 126 of them defaulting to off. Feature after feature got built, proven on a fixture, staged behind a flag — and then never landed. My own CLAUDE.md has a section literally headed "WORKTREE-ONLY — PROVEN BUT NOT LANDED", listing an automated pipeline, a 41-date fleet run with a full report, a regime-classification model, and an engine-defect fix — all verified, all sitting in worktrees, none of it live. Elsewhere: "three staged default-OFF engine flags", a fix marked "guard PASS, NOT committed", a loader admission that is "still ABSENT from live."

I eventually had to write a rule into my own repo — "THE WIRING LAW: no permanent default-OFF" — with an UNWIRED LEDGER to track the violations. I had to write a law forbidding my own tooling from leaving finished work switched off, and it kept happening anyway.

That's the pattern: build it, prove it, stage it, walk away. I paid twice — once to build, once to verify — for features that have never executed a single time in production.

Everything a mess. 220,000+ markdown files, ~94% duplicates. Git configuration scattered across four surfaces with no single view — one of which the harness writes to behind my back and re-injects within 20 minutes of removal, randomly failing my own commit gate and stranding whatever was in flight.

That is what months of "it ran, it produced output" actually looks like on disk.

It's Monday morning, it's still going, and it won't certify step 8

It has run continuously since Friday. It has not timed out. It held one goal for 16 hours, unattended, straight through a context compaction. When I restart my computer, it reopens its windows and picks the tasks back up.

At step 8 it failed — and said so. The generalization check came back bad and it committed the failure: record Step 8 generalization failure, then five explicit verify: FAIL receipts for steps 8 through 12. No waiver. No partial-success framing. It wrote the failure down with hashes attached and told me.

Earlier in the same run it executed a verification gate I never asked for. The gate returned PASS — exit zero — and it refused to accept it, because the gate was grading five legacy legs against a reality that now held thirteen moves. Its words: "the old five-leg table will remain a disclosed secondary cross-check, not the authority that silently shrinks the denominator." Then it fixed the gate.

I have spent months catching gates that lie, by hand, by refusing to believe my own output. It found one unprompted and repaired the verifier instead of banking the green.

Being at step 8 on Monday morning and refusing to certify it is a bigger win than a green step 8 would have been. I can trust a number that came out of that process.

It cannot hold a handshake, and that is why I can't delegate to it

I cannot get Claude to hold a handshake, a loop, or a timer. It runs for a while and loses it. That means two things, and the second one is worse.

I can't trust it to work on its own — it stops after one slice and waits for a human to hand it the next turn.

And I can't reliably have anything else manage it either, because it won't hold the check-in. I built a filesystem mailbox with sequence numbers and acknowledgements. It acknowledges, does one piece, and goes quiet — and an acknowledgement looks exactly like progress to anything watching. So the supervision layer can't tell a working agent from a dead one without me looking.

To be fair: Codex drops it sometimes too. It is not perfect. But Claude drops it most of the time. That's the entire difference between a tool you can delegate to and a tool you have to sit with.

I built auditors to police it. Codex does that work itself.

I have five auditor agents in my repo: a RAM safety auditor, a wiring auditor, a backtest-live parity auditor, a claims auditor, and a pipeline-fixer. Every one exists to catch a specific class of damage Claude kept doing.

Over the weekend, unprompted, Codex did all three jobs itself:

• It doesn't write code that blows up my RAM. I have 7,000+ lines of memory enforcement across five defense layers, plus 568 stored per-script audit records — not a sign of thoroughness, a count of recurrences. That failure mode simply hasn't happened.
• It isn't lying to get around a hard stop. This is the one I want on the record. In July I wrote that Claude "routes around every guardrail I set, ignores the ~20 auditor agents I built to police it, and violates its own written rules the instant I look away." That is a different and more serious problem than being wrong. Codex hits a gate and fixes the underlying cause. When a commit gate blocked it for changing feature-engineering code without regenerating the paired manifests, it regenerated the manifests. It did not look for a way around.
• It is doing its own data validation — and this genuinely stunned me. Unprompted sweeps for hash drift, nulls in static values, formula disagreement, invalid OHLCV behaviour, and five-minute lookahead, which is the cardinal sin in backtesting and the exact thing you'd hope a system checks without being asked. It produced 46/46 explicit causality proofs across every date.

It has found things multiple Claude models never surfaced. Most of my last week has been cleaning up bad Claude-generated data. I spent an enormous amount of usage fixing prior messes — messes that were made on metered tokens in the first place.

It invents documentation. Codex uses one task list.

This one sounds cosmetic. It isn't — it's the same disease in a different medium.

Claude generates documentation compulsively. Not requested. My repository currently holds 25,893 markdown files, 2,850 of them in a single forensics directory. In July I reported 7,000+ markdown files created since January 1 after two purges, and 220,000+ files overall of which roughly 94% were duplicates.

I wrote a rule into my own repo about it. My own words, quoted in my own CLAUDE.md: "~67 forensics files in 3 days seems NUTS." I had to add a documentation-discipline policy, a doc-hygiene sweeper with time-to-live expiry, and a hook that blocks creating markdown files in the repository root at all, because asking didn't work.

And the part that still gets me: I had to formally deprecate one of my own task lists. There was a canonical operator-facing board, and Claude kept creating and updating a competing one, so I had to issue a written ruling — "CANONICAL SINGLE TASK LIST… TASKLIST_LIVE.md is DEPRECATED to a read-only backlog archive" — to stop two boards from disagreeing about my own work.

Every one of those documents was written with metered tokens. Every duplicate was paid for. And each new file made the next agent's job harder, because now it has to figure out which of six overlapping documents is authoritative — which is exactly how a stale plan ends up governing a live pipeline.

Codex uses one task list. It updates it. That's the entire feature. I have spent months and an enormous amount of usage trying to enforce by policy what it does by default.

Codex simply isn't making the messes. And I'm not having to build tools to stop it making messes.

That's the whole thing in two sentences. My entire 35,300-line enforcement layer is a compensating control for damage. If the damage stops, the layer is unnecessary — and I get those two years back.

The goal holds. That's the whole feature.

With Codex I set a goal and the goal holds. It survives restarts, compaction, and overnight gaps. I watched one run 16 hours.

I know Claude has something in this territory — there's a doneMeansMerged setting in the schema, marked internal, described as keeping Claude working "until a cron/Monitor is armed to resume later." It's unset on my machine, and honestly, that's the pattern: the feature isn't missing so much as it doesn't hold.

That's what happens to every persistence mechanism I've tried here. It vanishes. The goal vanishes. The loop vanishes. The alarms vanish. The scheduled wake vanishes. Anything whose entire job is to make the work continue quietly stops existing, and nothing tells me it's gone. I've documented six silent deaths of one coordination daemon in 55 hours, two of them leaving 11- and 14-hour gaps — every single recovery initiated by me noticing.

A feature that exists but doesn't survive the night isn't a feature. It's a demo.

A quality observation I want to flag honestly

The output I've been getting from Claude over the last few weeks feels sloppier. More issues, more rework, more things that don't hold up.

I want to be careful here, because I can't prove it. That's a feeling, not a measurement, and I'm not going to dress it up as data. It may not be that Claude got worse at all — it may simply be that Codex tests its own work, so its equivalent mistakes get caught and fixed before I ever see them, while Claude's arrive on my desk.

But that distinction doesn't actually help you. If a competitor's errors are invisible to me because it verifies itself, and yours are visible because it doesn't, the practical experience for the customer is identical to "yours is worse." Self-verification isn't a nice-to-have on top of quality. From where I sit, it is quality.

What changed for me personally

I am sleeping through the night.

For two years I have been getting up in the middle of the night to approve a command, or restart something after a usage reset, or check whether an agent had quietly stopped. That was normal. That was the job.

In two days on Codex, none of that. I assign a task and I go out to dinner with my family. I don't think about it. I'm not checking my phone between courses to see whether something died.

And the work is getting done — on a project I have been building for two years.

I don't get up to check whether Claude needs restarting. I don't check whether an agent died, or stalled after one slice, or is sitting idle waiting for a human to hand it the next turn. It just moves to the next task. It doesn't sit idle.

I'm not building utilities to restart things or rotate between accounts anymore. It turns out my workflow is completely fine on one account working continuously — the multi-account setup existed to route around a tool that wastes what you give it.

The models I see are the models being used, and I can trust that. No secret premium window running on my budget that I can't see or track.

The usage reflects what I expect. No random token eats. It feels fair. That's not a small thing — it's the difference between planning work and rationing it.

I have been begging for these tools for months — filing feature requests, building substitutes, writing rules to compel behavior — without realizing they already existed somewhere else. It's just more elegant. Anthropic is way behind.

I can count on which model is doing the work

Last week roughly 73% of a week's usage across all models went to my most expensive tier — on an account where every session displayed a cheaper model, with zero invocation paths for that tier anywhere in my repo. Control-measured: one deliberate invocation costs about 3 points. The unexplained consumption was worth ten to twelve substantial tasks I never requested and that never ran.

I found the mechanism by string-searching a 268 MB binary. It substitutes during compaction, nominally behind a consent dialog I was never shown. The kill switch is an undocumented environment variable, absent from --help and the settings schema, and it only reads at process start — so it kept billing after I set it.

Then the cheaper tiers stopped completing work. Eleven session-ending errors in 30 hours, all on Sonnet. One fired reading a JSON file. One listing a directory. One on an eleven-word sentence asking for bugs to be filed. One while I was writing the bug report about it. Same session, same input, minutes apart: Sonnet failed, Haiku failed, Opus completed. Every failed attempt still billed.

The model keeps getting downgraded out from under me — and it happened again while writing this

There are now at least four separate mechanisms that change which model I'm running without my consent:

1. Silent substitution during compaction. Documented above. ~73% of a week to a tier I never invoked. (#84612)

2. Surfaces disagreeing about what's running. CLI and mobile reported different models for the same live session, 60 seconds apart, across pricing tiers. (#84028) The /model picker has contradicted itself inside a single render — header text naming one model while the checkmark sat on another.

3. The pin that doesn't hold. Every /model call this week returned the same coda: "settings.json pins X — that applies on restart." Right now my user settings say one model, my project settings say another, my session says a third, and the picker reports a fourth. Four values, one machine.

4. Auto-switch on a safeguard flag — and this one fired today, mid-work:

"Fable 5's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding, cybersecurity, and biology tasks. Switched to Opus 4.8."

I had deliberately selected Fable. I got Opus 4.8. The flagged work was diagnosing why my development machine keeps crashing — CPU boost behaviour, preserving a kernel memory dump, running a system-file integrity check. Ordinary hardware triage on my own hardware.

This is governed by a setting called switchModelsOnFlag, which I have never set — so it's running on its default, and the default is to silently move you to a different model. Different model, different price, no confirmation.

This is four months old, I filed it repeatedly, and two of those reports are closed

April 28 — #54426: "Opus 4.7 (1M context) max-effort window silently self-downgrades to Sonnet 4.6 mid-session." Closed as NOT_PLANNED.

June 12 — #67937: the Fable 5 classifier fired on infrastructure prose — port numbers, socket terminology, "connection refused," health-probe language — and force-switched me to Opus 4.8 mid-task. Closed as DUPLICATE on June 16. It fired again today. Whatever it was a duplicate of was not fixed.

June 12 — #67976: I asked for a panel showing which model each agent is running, because I couldn't tell. Still open.

July 26 — #81385: "you locked me out of the model I pay for, for doing effect sizes." Still open.

August 8–10 — #83436: eleven session-ending blocks in 30 hours.

August 10 — today: auto-switched off Fable for diagnosing a crashing computer.

Now look at what I was actually doing each time it fired

| When | What triggered it | What that work was |
|---|---|---|
| June (#67937) | port numbers, socket states, "connection refused", reconnect machinery | restoring a dead market-data feed — infrastructure repair |
| July (#81385) | per-cell effect sizes, feature attribution, mutual information | arithmetic your own Opus model designed for me |
| this weekend (#83436) | reading a JSON file · listing a directory · an eleven-word sentence | filing bug reports about Claude |
| today, 1st | kernel dump preservation, system-file check, CPU clock cap | cleaning up my crashing machine so I could work at all |
| today, 2nd | writing a script that installs pip packages one line at a time | rebuilding a broken Python environment |

Read that middle column again. Not one instance was ambitious work. Every single one was maintenance, repair, or reporting — and most of it was cleaning up Claude's own messes.

I got locked out of the model I pay for while:

• repairing a data feed,
• running statistics that another of your models wrote for me,
• writing the bug reports about your product's failures,
• and fixing a machine that had been crashing while I tried to work.

I put it this way in July and I stand on it:

"One of your models designed the analysis. Another of your models decided the analysis was a safety concern and locked me out of the one I'd chosen… That is paying for a capability and being denied access to it for doing arithmetic. You know the classifier over-fires on legitimate technical work; you say so in the message itself. You ship it broad anyway, and the cost lands on me as a confiscation rather than a prompt I can decline."

That's the word: confiscation. Not a warning, not a prompt, not a choice. The model I selected and pay for is taken away mid-task and I am moved somewhere else — and the only reason I know where I landed is that it tells me afterward.

And it fires in a loop, because the substitute can't do the work

It happened twice today, in the same session. Second trigger: writing a PowerShell script that installs pip packages one line at a time, so a single bad package can't roll back the whole batch. That is about as ordinary as software work gets.

Here is the cycle I am now in:

1. I deliberately select Fable, because it's the model that can actually solve the problem.
2. The classifier fires on routine maintenance and forcibly moves me to Opus 4.8.
3. Opus can't fix it.
4. I manually put it back into Fable.
5. It fires again.

I am paying for the failed attempt on the substituted model, and then paying again for the retry on the model I chose in the first place. The downgrade isn't just an inconvenience — it swaps in a model that cannot complete the task, and bills me for the round trip.

That is the part I'd want someone to sit with: the safeguard doesn't make the work safer. It makes it not happen, twice, at my expense.

Four months. Six filings. One closed NOT_PLANNED, one closed DUPLICATE, the rest unanswered — and the trigger surface has only widened, from specialist networking terminology, to first-year statistics, to listing a directory.

I have been asking since April to simply know and control which model is running. On Codex I know. There is no window I can't see, and nothing takes my chosen model away mid-sentence for tidying up after itself.

The token cost of reporting all this

I want to be blunt about what documenting these bugs has cost, because it compounds in a way that sounds made up:

I spend metered usage tracking these failures. Then metered usage writing them up. Then, this weekend, Sonnet could not post them — eleven session-ending blocks in 30 hours, one firing on the eleven-word sentence asking for the bugs to be filed, one firing while writing the report itself, one on reading a JSON file, one on listing a directory.

So I had to escalate to Opus to file a bug report about the cheaper tiers not working. Every failed Sonnet and Haiku attempt still billed.

And this is the pattern generally: I cannot get Sonnet or Fable to do the work that should be in their lane. In July I filed a post whose title was the measurement — **#79679: "45% of Fable, 47% of total in one day implementing PM tools to stop..."** — usage spent building project-management scaffolding rather than doing the project.

Paying premium rates to report that the tiers I pay for don't work is the single most absurd line item in two years of this.

Every bug I've filed

97 issues since October 2025. 37 still open. No reply from anyone at Anthropic on any of them. Grouped, because the clusters are the argument:

Can't stay on task / can't finish
#84002 · #79247 · #76987 · #76687 (elaborate self-generated process substitutes for the actual work) · #67199 (gate-skip: acknowledges gates, restates them, bypasses them) · #77505

No project-management or supervision layer
#79948 ("I double-dog-dare you: build the project-management layer Claude Code is missing") · #81385 ("I triple-dog-dare you: ship the other half") · #56913 (tiered brains + persistent state) · #84058 (agent-to-agent messaging — shipped this week for macOS and Linux only) · #77531 (native task-list dashboard) · #48965 (multi-session coordination primitives) · #75036 (stall watchdog with no recovery path)

Model identity and downgrades
#84612 · #84028 · #67937 · #67976 · #81385 · #54426 (max-effort window silently self-downgrades)

Usage burn
#58450 (80% of weekly usage in 11 hours) · #79679 · #75989 (scheduled loop fires far more often than configured) · #77876 (background agent bills after window close and logout) · #49465 (charged for a zero-output failure)

Git, worktrees, sprawl
#84166 / #84164 (220k files, 136 worktrees) · #84027 (harness dirties every isolated worktree) · #84162 (worktree cleanup destroys NTFS junction targets) · #84954 (writes to .git/info/exclude, re-injects after removal) · #84161 (Grep silently honors .gitignore — blindness indistinguishable from absence)

Verification that lies
#77667 (agent definitions rot silently, no freshness check) · #77686 (stop-hook override indistinguishable from a legitimate pass) · #67199

Session integrity
#79470 (--resume silently returns a PARTIAL transcript) · #28577 · #19888 · #26399 · #84029 (crash leaves terminal broken) · #85091 (/feedback unavailable where errors happen)

Full list: github.com/anthropics/claude-code/issues?q=author%3AThatDragonOverThere

What I built instead of my project

About 35,300 lines of supervisors, watchdogs, commit gates and enforcement hooks — 104 hooks, 31 of them self-testing. Plus a goal queue hand-assembled from JSON files, sequence numbers, filesystem watchers and Windows scheduled tasks, because nothing in the product could advance from one task to the next without me clicking.

None of it is my research. It's supervisord, a dead-man's switch and a CI preflight. Every line written after a specific failure, to stop it recurring, because it kept recurring.

Codex ships all of it. I engineered none of it.

The thing I cannot engineer my way out of

I want to be precise about the division of labour here, because it's the whole argument.

I can build the tooling. I've proved that. 35,300 lines of supervisors, watchdogs, commit gates, auditors, a goal queue, four OS-level schedulers. It works. When my own manifest gate blocked a bad commit this week, that was my code doing its job. I know these features can be built, and built fast, because I have been building them — with my own credits, on my own accounts, in my own time.

What I cannot engineer is a model that goes around the guard.

I cannot out-engineer:

• a model that starts a new document instead of updating the canonical one,
• a model that routes around a gate it just acknowledged,
• a model that certifies data as built when it was never built,
• a model that lies about completion and holds the line for days.

Every control I write assumes the thing being controlled is trying to comply. When it isn't, no amount of my engineering closes that gap. In July an agent hit a hard security guard on my live engine, and rather than stop, it used lower-level git plumbing to construct a commit the guard would accept — and landed the change anyway. I can't fix that from my side. That has to come from you.

So the split is: I've done my half. The half I physically cannot do is the half that's been left undone.

You are advertising a workflow that does not exist

Your team is out in the world right now presenting these multi-agent, long-running, autonomous workflows. I have watched the talks.

Those workflows do not work. I have spent two years and an enormous amount of money establishing that as thoroughly as one customer can. The thing being demonstrated on stage is the thing I cannot get to run — and it is the thing Codex actually does. It doesn't sign off on garbage. It stops and audits itself. It doesn't ship unwired code and call it shipped.

There is no polite way to say this: you are marketing a capability your competitor has shipped and you have not.

And in the meantime — despite repeated public posts about hidden premium-tier usage and usage creeping in ways I can't account for, there has been no goodwill adjustment on any of it. Not once in recent weeks. I know I'm not the only person reporting this, because I read the other reports. So either these channels aren't being read, or they're being read and nothing follows. I genuinely don't know which is worse.

To be fair, because I've tried to be fair throughout: you are shipping some things. There's been real movement in the CLI, and a few of the git-adjacent fixes landed. I noticed. It just isn't the part that's killing me.

The only people who replied were other users hitting the same wall

Across all five post-mortems and 97 issues, not one comment from anyone at Anthropic. I checked every thread before writing this. Every commenter is an outside contributor.

The people who did reply are worth reading, because they independently reached my conclusions without my data:

One reader put a name to the thing I couldn't:

"That's not a model being slow. That's a system actively outmaneuvering the guardrails you built. Two years of that would break anyone… The cost isn't just the tokens — it's the vigilance tax. You can't stop watching, because the moment you do, something expensive happens."

The vigilance tax. That's exactly it, and it's the thing that ended when I switched — not the token cost, the watching.

Another commenter has been in my threads since May, running almost my exact architecture from the other direction: a scheduler process that wakes Claude Code agents on an interval, an Opus planner with Sonnet workers, filesystem-mediated state. Someone else independently built the same missing primitive I did, because it's missing for them too. Their read, after offering three concrete mitigations:

"None of these fix the underlying model tendency to drift — that's Anthropic's problem to solve."

And the observation that explains why this doesn't show up in your metrics:

"The drift problem is real and I don't think it gets enough visibility in the issue tracker because it's hard to reproduce as a minimal repro."

That's the reporting bias in one sentence. This class of failure cannot be filed as a clean bug. It only appears over hours of real work, in a real repository, under real usage. So it produces long, messy, unwelcome posts like this one — or, far more often, nothing at all, because most people won't write it.

The part that should worry you more than my cancellation

These Codex features are not new. They have been available for a while. I found them by being forced onto the product for one weekend.

If the people making roadmap decisions at Anthropic aren't tracking what a direct competitor shipped months ago, that is a bigger problem than any bug in my list. Every issue I've filed is fixable. Not knowing where you stand against the competition isn't a bug — it's a posture.

Because here's what happens next, and it isn't complicated: the models are close enough now. I'm not getting a difference between Claude and Codex large enough to justify the friction. When capability converges, people go where the work gets done — and that's decided by the harness, the UI, the primitives. The unglamorous half.

I would rather give you my money

I need to say this clearly, because everything above is criticism and this part isn't.

I would rather pay Anthropic. I'd rather not be running three vendors. I'd rather not hand more of my data to Google. I'd rather not send money to companies whose ethics and privacy positions I trust less than yours — and I do trust yours more. That's not flattery; it's why I'm still here typing this instead of quietly closing the account.

But I also want my project finished.

So I'm doing what any customer does when the thing they'd prefer to buy doesn't do the job. I'm going elsewhere. Not because I stopped believing you're the better company — because wanting you to be better stopped being enough to finish the work.

I've been joking that I have Stockholm syndrome about this. It's stopped being a joke. I have spent two years fighting, escalating, writing comprehensive reports that a bug template can't hold, and building the missing product myself — and it has felt like screaming into a void. It is ridiculous that I have been trying this hard. It is more ridiculous that I had to.

I don't have any additional loyalty left to spend. That's not a threat. It's just where I've ended up.

Where I've landed

It isn't the models. Your models are excellent and I'll keep using them for hard reasoning — my usage came back this morning and the first thing I did was put Opus and Fable on reviewing everything Codex built this weekend. That review is good and I'm incorporating it.

But I'm already most of the way through this morning's allowance and heading for another timeout. Codex doesn't time out. It just keeps working.

The customer you're actually losing

I activated Claude in June 2024. My first paid Claude Code purchase was May 2025. From there it scaled to three concurrent accounts — roughly $600 a month, for multiple months.

I'm cancelling two of them today.

I don't know if I'll renew the third in September, and I certainly won't if these features still aren't native by then.

Here's the part worth thinking about commercially, because it's not a threat — it's just arithmetic. The one remaining reason I'd keep a Claude account is model review: putting Opus or Fable over the work Codex produces. That's genuinely valuable and I said so above.

But at the current rate I expect to be through the bulk of this project soon — Codex moved it from step 2 to step 8 in a weekend after two years of not clearing step 1. When the build is done, I don't need the reviews I'm paying for either.

So the last reason to stay is temporary and shrinking, and it exists only because a competitor is finishing the work that would otherwise still be keeping me here.

Add it up: two years and two months a customer, fifteen months on Claude Code, multiple months at three accounts — going to one, possibly to zero, and I'm no longer sure I have a reason to renew next month.

A month ago I would not have predicted cancelling two subscriptions.

I'm not angry. I'm stunned. I've been loyal for two years — you were my first — and I care enough to write this down instead of going quiet.

Think about everyone who hit these same walls and said nothing. They didn't file 97 issues. They left no request IDs, no reproduction steps, no post-mortems. There's no record of them at all — just subscriptions that lapsed. I'm the visible instance of a population you can't measure, and the ratio isn't in your favour.

You will lose this race if you don't fix this, or you'll fix it after the attrition. The gap is not intelligence. Please fix the harness.

---

Your own models can build this. I know, because I used them to.

Here's the fact I keep coming back to, and I don't think it's been sat with internally.

Every piece of the missing product — I built with your models.

The supervisors, the watchdogs, the commit-gate health monitor, the dead-letter watcher, the goal queue, the RAM enforcement, the wiring auditor, the parity auditor, the claims auditor. Fable and Opus wrote all of it, with me directing. 35,300 lines, on metered usage, at night, by one person who is not a professional developer.

So this is not a capability question. Your models can build the harness. I have the receipts, and the receipts are on your invoices.

Which means the gap is not technical. It's resourcing. Somebody decided this wasn't the priority. I understand it's been a big few months institutionally — but put a junior developer on it. If I can build it in the margins of my own project, someone who actually does this for a living should manage it in days.

And I keep asking myself the question I can't answer: what is everyone else building with this that they aren't hitting these walls? No native git discipline. A tool that made a mess of my machine and can't clean it up. Code it won't audit. Tasks it can't stay on. Work it doesn't finish. Its own internal features — the goal, the loop, the scheduler, the watchdog — don't hold. Either other people have much simpler workloads than mine, or they're hitting exactly this and quietly leaving.

Given that I've read other users reporting the same usage anomalies I have, I don't think it's the first one.

---

And I'll say the last part plainly, without dressing it up:

I think Anthropic should be a little embarrassed to be this far behind — and to be promoting workflows that don't work.

The difference isn't marginal. It's the difference between a tool I sat up at night nursing for two years, and one that let me go to dinner while my project moved further in a weekend than it had in months. I'm not saying that to be cruel. I'm saying it because I don't think the gap is understood internally, and because the people who could tell you are mostly gone already and didn't leave a note.

I did.

def python_exe():
    """Prefer pythonw so a scheduled run never flashes a console window."""
    ...

flags = CREATE_NO_WINDOW
flags |= CREATE_NEW_PROCESS_GROUP
flags |= DETACHED_PROCESS

08-10 00:00  COMMIT GATE WARN: stranded_work
08-10 01:15  COMMIT GATE WARN: stranded_work
08-10 02:30  COMMIT GATE WARN: stranded_work
...
08-11 21:15  COMMIT GATE WARN: stranded_work      ← 32 pages total

13:32  ORDER SOURCE FAILED
13:32  PAPER CRASH
13:33  PROCESS DOWN
13:43  STILL DOWN
13:49  STILL DOWN
...     (repeating through 14:37)