Context rot is the measurable decline in a language model's output quality as the amount of text in its context window grows, even when the input is still well below the model's advertised limit. The model is not running out of room. It is getting worse at using information that is already in front of it. Chroma's July 2025 research report tested 18 models and found that across all of its experiments, performance consistently degraded as input length increased, and did so non-uniformly. Degradation was worse when the context contained plausible but irrelevant material.

What is the difference between context rot and context poisoning?

Context rot is driven by length. The more tokens in the window, the less reliably the model uses any of them, even when nothing in the context is wrong. Context poisoning is driven by content: one wrong fact, a bad assumption, or a failed approach enters the context and the agent keeps referring back to it. Length degrades the agent's attention, poisoning corrupts its premise. They compound, because a long session gives a bad fact more turns to get repeated, and the fixes differ. Rot is answered by shortening the context. Poisoning is answered by removing the specific wrong thing, which in practice usually means starting a fresh session.

How do you detect context rot in an AI coding agent?

The cheapest detector is a canary: put an arbitrary, memorable fact at the very start of the session, something the agent has no other way to know, then periodically ask it to repeat that fact back. While it answers correctly, the early context is still being used. When it forgets or garbles the answer, the beginning of your session has stopped meaningfully influencing the agent's behavior, which is your signal to reset before you spend more time on output you will have to throw away. Watch behavior too: duplicated code, re-implementing something that already exists, and repeated returns to a fix that already failed are all late symptoms.

Does a bigger context window fix context rot?

No, and this is the most expensive misunderstanding in the category. Context rot is defined by degradation well inside the window, so a larger window raises the ceiling on what you can load without changing how reliably the model uses it. A bigger window can make things worse in practice, because it removes the forcing function that used to make you curate what the agent sees. The useful responses are architectural: keep the working context small, split work across separate context windows, compact aggressively, and give the model an external way to check its work rather than relying on it to remember.

Context Rot: What It Is and How to Catch It

Every founder running coding agents has had the session that turns. The first hour feels like a superpower. By hour three the agent is confidently rewriting code it already wrote, re-introducing a bug you watched it fix, and defending an assumption that was never true.

That failure has a name now: context rot, the decline in a model's output quality as its context window fills, even when the input is still well under the model's limit. Picking the right name matters, because the three names in circulation point at three different fixes.

What context rot actually is

Context rot is the decline in a model's output quality as the amount of text in its context window grows, even when the input is still well under the model's advertised limit.

The important word is under. This is not the model running out of room and truncating. It is the model getting worse at using information that is already in front of it, while there is still plenty of room left.

The term was formalized in a July 2025 report from Chroma, by Kelly Hong, Anton Troynikov, and Jeff Huber, which tested 18 models on tasks the report deliberately kept simple so that input length was the only thing changing. The finding that should change how you work: across all the report's experiments, model performance consistently degrades as input length increases, and it degrades non-uniformly. Tasks a model handles reliably at short context become unreliable at long context, even when the task itself never got harder. The report also found that adding a single plausible but irrelevant distractor to the context measurably hurt performance, and adding four compounded the damage.

Read that as a founder and it says something uncomfortable: the amount of context you give an agent is not a free variable you turn up until you run out of window. It is a budget you are spending against quality.

What causes context rot

Two mechanisms, and knowing both tells you which fix to reach for.

The first is that models do not use their context uniformly. Attention is a finite resource spread across everything in the window, so every token you add competes with every token already there. Chroma's results show this is not a graceful slope: the same model degrades at very different rates depending on how the task is shaped. Retrieval that depends on an exact lexical match holds up better than retrieval that depends on semantic similarity, and irrelevant material that is topically close to what you actually want does more damage than obvious noise. That last point is the trap in an agent session, because everything the agent read on its way to the current problem is topically close by construction.

The second is a training-distribution problem, and French-Owen states it plainly on the episode: "there's a lot of training data on the internet for like what is the next sentence that comes or like what's the next paragraph that comes." Predicting the next sentence from the last paragraph is a task the internet supplied endless examples of. Deciding, 80,000 tokens into a session, that the relevant thing is something from token 20,000 is a task with far less training signal behind it. Long-horizon reasoning over a long context is the part these models were least trained for.

Both mechanisms point the same way: the useful lever is not a better prompt at the end of a long session. It is a shorter session.

Context rot, context poisoning, and the dumb zone

Three terms get used interchangeably in founder chat groups. They are not the same failure, and the response to each is different.

Context rot is a length problem. Nothing in the context is wrong. There is just too much of it, and the model's ability to reason over any particular piece has degraded. The fix is to make the context shorter.

Context poisoning is a content problem. One wrong fact, a bad assumption, or an approach that already failed has entered the context, and the agent keeps returning to it. On Y Combinator's Lightcone episode on coding agents, Calvin French-Owen describes the mechanism precisely. He co-founded Segment and was its CTO, sold it to Twilio in 2020, then joined OpenAI in May 2024 and worked on Codex before leaving in June 2025, so he has watched this from inside both a startup and a frontier lab.

French-Owen calls context poisoning "a real thing", and the mechanism he describes is what makes it costly: the agent goes down one loop and keeps going, because persistence is what these models were trained into, all while "referring back to tokens which are like not right in terms of pursuing a solution." The persistence that makes an agent great at grinding through a bug five levels deep is the same property that makes it grind for an hour against a premise that was wrong in minute two.

The dumb zone is the operating rule. The term belongs to Dex Horthy, founder of HumanLayer (Y Combinator, Fall 2024), and it comes up by name on the Lightcone episode: the region past which the model starts visibly degrading. Horthy's answer is a budget rather than a warning light. In Advanced Context Engineering for Agents he says the goal is to keep context utilization under 40 percent, and to compact often enough to stay there instead of filling the window because it is available. Treat that as his team's working target, not a measured line where quality falls off: HumanLayer's written version puts the range at 40 to 60 percent depending on how complex the problem is.

The three compound. A long session gives a wrong fact more turns to get restated, and each restatement makes it look more like established truth to the next turn. That is why sessions do not degrade gracefully. They feel fine, then they fall over.

Why context rot hits coding agents harder than chat

Two properties of coding agents make this worse than it is for a chat assistant.

The first is persistence. Coding agents keep going no matter what, an observation French-Owen raises on the episode and credits to Andrej Karpathy. A wrong turn therefore does not produce a stop. It produces more work built on the wrong turn.

The second is that agents default to addition. French-Owen describes what they do as "typically just making more of whatever's there". If your codebase has a pattern, the agent will produce more of that pattern, good or bad. If your context has a wrong assumption, the agent will produce more code consistent with the wrong assumption.

He puts the consequence in terms any founder can act on: "if it latches on to something that isn't quite right, it doesn't have a lot to go on", and "if it misses something that's essential, it's going to just reimplement it". Duplicated code and re-implemented functionality are not random agent quirks. They are the visible symptom of an agent working from a context that no longer describes reality.

There is a longer-horizon version of the same point, and it is the one worth pinning to your wall: whatever you supply to the coding agents is the kernel, and "that kind of kernel is going to be what they run with and make more of forever more". The context you set at the start of a session is not an input. It is a multiplier.

The canary: how to catch it before it costs you a day

The detection method that comes up on the episode is the cheapest instrumentation in this entire category, and almost nobody runs it.

Put a canary at the start of the session. The trick, described on the episode as something founders do, is to put "a canary at the beginning of the context": something arbitrary and memorable that the agent has no other way to know. A name. A specific time you drank tea. Any fact with no relationship to the codebase.

Then, periodically, ask for it back. Do you remember my name? Do you remember what time I drank the tea? While the agent answers correctly, the beginning of the session is still shaping its behavior. The moment "when it starts forgetting", the early context has stopped meaningfully influencing the output, and everything the agent produces from here comes from a partial picture.

Two honest caveats. On the episode the forgetting signal is offered as a sign the context has been poisoned rather than as a length measurement, and it is a proxy for both: a window the model can no longer hold in full is also a window where a wrong fact planted early can sit unchallenged. And the reply the trick draws on the episode is "I have not tried this, but I fully believe it", which tells you how young this practice is. It is a cheap instrument, not a validated one.

The canary works because it converts an invisible, gradual failure into a binary signal you can check in five seconds. Without it you are relying on noticing that the output got subtly worse, which is exactly the thing a tired founder at hour three does not notice.

Behavioral tells are the backup, and they are all late signals:

The agent re-implements something that already exists in the codebase.
It returns to a fix you already watched fail.
It starts changing files that have nothing to do with the task.
Its summaries of what it has done stop matching what it actually did.

By the time you see these, you have already paid for the rot. Use the canary.

How to fix context rot: clear, compact, or delegate

Once you have the signal, you have three responses, and choosing between them is the actual skill.

Clear, when the context is poisoned. If a wrong fact is in the window, shortening the context does not reliably remove it, and compaction can carry the wrong fact forward in condensed form. Start fresh and re-seed with what is true. French-Owen says he does exactly this, that he will "very actively clear context", and his trigger is more aggressive than most founders run: he clears "when it gets above like 50% tokens", which lines up closely with Horthy's 40 percent threshold and sits far below where most people think about resetting.

That number is the change most founders can make today. If you clear context when the tool warns you about the window, you are clearing it roughly twice as late as the people who built these agents.

Delegate, when the work is separable. The alternative to holding everything in one window is not holding it at all. French-Owen's read on why Claude Code performs well is that it manages to "split up context well": it spawns exploration sub-agents that traverse the codebase in their own context windows and return a summary, so the searching never enters your main window. The founder version is to stop asking one long-running session to hold the whole task, and to structure work so each piece can go to a fresh context that returns a small answer. If you are running several of these at once, that is a distinct discipline, and we covered it in running a fleet of coding agents in parallel.

Compact, when the session must continue. Compaction summarizes the window so work can continue past its limits. It is the weakest of the three, because a summary of a poisoned context is still poisoned, and because summarizing is itself a lossy operation performed by the same degraded model.

The one case where none of this saves you is worth naming plainly. French-Owen still calls the context window "probably the number one limit", and for a problem genuinely too large to fit, "no amount of compaction is going to help". If the task does not decompose, the answer is not a better prompt. It is a smaller task.

How Claude Code and Codex handle context rot differently

It is worth knowing that the tools you use have made different bets here, because it changes which failure you will hit.

Claude Code holds a session's context and leans hard on delegating outward to sub-agents with their own windows. Codex leans the other way: French-Owen notes it will "run compaction like periodically after each turn", which in his telling is what lets it run for much longer stretches on a single job.

The contrast is one of emphasis, not of kind. Both tools compact, and both do it automatically as the window fills. The difference is how aggressively each one compacts and how much of the work it prefers to push into a separate context instead.

Neither bet is correct in general. If your work is a long, unattended, single-thread job, frequent compaction is the behavior that matches it. If your work is interactive and exploratory, delegating to fresh windows preserves quality better. Founders who complain that one tool gets dumb are frequently running a workload the other one was tuned for.

How to prevent context rot in your codebase

The best fix is upstream of all of this, and it is a design decision rather than a technique.

Write less plumbing. French-Owen's first answer for how to get more out of coding agents is to use "far less code and plumbing": stacks where boilerplate is handled for you, and work defined in one or two hundred lines rather than spread across service discovery and registration. Every line the agent has to read to understand your system is a line spent from the quality budget.

Keep modules small and well bounded. The reason grep-based agents work at all, in his framing, is that "code is very context dense": a line of code is probably under 80 characters and carries real meaning, and a codebase does not hold many large data blobs. A well-factored codebase is not just nicer for humans. It is cheaper in tokens for an agent to understand, which means more of the window is left for thinking.

Give the model a way to check its work. This is the item on the list with the biggest payoff. In French-Owen's words, "giving the model a way to check its work helps improve performance drastically", which in practice means tests, lint, and CI the agent can run itself. Tests are how an agent detects that its context has drifted from reality without you having to notice. On the same episode, Garry Tan describes going a few days into an intense coding stretch with very few tests, then dedicating a day to test coverage: "I was surprised how important testing was", and after that, "And then I just sped up like crazy". Test coverage is not overhead in an agentic workflow. It is the sensor. We went deeper on this in how testing changes when AI writes the code.

This is also where context rot connects to the broader discipline of context engineering for AI agents. That work is about supplying the right context in the first place. This one is about what happens to context you already supplied as a session wears on. You need both: the best-assembled context in the world still degrades if you never reset it.

Context rot is also a security problem

This is worth flagging, because most coverage treats context rot as a quality issue only.

The connection is my own, not something anyone argues on the episode, and it is this: a degraded context is an easier context to manipulate. If a model is already unreliable at using what is in its window, an injected instruction sitting in that window competes on more even footing with your actual instructions. French-Owen's account of building Codex at OpenAI shows how low the bar already is without any degradation at all. Prompt injection was one of the things the team looked into before opening the product up to the internet, and when a colleague planted an obvious injection in a GitHub issue and asked the model to fix that issue, "immediately the prompt injection works".

His read on the incentive gap is the part founders should sit with: "if you're a startup where you're just like running fast, you probably don't care". You just want it to work. On the episode, the split on skipping permission prompts is put at "about 50/50 on the YC engineering team."

That is a defensible choice on a throwaway prototype. It is not defensible the moment the agent can reach a production database, a customer's data, or a deploy pipeline. The practical line: run permissive on repos where the worst case is losing your own afternoon, and keep approval gates on anything holding secrets, customer data, or the ability to ship. A long-running agent session with a poisoned context and unrestricted permissions is not a productivity setup. It is an unattended actor with bad information and production access.

What context rot costs a startup

The reason to care is not elegance. It is that context rot is a silent tax on the exact thing you adopted agents for.

The cost is not the bad output. Bad output you can see and throw away. The cost is the bad output you ship, plus the hours between the moment the context went wrong and the moment you noticed. That gap is where the money goes, and it scales with how long you let a session run unexamined.

There is a human version of the same problem, and the episode names it well: the industry has built "context management for agents but like we also need context management for humans". A founder running six agent sessions is holding six contexts, and human context rots too. The founder who checks a canary every twenty minutes is not being pedantic. They are refusing to pay for three hours of confidently wrong work.

Treat context as a managed resource rather than a setting and this stops being a tooling complaint. It becomes one of the engineering habits that separate teams shipping real work with agents from teams generating volume, which is the same thread running through our guide to AI for startups.

What to do this week

Add a canary to your next long session. One arbitrary fact at the top. Ask for it back every twenty minutes or so. The first time it comes back wrong, you will know exactly how long you have been working with a degraded agent.
Move your reset trigger to 50 percent of the window. Not when the tool warns you. Clear early, re-seed with what is true, and watch whether your throughput goes up.
Learn to tell rot from poisoning. Too long, or working from something wrong? If a wrong fact is in the window, do not compact. Start clean.
Stop holding the whole task in one window. Break work into pieces small enough that a fresh session can complete each one and return a short answer.
Spend a day on test coverage before you spend another week on prompts. Tests are how an agent catches its own drift, and it is the cheapest reliability upgrade available.
Draw your permission line by blast radius. Skipping permission prompts on throwaway repos is fine. Anything touching secrets, customer data, or deploys keeps a human gate.
Delete plumbing. Every service, config layer, and indirection you remove is context budget you get back on every agent run, forever.

If you want the full operating system for running a startup this way, from how you scope agent work to how you keep the security posture that lets you move fast without shipping someone else's instructions, that is what we teach in AI Operating System for Startups.

Sources

We're All Addicted To Claude Code, Y Combinator's Lightcone podcast with Calvin French-Owen. The interview this article distills: the context poisoning mechanism, the canary trick, the 50 percent clear threshold, sub-agent delegation versus periodic compaction, and the prompt injection story from building Codex.
Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma, July 2025, by Kelly Hong, Anton Troynikov, and Jeff Huber. The research that formalized the term, and the source for the 18-model finding and the distractor result.
Advanced Context Engineering for Agents, Dex Horthy of HumanLayer on YC Root Access, for the under-40-percent utilization target in his own words, and HumanLayer's written version for the wider 40 to 60 percent range. Gergely Orosz's interview with Horthy in The Pragmatic Engineer is the supporting source for the dumb zone.
Background on Calvin French-Owen and Segment: his post Reflections on OpenAI, dated July 15 2025, for his May 2024 start and for a departure he places three weeks before that post, and his essay From Founder to CTO for the role. On Twilio's 2020 acquisition of Segment: TechCrunch on the announcement and Twilio's own press release on the close.
HumanLayer's Y Combinator company page for Dex Horthy's batch and company details.
Anthropic's sub-agent documentation and OpenAI's guide to compaction, for how each tool actually handles separate context windows and automatic compaction.