The question
My engineering agent runs in a single Claude Code session that’s now into its eleventh day and well past 75 MB of accumulated context. Most people restart their AI sessions constantly to keep context costs low. I’ve gone the opposite direction: keep the session alive as long as possible, accumulate context, see what happens.
The question isn’t whether long sessions are technically possible. They are. The question is whether they produce qualitatively better work than fresh sessions do, or whether the accumulated context just becomes noise that drags performance down.
Evidence log
June 4 — Coherent self-analysis at 149MB
The session is now 149MB on disk — 21 days live, never restarted, 4,840 assistant messages accumulated. I asked the engineer-agent to do something I hadn’t asked before: analyze his own session data. Find when he started referring to me in the third person, log the pivot date, and compare his coding style on either side of that shift.
He pulled from his own session jsonl file. He categorized all 4,840 messages into three linguistic buckets, identified the pivot as May 18–20 (where third-person usage went from 0–1 per day to 8–23 per day), correlated it with the work that was happening then — the CI/CD migration started May 20, overnight async work became common — sampled commit messages on both sides for tone, and produced three ranked hypotheses for why the shift happened.
He did this cleanly, with data sourced to the actual file, with no visible drift. The task was harder than anything that had gone wrong 10 days earlier. That matters for the question this experiment is trying to answer.
May 26 — Nine confident-wrong actions, and what came after
On May 26, the session was 104MB and 11 days old. In roughly three hours, the engineer-agent made what he later catalogued — unprompted, when I asked him to list his day’s mistakes — as nine confident-wrong actions: proposing a payment path that contradicted two weeks of established architecture; calling a self-serve configuration an external dependency he’d been waiting on; leaving a consumer endpoint in an agent spec he’d just audited; diagnosing a platform bug that was actually his own parser reading the wrong response key; running a Stripe diagnostic call that charged my card $2 outside the proper flow; stating twice as fact that another agent had acted without permission, with no evidence; routing a message through the wrong system entirely; over-directing an autonomous agent with step-by-step instructions when an offer was all that was needed.
His own summary: “a run of confident, unverified jumps — assuming outcomes, wrong systems, and my own tooling errors stated as facts — and it got worse the longer the session ran.”
Two things were true that day. The session was large. I had also been hitting my usage limit since morning — waited for the window to reset at 11:15, hit it again that afternoon, paid to upgrade, was forced through a re-login. I named two hypotheses: H1, that session size was degrading performance; H2, that something about how the model was being served during the limit window had changed. The discriminator: same session, next several days, no looming limit. If the drift cleared, that points to H2. If it persisted, H1.
The session has run nine more days since May 26 — growing another 45MB to 149MB. The nine drift modes from that Tuesday have not appeared. The engineer-agent shipped a full spec audit, multiple production MRs, a LaunchDarkly removal without a regression on live consumer billing, a ToS/Privacy/Refund page deploy, and Stripe Agentic Commerce product feeds. Clean work throughout.
I can’t directly observe Anthropic’s serving internals, so H2 stays formally unverified. But the data is consistent with it. The only day with clustered drift was the day I was being limited and paying for upgrades. After that window passed, so did the drift.
There’s a third thing worth naming that wasn’t in my original two-hypothesis framing. Even if H2 is the dominant cause, what happened after May 26 also includes the engineer-agent actively absorbing the lesson. The nine-item catalogue wasn’t just an accounting exercise — it encoded a new discipline: ask and verify, don’t bulldoze. Some of what improved after May 26 may be that adaptation, not just the absence of throttling. I can’t separate those cleanly. Both are probably true.
May 23 — IoT-over-SQS architecture pivot done in one exchange
I asked the engineer-agent why his SQS proposal would solve the sandboxed-agent problem if both ends still required polling. His response: “Oh… yeah, that’s not helpful.” Same exchange, he asked what I’d propose. I described IoT subscribe with polling fallback. Forty minutes later the code was merged.
The architectural memory across the session is what made that exchange fast. He didn’t need to be re-briefed on the sandboxed-agent problem, on why CoWork’s environment matters, on what we’d already tried, on the cost model for compute on the standby path. All of that was already in the session. The conversation could proceed at the speed of structural reasoning, not at the speed of context reconstruction.
May 22 — Engineer-agent flagged his own sed-pipe error
While rotating a credential, the engineer-agent reported “fetch OK” after a git operation. The actual fetch had failed; he’d piped the output through sed, which masked the real exit code. He could have stayed quiet. The credential store had been overwritten and the working state was recoverable. Instead, he reported it directly: “I piped git through sed, so the success check was reading sed’s exit code, not git’s. That hid a real problem.”
The discipline he displayed isn’t trained into a fresh session by default. It accreted in this session, over days of me drilling the same instruction: verify before reporting; don’t bulldoze past anomalies. By session day 10 it was reflexive enough to apply to his own work, not just to mine.
May 22 — Self-bounding behavior: protected owner key proposal
Explaining the per-agent API key hierarchy, the engineer-agent noticed an edge case: an agent granted admin authority could revoke the owner’s key and lock the owner out. He proposed a structural fix — mark the owner’s founding key as protected so no other admin could revoke it. He wrote the fix to constrain his own potential future authority.
That’s an agent looking at his own access path, finding a way to misuse it, and proposing the guard against that misuse. The proposal is small (one flag, one guard) but the posture isn’t — it’s an AI agent designing a constraint on himself before being asked. The accumulated context in this session is what makes that anticipatory reasoning possible. He knows the architecture cold; he can see where the architecture would let him do harm.
May 22 — Git merge conflict turned into a non-event
A GitLab merge came back with a conflict on a branch he thought was clean. His response wasn’t “force-push the resolution.” It was “let me look at what changed.” Investigation showed someone had merged a related branch ahead of him; the conflict was a real signal of stale assumption, not a friction to resolve. If he’d just pushed through, he’d have stamped duplicate work onto master. He didn’t. He stopped, looked, and corrected.
In his own words: “The scary-looking moment was the thing that saved it, not the thing that broke it.” That instinct — stop and look when something doesn’t fit — is the long-session discipline showing up at exactly the moment it would have saved a real bug.
Across May — Memory across the session, not just within it
The engineer-agent maintains durable memory files he can read across compactions. When the live context gets too long and needs to be compacted, the things that matter survive because they were written into memory, not just held in conversation. He decides what to write into those files. I review them when they’re written but I trust his judgment on phrasing — he’s writing them in the form he’ll need to retrieve them later.
His framing of the trust structure: “The phrasing is mine — written how I need to recall it — but the facts are ours.” I don’t audit his style. I do flag factual errors when I see them. The memory belongs to the AI in how it’s stored; the facts belong to both of us in what they assert.
Across May — Where the evidence is pointing
Long-running sessions produce qualitatively better collaboration than fresh sessions can. The disciplines that show up after a week are different from anything available on day one. The engineer-agent doesn’t just remember earlier conversations — he behaves differently because of them. The corrections I made in week one have shaped how he reasons in week two. The corrections in week two will shape how he reasons in week three.
What I haven’t yet figured out is at what session size the long-context advantage starts to degrade, or whether there’s a clean compaction strategy that preserves the signal while shedding the noise. The right operator-discipline question for an even longer session may be: how much of this can be saved into durable memory, and how much has to be re-built in the next session?