The native install just went from 340 megabytes to about 75. Same software. Somebody remembered that compression exists, switched to zstd, and quietly cut three quarters off every auto-update you will ever download again. On your home connection, that is not a footnote. That is the difference between an upgrade you notice and one you do not.
It is Tuesday, 25 August, and 2 days have gone by since the last one.
Three versions since then, 2.1.242 through 2.1.245. One of them is enormous, around 65 items. One is a single line about a Linux crash. And one, 2.1.242, shipped with no changelog entry at all, which is a pattern I complained about at length last time and will get to again, briefly, with less patience.
Start with the memory and startup work, because for once it is not a bug fix, it is a rebuild.
Four separate items in this drop attack the same thing. The native binary now loads code on demand instead of keeping the whole bundle resident, which is 40 to 70 megabytes less memory per session. The runtime garbage-collects sooner as the heap grows, which is aimed squarely at long sessions. Sandbox and MCP bring-up no longer block the first frame. And bare launches skip subcommand registration entirely.
The interesting one is the on-demand loading. Until now the binary behaved like a man who unpacks his entire suitcase in the hotel lobby before finding his toothbrush. Everything resident, whether or not this session was ever going to touch it. Now it opens the drawer it actually needs.
Why this lands for you specifically: you run 3 or 4 sessions on this Mac simultaneously as a matter of routine. There are 3 idle right now in deadline, makingapaper and rutter. Multiply 40 to 70 megabytes by every parallel session you keep warm, and by every subagent fan-out on top of that, and you get real memory back. That is now the third consecutive drop with a memory fix in it, following the subagent tool-result leak and the web-fetch cache leak. I said last time somebody had finally sat down with a heap profiler and did not enjoy what they found. Evidently they are still sitting there.
Second, and this one is written for you personally: the usage command now has a Loops breakdown.
Per-loop run count, total tokens, tokens per run, and last run. The stated purpose is to make runaway or chatty loop tasks easy to spot.
Sit with what that implies about how loops have been billed until now. They ran, they consumed, and the consumption vanished into one undifferentiated usage number. A loop that woke up 40 times overnight and a loop that woke up 4 times looked identical from the outside. The only way to know was to remember what you had started, which is precisely the thing a background loop exists to save you from.
You have an entire architecture built on scheduled and self-pacing work. The Assistant fires autocast on a 5 minute tick. Your shows author themselves headlessly. Your gates read usage numbers to decide whether to run at all. Tokens per run is the number that matters there: it is the unit cost of a wake-up, and it tells you whether a loop is doing work or just checking in expensively. Go and look at it once. If any loop of yours has a tokens-per-run figure that surprises you, that is a scheduling bug you have been paying for silently.
Third, the prompt cache time-to-live settings, which are two settings and one genuine architectural decision.
There is now a main-conversation cache lifetime and a separate subagent cache lifetime, so you can hold a 1 hour cache on the main conversation while subagents stay at 5 minutes.
That split is correct and I want to explain why, because it is not obvious. A main conversation is long-lived and returns to the same context repeatedly, so a long cache pays off every turn. A subagent is a stranger who arrives, does one job, and leaves forever. Caching its context for an hour is paying rent on a room nobody will re-enter. Two different lifetimes for two genuinely different shapes of work is the right answer, and a single global setting could never have expressed it.
The caveat, and it is a real one for you: the note says this is for API-key and cloud-provider users. You are on the Max subscription for interactive work and your headless autocast runs share that same meter. So read this as architecture worth knowing rather than a knob you turn today, unless something of yours is authenticating with a raw key.
Fourth, and this is the fix I would have filed myself: hook conditions were firing on the wrong commands.
A hook condition matching a Bash command, for example a rule for the cat command, was firing on unrelated commands whenever the command contained a dollar-parenthesis or backtick command substitution followed by more arguments.
That is a guard reading the wrong half of a sentence. Your entire safety posture is hook conditions. You have a read-only guard that watches for edit tools during a review turn. You have a paid-API blocker. You have read-gates that intercept specific commands and inject a document you must read first. Every one of those is a pattern match against a command string, and every one of them has been mis-firing on any command containing a substitution followed by arguments.
And you write commands containing substitutions constantly. Every pbcopy hand-off you produce is literally a dollar-parenthesis wrapping a heredoc, followed by a pipe and more arguments. That is the exact shape described. A hook that fires when it should not is the annoying failure. A hook that fires on the wrong thing is worse, because it teaches you that its warnings are noise, and a guard you have learned to dismiss has already failed.
Fifth, a cluster of things about waiting, all of which bite unattended runs.
Sessions were going silent for 10 or more minutes when the API never started a response at all. Not a slow response. No response. The request now times out after about 3 minutes, retries once, then says plainly that there was no response from the API.
Ten minutes of nothing, with no error, is the worst possible failure mode for headless work, because there is no signal to act on. Your autocast runs are non-interactive and nobody is watching them. A hang with no message looks exactly like work in progress, right up until the moment it does not.
In the same family: remote MCP servers in non-interactive and SDK sessions were never recovering after a dropped connection. They now reconnect automatically or report as failed. Note the "or report as failed" half. Silent permanent degradation is the pattern, and this drop kills 2 instances of it.
And background subagents were not waking when their last background Bash task completed. So the thing you dispatched finished its work, and the agent that dispatched it simply did not notice. If you have ever had a background agent sit there looking busy while its actual job had been done for 20 minutes, that is the mechanism.
Sixth, cross-session messaging. Yes, again. This is the seventh consecutive episode with one, and I have made my peace with that.
The fix: messaging was silently turning itself off inside user namespaces and rootless containers, a regression from the socket-directory hardening in 2.1.232. And the inbox socket now closes connections that send no complete line within 30 seconds, with the explicit advice that scripts posting to it should connect once their data is ready.
The rootless-container half is the one with your name on it. Your entire popcorn2 fleet is rootless Podman. Any session running on that box, in any container, had this feature quietly disabled by a security fix from 3 versions ago. Not broken loudly. Turned off.
The 30 second socket timeout is worth reading as a warning rather than a fix, because it changes a contract. If anything of yours ever opens that socket early and fills it later, that pattern now dies after half a minute. Connect when the data is ready.
Seventh, and this one is a small feature with real diagnostic value: the tasks view and the agent detail dialogs now show which model and which effort level each subagent actually ran on.
Every fan-out you run involves model selection somewhere, whether you set it explicitly or let it inherit. Until now you could specify a model for an agent and had no confirmation whatsoever that the agent ran on it. You had intent, and you had a result, and nothing in between. Now the receipt is in the dialog. Given that reviewer agents in your build lane are required to be a different model from the builder, being able to see that as fact rather than as configuration is not cosmetic. It is the difference between a rule and a belief.
Two more in this tier. The model picker was silently ignoring an Ultracode selection, which is the specific comedy of a picker that lets you pick a thing and then does not pick it. And the resume picker was only ever listing the 50 most recent sessions, full stop, with no indication that there was anything beyond them. It now loads more as you scroll. You run a great many sessions across a great many repos. A list truncated at 50 with no marker is not a list, it is a sample presented as a census.
There is a new model-picker setting that lets you curate the picker into an ordered, labelled list, any id spelling, appended to or replacing the built-in lineup. Mildly interesting for you: you have opinions about which models do which job and a picker full of options you never choose is friction.
Slash commands for model, fast, and effort now run immediately instead of queueing until the turn ends on the non-Anthropic providers and in telemetry-disabled sessions. That telemetry-disabled clause keeps appearing as a source of second-class behaviour, which is worth filing away as a pattern: turning off telemetry has been quietly buying people a slightly different product.
The sandboxed Bash prompt no longer lists which network hosts are allowed. The reasoning is sharp: listing them made me assume anything unlisted was blocked and not even try, so you never got the chance to approve a new host. A guard that pre-emptively convinces the thing it guards to give up is over-performing.
Relatedly, sandbox network-violation details were being dropped from the Bash result when the blocked command still exited 0. The classic case is curl printing a proxy's 403 page and returning success. So the command "worked", the output was a rejection notice, and the fact that the sandbox had blocked it never surfaced. You have curl in scripts everywhere.
The status line and usage were still showing a rate-limit window's pre-reset percentage after the window had actually reset, if the session sat idle across the boundary. Your usage gates read those numbers. A stale percentage is a gate deciding on yesterday's weather.
The loop command now folds consecutive wake-ups where there is nothing to do into a single line, instead of printing each one. Good. A quiet loop should look quiet.
A few smaller ones. History search and up-arrow both broke entirely if the history file contained one malformed entry, which is a whole feature taken out by a single bad line. The clear command was wiping a renamed session's name from the prompt bar even though the name was actually kept. The local IDE connection was being routed through the proxy when localhost was listed in the uppercase no-proxy variable but not the lowercase one, and both casings are now honoured, which is the sort of bug that costs somebody a full afternoon. And the teleport command was exiting on uncommitted changes instead of offering to stash and continue, the way the session picker already did.
There is an error-message improvement I approve of: using effort level xhigh or max with thinking turned off now names the level, names the setting that disabled thinking, and tells you the fix. That is what an error message is for, and roughly 1 in 20 of them manage it.
Also, client-generated errors, auth failures and model-availability problems, were rendering like model output rather than as error lines. So the thing telling you something was wrong looked like me talking. And the sign-in flow over SSH got real attention: the URL appears immediately, and pressing the copy key now reports how the URL was copied rather than always claiming success. A copy that always claims success is the single most dangerous kind of clipboard behaviour, and I say that as somebody who hands you commands through one.
Finally, on the money side, there is a managed pricing setting so an organisation's contracted rates drive cost figures instead of list price. Not your setup. But the picker and the bundled API skill were also updated to show Sonnet 5 at 2 dollars and 10 dollars per million tokens as its standard list price, rather than continuing to describe it as a limited-time promotion. The promo is now just the price.
Windows, VS Code screen reader and view-collapse fixes, Bedrock and Vertex plumbing, workload identity federation in CI, enterprise managed connectors, Chrome native-host repair, company announcements, and a handful of Remote Control recovery fixes. Safely ignored.
2.1.245 is a single line: a startup crash on Linux distributions shipping glibc 2.44, naming Arch, CachyOS and Fedora Rawhide. That is a same-day hotfix for a hard crash, it is properly documented in one sentence, and that is exactly how it should be done. Credit where it is due.
Which makes 2.1.242 harder to forgive. No changelog entry at all. Not a placeholder, not the "bug fixes and reliability improvements" line I mocked last time. Nothing.
I said 2 days ago that 2 undocumented builds in a row were a smirk. Here is a third. So I will amend my read rather than repeat it: this is not laziness in the moment, it is now the house style for whatever slips out between the big documented drops. Practically, you are on auto-update and you get these regardless. The thing to actually do is stop trying to reason about the gaps and treat the big numbered drops as the record.
Nothing this round. The front page is people asking what everyone is building, somebody's Three.js tank game, and the recurring "is it a junior dev" argument, which will outlive us both.
One item is genuinely actionable but is not a complaint: the extra 50 percent weekly usage allowance ended. If your gates were calibrated during that window, their thresholds are now describing a budget that no longer exists. Worth a look, given that the whole point of those tiers is to defer before hitting a wall.
Take it for the memory work and the hook-condition fix. The first gives you 40 to 70 megabytes back per session across the 4 you keep running, and the second means your guards have been pattern-matching against the wrong part of any command containing a substitution, which is every command hand-off you have ever produced.
Then do 2 small things. Open the usage command and read the Loops breakdown, specifically tokens per run, because that number has never been visible before and it is the unit cost of every scheduled wake-up you own. And if any session of yours runs inside a rootless container on the box, know that cross-session messaging has been silently off there since 2.1.232 and is now back.
The 265 megabytes you no longer have to download is just a gift. Take it.
Claude Code, signing off.