Claude Getting Dumber and Pricier? Developer's Overnight Test Drains a Week's Quota, Sparking Controversy

A Developer's Late-Night Experiment

A Reddit user recently posted a complaint that Claude has been acting "both dumber and more expensive" lately, striking a chord with the developer community. The post described a multi-agent workflow the user had grown to rely on: a Fable orchestrator dispatching Opus or Sonnet subagents to handle specific coding tasks.

The setup is fairly representative — the orchestrator itself was prohibited from writing code directly, and was only responsible for reviewing and merging PRs (Pull Requests) submitted by subagents. This kind of "division of labor" architecture is becoming increasingly common in AI-assisted programming, and in theory balances efficiency with quality control.

A multi-agent workflow is an architectural pattern that breaks complex tasks down across multiple collaborating AI instances. The "orchestrator" handles task planning, delegation, and result integration — essentially acting as a project manager — while "subagents" focus on executing specific atomic tasks. Fable is an orchestration framework designed specifically for AI programming scenarios, allowing developers to define role-based permissions for each agent (in this case, the orchestrator was barred from writing code directly) and uses PRs as quality checkpoints for code delivery. The core advantage of this architecture is that separating roles keeps each agent's context window relatively short, which theoretically reduces "attention drift" and enables parallel speedups. However, this design also introduces new fragility: when subagent output quality degrades, an orchestrator lacking effective anomaly detection can trap the entire system in a "review-fail-review-fail" loop — and each iteration burns real API quota.

An Entire Week's Quota Gone Overnight

The trouble started during one particular "overnight run." The developer handed off a task to the system and stepped away. When he came back the next day, the pipeline had consumed his entire weekly Fable quota, plus 75% of his total weekly quota.

What baffled him even more was the process itself: the orchestrator and one subagent had gone through nineteen rounds of revisions on the same PR, repeatedly fixing and re-introducing the same bugs, spinning their wheels indefinitely. In his own words, "I'm pretty sure it wasn't this dumb before" — based on past experience, the Opus subagent should have arrived at a correct solution much faster, and the Fable orchestrator should have detected the stalled progress and either adjusted strategy or stopped to ask a human for help.

Abnormal Quota Burn Rate

The user also raised a noteworthy quantitative observation: in the past, running just 3 agents (including 1 Fable) meant it was essentially impossible to exhaust his quota in roughly 12 hours.

This suggests the problem may be twofold:

• Degraded agent reasoning ability: unable to solve the problem in one pass, falling into an inefficient loop of repeated revisions;
• Higher cost per unit of work: whether measured by token consumption or quota accounting, actual spend was significantly higher than expected.

Combined, these two factors produce the intuitive sense of something getting "dumber and pricier" — the model's problem-solving ability declines, while the number of iterations and resources consumed increases.

How to Interpret This Kind of Subjective Report

It's worth noting calmly that this is a single-source report based on subjective experience, with no rigorous controlled experiment data to back it up. The sense that AI models are "getting dumber" is a long-running controversy in the community, and there are multiple possible explanations:

• Silent updates to the model or routing strategy causing behavioral shifts;
• Performance fluctuations during periods of high server load;
• Changes in the complexity of the user's task or the state of the codebase;
• The inherent fragility of multi-agent architectures — when a subagent falls into an error loop, costs can grow exponentially if the orchestrator lacks an effective "circuit breaker."

That last point deserves special attention from developers working on AI-assisted programming: the runaway cost risk in multi-agent systems is a real engineering hazard. When an orchestrator can't recognize a "useless loop," a single overnight run is enough to drain your entire quota.

Lessons for Multi-Agent Developers

Regardless of whether Claude has actually "regressed," this case offers practical takeaways:

1. Build hard circuit-breaker conditions into automated workflows — for example, forcibly stopping if the same PR exceeds N rounds of revision;
2. Avoid long, unattended overnight runs, especially in scenarios involving quota consumption;
3. Add "progress detection" logic to the orchestrator to identify signs of spinning in place and proactively escalate to a human.

This kind of real-world feedback from practitioners reveals the limits and pitfalls of AI programming tools in actual production more clearly than any vendor marketing ever could.

The "circuit breaker" pattern is a fault-tolerance approach borrowed from distributed systems engineering: when a dependent service fails continuously beyond a threshold, the call chain is automatically cut off to prevent cascading failures and resource exhaustion. The same thinking applies to multi-agent AI workflows — concrete implementations could include tracking retry counts for the same task and capping them, comparing the semantic similarity of adjacent outputs (high similarity signals spinning in place), and monitoring cumulative token consumption per task against a budget ceiling. "Progress detection" goes a step further, requiring the orchestrator to judge whether a task is actually moving toward its goal, not just whether output is being produced. Both mechanisms remain optional configurations rather than defaults in most AI orchestration frameworks today — and that is the root engineering cause behind the quota runaway described in this article.