Your team is still doing something the expensive way because of a limit that no longer exists. You will not find it in a system, because it is not in a system. It is in how people work.
On 1 September 2026 Anthropic announced Claude Fable 5.1, and two sentences in the announcement matter more to a manager than the benchmark table did. The first: "Fable 5.1 will cost an estimated 25% less than Fable 5 for typical workloads, wherever usage is billed by token", with savings for highly agentic work often much larger, up to approximately 45 percent, driven by cache reads dropping to $0.25 per million tokens while input and output pricing stayed at $10 and $50 per million. The second: "In cybersecurity, our newest safeguards block 60% fewer false positives than before."
Both of those are constraints. Somewhere in your organisation, people built habits around them.
What does a constraint-driven workaround look like?
It looks like competence, which is why it survives.
Someone worked out that re-sending a long policy document on every query was expensive, so the team started pasting in extracts instead. Someone found the model would not engage with a security topic, so that class of work quietly went back to being done by hand. Someone hit a slow response on a big file, so the standing instruction became "split it first". Each of those was a good decision when it was made. Each of them encodes a fact about a tool into the way people work.
Then the fact changes. A price falls, a safeguard is tuned, a context limit lifts, a feature ships. The vendor communicates it through a pricing page, a changelog or a launch post. Nobody on your team reads those, and the person who invented the workaround has since moved teams.
So the workaround stays. And now it is pure cost, because the reason for it is gone.
Why does nobody catch this on their own?
Because nothing goes wrong. That is the whole mechanism.
Most operational review is failure-triggered. Something breaks, someone raises it, the process gets fixed. A workaround that has outlived its constraint does not break anything. The work still gets done, to the same standard, using more effort and more money than it needs. There is no incident, no complaint and no alert. The only signal is an absence, and absences do not escalate.
It is also nobody's job. The constraint was a fact about a vendor's product, owned by whoever manages the vendor. The workaround is a fact about how a team works, owned by the team. Those two things are tracked in different places, by different people, in different formats, and the connection between them lives only in the head of whoever first hit the wall.
This is the mirror image of the problem most AI governance is built for. The site has covered watching a model for drift after a successful pilot, and keeping a dependency register because every model has a retirement date. Both of those are defences against the tool getting worse or going away. Nobody builds a defence against the tool getting better, because it does not feel like a risk.
It is not a risk. It is a loss, and it compounds quietly. It is also the reverse of the AI review tax, where cheap production pushes cost onto reviewers. Here, cheap production arrives and nobody claims it.
What is the operating move?
A register and a trigger. Neither takes long, and both belong to the team lead rather than a central function, because a central function cannot see habits.
Build the register. Ask your team one question in a stand-up: what do we do the long way around because the tool cannot handle it? Write down what you hear, one line each: the practice, the limitation that caused it, roughly when it started, and roughly what it costs in time or money. Expect between five and fifteen entries from a working team. Expect at least two to be things you did not know were happening.
Set the trigger on the event, not the calendar. A quarterly review is the wrong cadence when a vendor can change the economics of a workflow in a single announcement. The trigger should be a version change, a pricing change or a change to safeguards on any tool your team depends on. One person subscribes to the release notes for the two or three tools that matter, and when something lands, the register comes out.
Run a short review. For each entry, one question: is the limitation still real? Test it rather than assuming, because vendor announcements are written to be flattering and the honest answer is sometimes that the constraint has moved rather than gone. Three outcomes are possible. The limitation is gone, so retire the workaround and tell everyone. The limitation has narrowed, so tighten the workaround to the cases that still need it. The limitation stands, so leave it and note the date you checked.
Close the loop out loud. This is where the register meets the norm you set for your team, because a habit is only retired when the people who hold it hear that it has been. A habit that has been normal for eight months does not disappear because a decision was recorded. Say it in the same forum where the original constraint was first complained about.
What are the signals if nobody volunteers one?
Some teams will not answer the question directly, either because the workaround feels like an admission or because it genuinely no longer registers as a choice. Four signals are worth watching for.
Manual preparation steps in front of an automated one. Anywhere a person reformats, trims or splits something before handing it to a tool, ask why. The answer is usually a limit, and limits move.
Work that quietly comes back to people. A task that was moved to a tool and then moved back is a strong signal, because the reason it came back was almost always specific and is rarely revisited.
Rules with no author. "We don't put that through it" is a sentence worth chasing. If nobody can say who decided or when, the decision is old enough to be worth re-testing.
Instructions that mention a number. A standing instruction to keep something under a certain length, or to a certain number of items, is a constraint written down in the language of practice. The number came from somewhere.
Anthropic's own framing of the change was an estimate of 25 percent less for typical workloads, wherever usage is billed by token. That is the size of movement a team will never detect from the inside, because nobody on it sees a unit price. It arrives as a line in someone else's announcement and lands, or does not land, depending entirely on whether a manager is looking.
Where does the leader's judgement stay?
Three places, and none of them can be delegated to the register.
Deciding what the constraint was actually protecting. Some workarounds were adopted for cost and some for caution, and they look identical on a list. A team that stopped putting a category of document through a model because the outputs were refused may have also, incidentally, stopped putting sensitive material through a third party. Remove the workaround and you remove both. The refusal was never the control. Check whether the control it was standing in for exists somewhere else, and if it does not, build it before you retire the habit.
Deciding whether cheaper should mean more. A 25 percent unit cost reduction can be taken as a saving or as permission to do more. Both are legitimate. What is not legitimate is letting the answer emerge from whoever notices first. If the constraint was the only thing keeping usage in check, removing it without a decision is how a budget line surprises you.
Deciding when not to change anything. A team that has just settled into a working rhythm does not need its practice re-cut every time a vendor ships. If a workaround costs little and the alternative would require retraining, keep it and record the reasoning. A register is a place to make that call deliberately, not a backlog of mandatory changes.
What does this look like in practice?
[TEAM] has been preparing a monthly regulatory summary. Eleven months ago, feeding the full source pack to the model on every pass was judged too expensive, so [TEAM_MEMBER] wrote a routine: pull the three most relevant sections by hand first, then summarise. That hand-extraction step takes about forty minutes a month and occasionally misses a section, which is caught in review perhaps twice a year.
The cost of re-reading a cached document has since fallen substantially. Nobody told [TEAM]. The forty minutes is still being spent, the two misses a year are still happening, and the person who built the routine has moved to another team. The routine is now unowned, unexamined, and defended by the fact that it works.
That is the shape of the thing. Not a failure. A rational decision, correctly made, that nobody had a reason to revisit.
The bottom line
- Teams encode tool limitations into working habits, and those habits do not expire when the limitation does.
- Nothing breaks when a workaround outlives its constraint, so no failure-triggered process will ever surface it.
- Anthropic's 1 September 2026 release moved two constraints at once, cost and cybersecurity refusal behaviour, which is a normal week for a frontier vendor.
- The fix is a short register owned by the team lead, and a review triggered by a vendor version or pricing change rather than by the calendar.
- Some workarounds are load-bearing controls in disguise. Check what the habit was standing in for before you remove it.
Do this Monday
- Ask your team the single question: what do we do the long way around because the tool cannot handle it? Write down every answer.
- For each entry, note the limitation that caused it and roughly what the workaround costs each month in time or money.
- Nominate one person to watch release notes and pricing pages for the two or three tools your team actually depends on.
- Test the top three entries against the current version rather than assuming, and mark each one retire, narrow or keep with a date.
- For anything you retire, check first whether the workaround was quietly acting as a control, and if it was, replace the control before you drop the habit.
- Announce the retirements in the forum where people originally complained about the limit, or the habit will simply continue.
References
- Anthropic, Introducing Claude Fable 5.1 and Claude Mythos 5.1, 1 September 2026
- Anthropic, Developing Enterprise Frontier Safeguards with our customers, 1 September 2026
- TheAICommand, AI passed the pilot. Now govern the drift.
- TheAICommand, Every model has a retirement date
TheAICommand. Intelligence, At Your Command.
