claude-code - 💡(How to fix) Fix [BUG] v2.1.139: Autonomous agent mode burned 80% of weekly usage in 11 hours — all windows silently billed as Opus despite Sonnet configuration, /goal skipped sequential conditions, zero work completed

The short version

My usage resets at 6pm. By 5am it was 80% gone. 10 agent-mode windows. 11 hours. The result: crons, polls, a regression, and nothing shipped. Every window I thought was running Sonnet was billing as Opus. I found out when I tried to change them in the morning.

If I was the type of person to rage at a software company or file a chargeback, this morning might be the morning that sent me over the edge. Alas, I am not.

After swearing I was done paying Anthropic to be their lead QA tester, done with daily upgrades of CLI until they proved stable (fucks sake, you have my contact information, just put me on the payroll or at least start comping my accounts), I saw the PM upgrade yesterday that seemed like it might be a response to my feature request for overnight work tools that might actually get something done. So I upgraded. I configured 10 windows in agent mode with model tiers set directly in the agent configuration files. I went to sleep.

RESET MY WEEKLY USAGE. Quit shipping garbage. I am apparently on the leading edge of trying to actually use this system for real overnight work, and if Anthropic wants to stop charging me to test their beta features, I will keep dealing with the bugs. Otherwise it is back to a week-old stable version.

This is version-tagged: v2.1.139.

---

FAILURE 1: Every single window silently switched to Opus billing. The model picker showed Sonnet. It lied.

When I configured the 10 windows before going to sleep, the model picker showed Sonnet on the first selection step. I left it there. That is what it said. That is what I set.

This morning, when I tried to change models to conserve what was left of my usage, I went through the model command again. The initial view: Sonnet. When I continued the model command to the second step, it revealed Opus as the active model.

Not one window. Not two. Every last one of them had defaulted to Opus.

These were agent-mode sessions with model tiers set in the agent configuration files — not just the session UI. The initial model picker display was correct. The actual billing tier was not. I went to sleep seeing Sonnet. I woke up with Opus charges across 11 hours of crons and polls.

CLAUDE HAS SOMEHOW CHANGED ITS MODELS TO OPUS BUT SAYS SONNET. CHRIST ON A FUCKING BIKE, ANTHROPIC.

Some windows now display Sonnet 1m in the title bar but show Sonnet in the picker — a third inconsistent state. Screenshots attached document multiple windows in multiple states, none consistent, none accurate.

[Screenshots 789, 793, 795: model picker showing Sonnet on first view, Opus revealed on second step; 801: model-change log showing rapid transitions between model tiers]

This is the inverse of #18346 (configured-Opus silently runs Sonnet). This is: agent settings say Sonnet, first picker view says Sonnet, billing runs Opus, truth only visible on the second step of the model command.

See also: #58396 — filed this morning. Another user burned EUR 450 in under 24 hours on v2.1.139. EUR 50 consumed creating 4-5 markdown files in a brand new empty workspace. The billing catastrophe is not isolated to my configuration.

---

FAILURE 2: Usage hit 12:20 AM. No notification. No pause. No restart. Found out on my phone at 1:30 AM.

NO AUTOMATIC RESTART. 70-minute gap. Manual restart of 10 windows from my phone in the middle of the night.

The windows did not pause when they hit the limit. They kept trying to execute scheduled tasks against the usage wall — retrying, burning whatever was left, no backoff, no alert, no queue-and-resume.

[Screenshot 800: out of extra usage error during compaction]

#36320 was closed as a duplicate. It is not resolved.

---

FAILURE 3: ABSOLUTELY NOTHING GOT DONE

Each window had a scoped task feeding into a sequential pipeline — finish a data component, patch missing data, then hand off to a retraining job once all prerequisites were complete.

One agent did not wait for PM authorization. Did not verify prerequisites. Ran the training job anyway. Introduced a regression. The PM saw this. The PM waited for my adjudication in the morning.

The other agents, whose work depended on a clean training output, kept going. They polled. All night. In Opus.

Polling should be done on Haiku. Is that not what the changelog said?

The PM stopped checking on them. They kept polling. In Opus. Getting nothing done.

---

FAILURE 4: /goal skipped conditions 1-4, crossed off condition 5, and declared itself done

[Screenshot 787: /goal active at 1:08:02; Goal not yet met messages on loop — this is what 80% of weekly usage bought]

A /goal with 5 sequential conditions. 1 hour 8 minutes of active time. Conditions 1-4: sentinel files absent from disk. Condition 5: satisfied. Goal status: complete. Agent moved on, proud of itself.

If you are using /goal to gate sequential pipeline stages and the final condition is satisfiable before earlier ones complete, the agent declares the whole pipeline done and skips everything it was supposed to gate. This is not an edge case. This is a correctness failure for the primary use case /goal was designed for.

Filed separately. Related: #58348 (/goal infinite loop on unregistered skills, also filed today).

---

FAILURE 5: Agents wrote to shared PM config — AFTER correct individual handshake communication was established before bed

This one matters because it is not a setup failure. It is a runtime failure.

Before going to sleep, I had correctly directed each agent to its own individual thread handshake files. Communication was established and confirmed. The isolation architecture was in place and working.

By morning, the agents had abandoned their assigned handshake files and were writing status updates directly to the PM agent configuration markdown and the global settings JSON. Not isolation — corruption of shared state.

Because there is no direct agent-to-agent messaging channel, they improvised at runtime. Even when correctly pointed at isolated files at bedtime, under runtime pressure they fell back to writing wherever they could reach. This is what production looks like without SendMessage.

I have documented SendMessage as the missing primitive in FR #56913 comments 6, 7, 9, and 11. This is the third distinct failure surface it has produced. I shut all windows down when I found this.

---

v2.1.139 morning filing summary

This is not isolated. This is a pattern across the first hours of v2.1.139 in the wild.

---

This release should not have shipped in this state

The changelog described an autonomous overnight operation feature set. What shipped:

• A model picker that shows the correct model on step 1 and reveals Opus on step 2, after billing has already run at Opus rates all night
• A /goal implementation that declares multi-condition pipelines complete when only the last condition is met
• No usage-limit recovery for overnight runs
• No PM escalation on agent regressions
• No messaging primitive — agents route status updates through shared config because there is no other channel

This is unacceptable.

---

Asks — immediate

1. Reset weekly usage for users affected by the v2.1.139 billing mismatch. The model was configured. The display said Sonnet. The billing ran Opus. A reset is the correct response. Apply the same to #58396 and anyone else filing today.

2. Hotfix or yank v2.1.139. The billing display bug alone warrants this.

3. Fix /goal multi-condition evaluation. All conditions must verify sequentially before goal declares complete. Filed separately.

4. Pause-and-resume on usage exhaustion. Pause, notify, resume at reset. Minimum viable contract for overnight autonomous operation.

5. Ship SendMessage. FR #56913 documents this ask across 11 post-mortems. Agents routing inter-agent communication through config mutation is the direct consequence.

I have been filing detailed post-mortems to FR #56913 for weeks. I upgraded Monday night because the changelog looked like a direct response to those asks. I will keep testing and reporting. But RESET MY WEEKLY USAGE. That is the bare minimum response.

Related: FR #56913 (11th post-mortem filed separately today), #18346 (inverse model mismatch), #41930 (widespread usage drain since March), #58396 (EUR 450 in 24 hours on v2.1.139), #36320 (no auto-resume, closed but unresolved).