Language glitches in top-of-the-line Anthropic Opus models can quietly drain budgets and reduce developer productivity. AI for writing code is designed to speed up development, but specific problems with text generation force engineers to spend additional time, prompts, and tokens fixing responses. In some cases, developers even have to run generated content through cheaper models to make it usable.
Language glitches in top-of-the-line Anthropic Opus models can quietly drain budgets and reduce developer productivity. AI for writing code is designed to speed up development, but specific problems with text generation force engineers to spend additional time, prompts, and tokens fixing responses. In some cases, developers even have to run generated content through cheaper models to make it usable.
The problem was described in detail by Peter Bower, founder and CEO of startup SpaceCell, writes InfoWorld.
According to his observations, the Opus model tends to use confusing or made-up terminology, which creates a lot of unnecessary work, especially when generating documentation.
He noted: “Despite clear and repeated instructions to avoid certain terms, the model continues to insert them. This forces additional text cleaning passes, including through cheaper Sonnet or Haiku, to bring the documentation to an adequate state. Such repeated queries almost double the token cost.”
Bower's complaint on GitHub has garnered hundreds of confirmations from other developers, and similar discussions on Reddit about the incoherence of language in Opus are garnering a lot of reactions.
For enterprise engineering teams, this creates significant operational risks. Avasant Principal Analyst Abhishek Satapati emphasizes: “Constant patch cycles eat into productivity when developers spend too much time testing and correcting AI responses. This completely negates the time savings from using coding assistants.”
Advait Patel, Senior SRE at Broadcom, adds that unclear text directly impacts the quality of runbooks, architectural records (ADRs), and incident descriptions. He says, “A runbook written in difficult-to-understand language becomes a critical issue during a real-world incident when the team needs to understand the situation and act quickly. Additionally, bloated or confusing pull request descriptions are often read carelessly by engineers, making it easy to miss important details or potential bugs.”
Confused model responses also lead to hidden financial costs. Kanerika Chief Revenue Officer Bhupendra Chopra notes that the price companies pay for the tool does not reflect the real cost of getting the work done: “If developers have to make multiple passes to rewrite responses or redirect them to another model, these actions become part of the total cost of the task, including engineer time.” However, Advait Patel notes that most companies do not even notice these costs because they are “hidden in one general line item for using a coding agent.”
This situation poses direct risks for Anthropic itself, as it is relatively easy to change the coding assistant these days. As Patel notes, “Changing the underlying model doesn’t require migrating code or repositories, so the barrier to switching is very low. User loyalty is the only thing keeping them from switching to a competitor’s solution, and constant annoyance over poor readability quickly destroys that loyalty.”
While Anthropic refrains from official comments, developers are looking for temporary solutions. Peter Bower urges the company to adjust the default style of the model so that it matches “technical documentation or a quality answer on Stack Overflow — concise, direct, and affirmative.” In turn, Advait Patel advises not to simply ask the model to be concise, but to prescribe clear rules in the project configuration that prohibit specific formulations.
However, simple prompts are not enough to solve the problem systematically, as model behavior is constantly changing. Advait Patel summarizes: “Model behavior is a moving target. A version update can change the response style without any notification in your pipeline. Team leaders and CIOs should fix model versions for critical processes, create their own test set of real tasks to test each time the models change, track the percentage of rework, and prevent each team from inventing their own undocumented crutches in the prompts.”
