---
title: "Session overdepth"
description: "antiburn flags sessions whose deepest request carries more context than its reviewed depth cap."
url: "https://antiburn.ai/docs/findings/session-overdepth/"
---
## What it detects

Every request in a coding session carries the full context the agent sends to the model - prior turns, file contents, tool output. antiburn tracks the deepest single request in each session and flags it once that request's context exceeds antiburn's reviewed cap of 400,000 tokens. One over-cap request anywhere in the session is enough for a finding; the rest of the session doesn't need to be shallow too.

This is a fixed rule antiburn applies, not a setting you tune.

## Why it burns tokens

Once a request carries hundreds of thousands of tokens of context, every subsequent turn resends that entire history as cache reads. A session that's already deep costs more per message than a fresh one, and it keeps costing more until something - compaction, a new session - resets the depth.

## How to fix it

Compact well before you hit the cap. antiburn's own guidance is to start using compaction once a session passes roughly 200k tokens, rather than waiting for it to become a problem. If your agent supports subagents, delegating exploratory or read-heavy work to a subagent keeps that work out of the parent's context entirely, so the parent's depth stays lower.

## When it shows "not assessed"

antiburn can't assess depth for a session whose agent never reports per-request context size at all - this happens for agents antiburn doesn't have a dedicated adapter for, and for the handful of agents whose logs simply don't carry a context-size field.

For agents that do report context size, a session can still come back "not assessed" rather than clean when antiburn only has partial coverage of its records - a truncated log or a malformed record, for example. Partial evidence is enough to prove a finding (an observed over-cap request is real regardless of what else is missing), but it's never enough to prove the opposite: a missing record could be hiding an even deeper request antiburn never saw. Depth also needs complete model-identity and timing data before a session reads clean, not just complete depth records.

See [hygiene score and findings](/docs/concepts/hygiene-score-and-findings/) for how this fits into your overall score.