Why your AI coding agent gets worse in long sessions

The first hour with a coding agent is the good hour. It reads the code, follows your lead, ships the thing.

By hour three it's a different colleague. It re-reads a file it already read. It reintroduces the bug you watched it fix. It "helpfully" undoes a decision you made two hundred messages ago, and explains its reasoning at length instead of just running the tests.

Nothing broke. Your agent isn't tired. It's full.

Your agent has a desk, not a memory

Here's the mental model that fixes most of this: an agent doesn't remember your session, it re-reads it. Every turn, the whole thing goes back to the model: the system prompt, your rules file, every file it opened, every tool result, every wall of test output, and the entire conversation up to now. Every connected MCP server adds its tool definitions to the same pile, which is why the best MCP servers are the few that pay for their space.

That pile is the context window, and it's finite. Modern models hold a lot in it, so you rarely hit a hard wall. What you hit is dilution: the one line that actually matters, don't touch the auth module, is now a needle in three hundred kilobytes of hay, competing with a stack trace from forty minutes ago.

Capacity isn't usually the problem. Signal-to-noise is.

What "full" looks like before it's obvious

The failure is gradual, which is why people blame the model. The tells:

• It redoes work it already completed.
• It forgets a constraint you gave once, early, in passing.
• It contradicts a decision made earlier in the same session.
• It narrates and plans more than it edits.
• Responses get slower and each turn costs more, because you're re-sending everything every time.

You don't have to wait for the tells, either. Claude Code's statusline can print the exact context_window.used_percentage figure on every turn, so "full" becomes a number you glance at instead of a guess you make three mistakes too late.

If you're arguing with your agent about something it already agreed to, that's not stubbornness. That's a session that needs to end.

Compaction buys time, not memory

Most tools handle a filling window by summarising the earlier parts and carrying on. That's genuinely useful and it keeps you working, but be clear about what it is: a lossy compression of your session.

The summary keeps the shape of the work. It drops the exact error string, the reason you rejected the first approach, and the specific wording of the requirement. That's precisely the detail a coding task turns on.

Treat auto-compaction as a warning light, not a feature. When it fires, that's usually the moment to finish the current thought and start clean.

Session habits that actually work

None of this needs a bigger model. It needs hygiene.

One task, one session. Finish at a natural boundary (the tests pass, the change is committed), then start a new session for the next thing. A fresh window is the cheapest performance upgrade available.

Put durable facts in a file, not in the chat. Anything you'd have to repeat next session belongs in your project's AGENTS.md file, where it's re-read automatically and costs you nothing to remember.

Write the brief before the work. A scoped, written task keeps the session short by construction, because the agent isn't discovering the requirement through twenty rounds of clarification. That's the whole argument for spec-driven development.

Prefer verification over narration. Test output is dense, decisive context. A four-paragraph explanation of what the agent is about to do is not.

Delegate the wide searches. "Find everywhere we handle currency" is thousands of tokens of file listings if the main session does it. Hand it to a subagent and only the answer comes back.

Point, don't paste. A file path costs a few tokens. Pasting the file costs thousands, in every single turn that follows.

A fresh session isn't a lost session

The reason people let sessions run for hours is fear: everything we worked out is in here, and starting over means explaining it all again.

That fear is the actual bug. If a restart is expensive, it means your project's state lives only in a chat log, the least durable place it could be. Move it into the repo, the rules file and the task itself, and a new session becomes a five-second cost instead of a twenty-minute one. And the old session isn't even gone: if you do need it, resuming brings it back intact.

Making clean starts the default

This is the workflow SanuDesk is built around. It's a desktop app where your Claude Code and Codex sessions tile into one grid, with a Kanban board the agents take their work from.

Deploying a card opens a fresh session with that card's title, notes and acceptance criteria as the brief. The context is small, current and specific by default: there's no six-hour history for the real instruction to get lost in. When the agent stops, the card moves to review with a what-changed note, and your follow-up lands back on the card rather than in a scrollback nobody will read again. The thread lives on the board; the window stays clean.

It's also what makes running several agents at once survivable: each one has its own tight context instead of one giant session trying to hold every task at the same time. Loops handle the recurring jobs on a schedule, each run journaled so the tenth is better than the first. It drives the agent accounts you already pay for, and the free tier doesn't need one of ours.

Try it on the next task

Next time you catch your agent repeating itself, don't argue with it. Note what it needs to know, put that in your rules file, and open a new session.

The difference is immediate, and slightly annoying, because you'll realise how many of yesterday's "the model is getting dumber" moments were just a desk that needed clearing.

Download SanuDesk free and point a workspace at your repo, or see how the grid, the board and Loops fit together on the features page.