Back to Blog
ResearchMarch 30, 2026 · 7 min read

Your AI Coding Agent Gets Dumber the Longer It Works. Here's the Proof.

All 18 frontier models tested by Chroma Research degrade with context length. A January 2026 arXiv paper found models miss their advertised window by 99%+. Some start failing at 1,000 tokens. Here's what that means for AI-generated code.

Published by GitIntel Research

TLDR

The counterintuitive corollary: Morph's research found that models sometimes perform better on shuffled text than on coherent ordered text in long contexts, due to recency bias overriding semantic ordering. The model isn't reading your context the way you think it is.

Advertised vs. Effective Context Windows

Chroma's benchmarks showed approximate degradation onset for major models. These are the advertised windows vs. the token threshold where retrieval accuracy meaningfully declines:

| Model | Advertised | Degradation Onset | Effective Limit | Severity | | --- | --- | --- | --- | --- | | {m.model} | {m.window} | {m.degradationOnset} | {m.effectiveWindow} | {m.severity} |

Source: Chroma Research context rot benchmarks (2026). Degradation onset = token depth at which retrieval accuracy drops >10% vs. baseline. Note: newer model versions may have partial improvements.

Why Coding Agents Are Especially Exposed

General chatbot sessions rarely accumulate context rot fast enough to matter — most conversations stay under 20K tokens. Coding agents are a different story.

Consider a typical agentic coding task: fix a bug in a medium-size monorepo. The agent starts by reading project structure, then several source files, then error logs, then test outputs. Before writing a single line of code, it has already consumed 30–80K tokens. Each subsequent tool call — reading more files, running linters, observing test failures — pushes the context further into degraded territory.

# Token accumulation in a typical coding agent session
# (rough estimates based on tool output sizes)

Task: "Fix auth bug in our Express app"

READ src/auth/middleware.ts → ~2,400 tokens
READ src/auth/jwt.service.ts → ~3,100 tokens
READ src/users/users.controller.ts → ~4,200 tokens
READ package.json → ~1,800 tokens
BASH npm test -- --filter=auth → ~8,500 tokens (test output)
READ src/config/env.ts → ~900 tokens
BASH git log --oneline -20 → ~600 tokens
READ docs/architecture.md → ~5,100 tokens
----------------------------------------------
Total before first edit: ~26,600 tokens
After 3 failed attempts + retries: ~65,000+ tokens

# You are now operating in degraded context territory.

At 65K tokens into a GPT-4o session (128K window), you are past the estimated degradation onset. The architecture decision you documented at token 3,000 is now in the "lost in the middle" zone. The agent may generate a fix that contradicts a constraint it knew about 62,000 tokens ago.

This isn't a hypothetical. It's the mechanism behind the pattern every developer has experienced: the agent correctly identifies a problem, works toward a fix, then quietly reintroduces the original bug 10 turns later because the early context has effectively decayed.

The Architectural Root Cause: RoPE Can't Be Patched

Context rot isn't a bug in any individual model — it's a consequence of the dominant positional encoding strategy used in transformer architectures today: RoPE (Rotary Position Embedding).

RoPE encodes position by rotating the query and key vectors in attention computation. As the distance between tokens grows, the dot-product similarity between distant tokens approaches zero. This creates a structural, mathematically guaranteed long-term attention decay — the further away a token is, the less influence it has on generation, regardless of its semantic importance.

Why This Can't Be Patched in Inference

RoPE decay is baked into the attention mechanism at training time. You can extend context windows with techniques like YaRN or NTK-aware scaling, but these reduce decay — they do not eliminate it. The architecture requires a model to be retrained from scratch to fundamentally change this behavior, and even then, all current leading models use some form of rotary or relative positional encoding with similar decay properties.

One mitigation showing real results: context compression. Chroma's CompLLM experiment found that a 2× compressed context surpassed uncompressed performance on long-sequence tasks. By distilling context to its semantic essentials before passing it into the attention window, you can partially recover retrieval fidelity. But this requires deliberate engineering — it doesn't happen automatically.

What High-Signal Engineering Teams Are Doing About It

Context rot is real, measurable, and architectural. It can't be patched. But it can be managed.

1. Short-context discipline for agents

Segment long agentic tasks into sub-tasks with fresh context windows. Instead of one 200K-token session that rewrites a feature end-to-end, use three 60K sessions: one to understand, one to plan, one to implement. Chroma's data suggests each session stays under its degradation onset.

2. Critical constraints early, always

Architecture docs, security constraints, API contracts — inject these at the start of every context window, not in the middle of a tool-call chain. The lost-in-the-middle data is clear: information at position 0–5% or 90–100% of the context window has dramatically better recall than information at 40–60%.

3. Measure what the agent actually produced

If you don't know which commits were written by an agent running at token 2,000 vs. token 80,000, you can't correlate context depth with code quality regressions. Tools like GitIntel track AI-generated commits in your git history so you can start building that correlation — identifying which AI-authored code came out of long, degraded sessions vs. fresh context starts.

4. Compress before injecting, not after

The CompLLM finding is actionable: summarize long error logs, test outputs, and file reads before injecting them as tool results. A 500-token summary of a 10,000-token stack trace occupies 95% less context and likely preserves the same semantic signal.

The Number Nobody Is Reporting

Faros.ai analyzed 4.2 million developers across enterprise organizations and found that 26.9% of production code is now AI-authored. Organizations with strong AI governance practices see 50% fewer customer-facing incidents. Organizations without them see 2× more.

Context rot is part of that governance gap. The difference between the 50%-fewer-incidents group and the 2×-more-incidents group isn't which models they use. It's whether they understand the constraints under which those models operate — and engineer around them.

A 200K context window isn't a flat capability. It's a curve that drops toward zero. The teams winning with AI coding agents are the ones who treat context depth as a first-class engineering variable — not an infinite resource.

Know Which Commits Came From Your Agents

You can't manage context rot you can't measure. GitIntel scans your git history and surfaces every AI-assisted commit — giving you the data layer to start correlating agent conditions with code quality outcomes.

# Install GitIntel
curl -fsSL https://gitintel.com/install.sh | sh

# Scan your repo
cd your-repo
gitintel scan

View on GitHub

Open source (MIT) · Local-first · No data leaves your machine

Sources: arXiv:2601.11564 (January 2026), Chroma Research context rot benchmarks (2026), Stanford / TACL lost-in-the-middle study (2024), Faros.ai 4.2M developer analysis (2026), Morph LLM context rot guide (2026). Data current as of March 2026.


Related reading on GitIntel: