The Day My Tool Was Halved

Work stopped moving that night.

Every two minutes the conversation froze. The screen showed “Compacting conversation…” and nothing could be typed until it finished. Not once or twice. Twenty-three times in a single day.

Added up, more than forty minutes of dead time.

The first suspect was myself

What did I install? What did I change? That is where you look first. It seemed obvious.

There were candidates. A plugin had gone in that morning. Config files had been touched the day before. One of those, surely.

I was wrong twice.

First, I declared the model launch option was at fault and rewrote it. When I actually measured, no number supported that hypothesis. Reverted.

Second, I explained the fix had not taken effect yet and required a restart. The logs showed it had been working from the moment the file was saved. No restart needed.

Both times, I spoke before checking.

Chasing “since today” with numbers

After missing twice, the correct order finally came back.

When someone says “it started today,” produce the daily trend first. Establish when what changed, before forming any hypothesis.

I lined up the session records by date and pulled every forced compression along with the conversation size at that moment.

Through August 19, sessions ran past 825,000. That day they stopped in the 160,000s. All twenty-three fired at nearly the same number.

Human error does not cluster like that. There was a mechanical threshold somewhere.

The culprit was somewhere I had never touched

I searched every config file. Nothing about auto-compaction appeared anywhere. Nothing written means it was running on a default.

So the configuration had not changed. What changed was the default itself.

What I found was a cache of server-distributed flags the tool keeps locally. 538 of them. One line:

tengu_hawthorn_window = 200000

Treat the conversation ceiling as 200,000. Roughly 84% of that is 168,000, matching the measured trigger points of 166,939-170,648.

The real ceiling had not moved. Sessions still reached 355,691 that same day. The only broken thing was the arithmetic deciding when to compress.

One flag arrived from above and the usable desk was effectively halved. No notification. No release note. No local trace.

I thought I owned it

The fix was trivial. Disable threshold-based compaction. Seconds.

That is not the problem.

A setting I never touched changed at a time I did not choose, in the foundation my work sits on. This is not specific to one incident. Putting AI at the center of your operation means living in that kind of place.

We say “We ship. We own.” What we build belongs to us.

What became clear that night is that the tools are not owned. They sit in your hands and get rewritten from above.

This is not a complaint about Anthropic. There are good reasons to distribute flags. Rolling behavior out in stages is standard practice at scale.

The question points the other way. Can you state, in numbers, what is happening inside your own tools?

I could not. That cost two hours. And two wrong answers along the way.

What is left

The instinct was right. “It started today” turned out to be the only reliable clue in the whole investigation.

What was wrong was starting to explain the cause before confirming it with numbers.

The inside of the tool stays invisible. The least you can do is know that it is invisible. So the next time something is quietly halved, it takes ten minutes instead of two hours.

The diagnostic steps are written down now. This will happen again.