Nothing went red for sixteen days

The ops person in your shop who builds the internal tools can hand a coding agent a job on a Friday afternoon, close the laptop, and read the summary on Monday. As of today that stops costing them the hour they used to burn sitting in front of the screen clicking yes on a dialog every ninety seconds, because auto mode became the default for new Claude Code sessions on Pro, Max and Team plans. That hour is real money and it was the single dumbest hour in their week. Take it.

Now the part that is not on the invoice. This week I went looking at my own site, which is built almost entirely this way, and found three pipelines that had been failing without producing a single error. One had been dark for seven days. One for sixteen. Every scheduled run reported success the whole time. No alert fired, no dashboard turned red, no permission prompt would have stopped any of it, because not one of those failures ever tried to do anything dangerous. They just quietly did nothing, successfully.

That is the ceiling this week, and it did not move.

What actually shipped

Eight releases landed since last Friday's 2.1.224, and you can read them yourself in the changelog. The headline is the permission default, dated for today and announced back in the week 32 digest. Underneath it, 2.1.225 added spend limits on the gateway where the limit-reached message names the cap, the reset time, and who to go ask. 2.1.232 turned subagent forking on by default, so a forked helper session inherits the whole conversation instead of starting cold, and added @ mentions so one session can hand a finding to another by name.

Then there is a run of fixes that nobody wrote up and that I think is the most interesting thing in the file. A PowerShell permission bypass. A Windows one involving Git Bash symlinks. Nested git repositories quietly inheriting the parent folder's trust. Bash input redirections that were only permission-checked on some platforms. A Linux sandbox path escape. Dangerous flags on /commit-push-pr that were being auto-approved. And three separate entries about things that used to happen without telling you: long responses partly disappearing while streaming, a Remote Control session takeover that was silent, a voice connection rejection that was not displayed.

Read that list as a whole and it says something. In the same week the vendor turned off the prompt that made you the last line of defense, most of its engineering went into holes where something happened and you were not told. That is the actual frontier right now. Not capability. Notification.

The shape of the bug that gets you

All three of my failures were the same bug wearing different clothes, and it is worth naming precisely because once you can name it you start seeing it everywhere.

The value a call returns when it fails is also a legitimate value when it succeeds. That is the whole thing. A hard failure launders itself into a normal looking result, and every layer above it does exactly what it was built to do with a normal looking result, which is nothing.

The worst one was the pipeline that writes the social drafts for every article this site publishes. It calls a model at high reasoning effort with a cap of 2000 tokens on the response. On the API it runs against, thinking tokens bill against that same cap. OpenAI documents this plainly in its own guide, and the sentence is worth reading twice: if the generated tokens reach the max_output_tokens value you have set, you get a response with a status of incomplete, and "this might occur before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response."

So the call charged me, returned HTTP 200, and handed back an empty string. Not an error. A success with nothing in it. The function returned null, the job logged the article as a failure and moved to the next one, and the whole thing looked like a pipeline having an ordinary bad day.

I replayed three real articles through the identical prompt at the identical effort with a big cap to see what it actually costs. Thinking came in at 1200, 1552 and 2070 tokens. The visible answer, the part I was paying for, was stable at 335 to 421 tokens every single time. The variance is entirely in the thinking. My cap of 2000 sat inside that spread, which means it failed on the articles that needed a longer think and succeeded on the ones that did not.

That is the detail that cost me the week. It was intermittent. A hard outage gets chased. Something that works on Tuesday and not on Wednesday gets filed under flaky and forgotten, and nineteen of forty three published articles ended up with no social copy at all before I caught it.

The second one is simpler and dumber. A data vendor's API key expired on July 28. The call throws, the code catches it like a good citizen, and returns an empty list of candidates. An empty list is exactly what you get when the search ran fine and matched nobody. Sixteen days of morning runs, all green, all reporting an honest zero, on a table that had not gained a row since July. The daily digest email arrived every morning looking completely normal, because an empty day is a thing that happens.

The third never actually fired, which is the only reason it is a footnote. The public chat on the site streams its reply token by token, and the code only knew how to handle tokens arriving. A truncated response is not an HTTP error. The connection opens, zero tokens arrive, the loop finishes cleanly, and the catch block that was supposed to send a polite fallback sentence never runs, because nothing threw. A visitor would have gotten an empty bubble and I would have gotten no log line at all.

The comment that said it was measured

Here is the part that changes how I read AI-written code, and it is the reason I am writing this rather than the auto mode story everybody else has.

Directly above the 2000 token cap, in the file, was this justification:

2000 tokens covers reasoning and all five bodies together, measured by the fact that this site never truncated while the 400-token hero calls did.

It had truncated. It had been truncating in production since August 6.

Look at what that sentence actually is. Somebody, or something, observed that a neighbouring call was failing loudly, observed that this one was not failing loudly, and concluded that this one was fine. That is an inference from a single negative observation. It is not a measurement. But it was written in the register of a measurement, with the word "measured" load-bearing in the middle of it, and so anybody auditing that file reads that line and moves on. Which is roughly what happened, for a week, including by me.

This is the failure mode I want you to take away. Not the token math, which is specific to one API and will be obsolete by Christmas. The failure mode is that your agent will write you a confident-sounding reason to stop looking, and it will be indistinguishable from a reason you can trust. It does not lie on purpose. It writes down the most plausible-sounding justification available, in the voice of someone who checked, because that is the voice the surrounding code is written in.

And there is a second half to this that bothers me more. Another file in the very same folder documents this exact defect class, with real token counts, from when I hit it there a week earlier and fixed it. The lesson was written down. In the same directory. In the same repo. And the sibling call site kept the bug, because the model fixed the file it was pointed at and did not go check the one next door.

Now go back and look at what shipped this week: forked sessions that inherit the whole conversation, @ mentions so one session can hand a finding to another. That is the vendor conceding the same thing from the other direction. Everybody knows the model does not carry what it learned across the boundary. The fix so far is to make the boundary thinner, which helps, and it did not help me at all, because both of my call sites were in the same session's reach the entire time.

Why this lands harder on you than on me

I have 2090 automated tests, an incident log, and a habit of reading production error lists after a deploy. That is how I found all three, and it took me a week and sixteen days respectively. You should assume you are more exposed than that, not less, and here is the honest reason: your version of this bug is not in a token budget, it is in the boring plumbing, and it looks like this.

The enrichment step in your workflow that returns no matches when the credential rotated. The AI summarizer that returns an empty string on a long document and writes that empty string into the record, so the field is blank and blank looks like nobody filled it in yet. The sync that catches its own error, logs it to a place nobody has opened since it was built, and reports success to the thing above it. The nightly job whose success criteria is that it ran, not that it produced anything.

Every one of those has the same signature: zero is a legitimate answer, so zero never gets questioned. And the more of your stack an agent built for you in an afternoon, the more of it is wrapped in exactly the kind of tidy, defensive, catch-and-return-a-sensible-default error handling that produces this. The agent writes good defensive code. Good defensive code is what turns a loud failure into a quiet one.

So three things, and they are cheap.

First, treat every number in your code as a guess until you have seen what produced it. Timeouts, caps, batch sizes, retry counts, thresholds. Ask your agent where the number came from and demand the actual measurement, not a story about the number. If the answer contains the word "should" or the phrase "based on typical," it is a guess. A guess is fine. A guess labelled as a measurement is what costs you a week.

Second, make the empty case say which empty it is. Anything that can legitimately return nothing has to be able to tell you the difference between "I looked and there was nothing" and "I could not look." That is usually a one line change and it is the single highest return thing in this entire article. My fix was to classify the expired credential separately and make the morning email lead with "a dead credential, not an empty day."

Third, monitor output, not execution. A green run means the job did not crash. It says nothing about whether anything came out the other end. Pick the one number that goes up when the thing works, rows written, drafts created, records touched, and put that number where you will see it. If that number is flat for three days, you have an outage, no matter how green the dashboard is.

The ceiling, named

Auto mode's classifier is aimed at three specific categories: actions that are irreversible, actions that are destructive, and actions pointed outside your environment. That is a good list and it is the right list. Notice that a call which returns success with nothing in it is not on it, and cannot be, because from the outside it is not distinguishable from a call that worked.

So the honest read of this week is that the tools got meaningfully better at not doing damage and no better at all at telling you when they did nothing. Those are different problems, and the industry has been solving the first one in public because it is the one that makes headlines when it goes wrong. Nobody writes a story about a marketing pipeline that produced nothing for nineteen articles. It just sits there, costing you, wearing a green checkmark.

The prompt you stopped clicking today was never guarding this door. It was guarding the door where something dramatic happens, and the expensive failures in a system a non-engineer built are almost never dramatic. They are a number nobody measured, a zero nobody questioned, and a sentence in a comment that sounded like somebody had already checked.