--- title: "Hygiene score and findings" description: "The Finding, Clean, and Not-assessed states behind every check, and how they roll up into a session's pass rate and burn estimate." url: "https://antiburn.ai/docs/concepts/hygiene-score-and-findings/" --- ## Three honest states, not two Every check antiburn runs against a session lands in one of three states: - **Finding** - the check found the pattern it looks for. - **Clean** - the check ran, and didn't find it. - **Not assessed** - antiburn can't say either way for this session, usually because the agent's logs don't record what the check needs, or because only partial evidence was available. "Not assessed" is deliberately its own state rather than being folded into "clean." A missing log field could be hiding the exact pattern the check looks for, so antiburn only calls a session clean when it has complete enough evidence to back that up. Partial evidence is enough to prove a finding - an observed problem is real regardless of what else is missing - but never enough to prove the opposite. ## The session checks Every analyzed session is run against six checks: - [Session overdepth](/docs/findings/session-overdepth/) - [Model overthinking](/docs/findings/model-overthinking/) - [Overpowered subagents](/docs/findings/overpowered-subagents/) - [Old model usage](/docs/findings/old-model-usage/) - [Fast mode overuse](/docs/findings/fast-mode-overuse/) - [Excess cache rehydration](/docs/findings/excess-cache-rehydration/) A session's detail view shows each check's verdict, and a count like "5/6 checks passed" summarizing the assessed ones. These are fixed, compiled-in rules - there's no setting to tune a threshold, only guidance on what to change in your own workflow when a check fails. ## The pass rate Across the sessions in your activity window, antiburn also shows an aggregate figure: the share of analyzed sessions that pass every check that could be assessed for them, plus the single most common failure among the ones that don't. You'll see this on the onboarding Ready screen once your first scan finishes, and it's the fastest way to tell whether your day-to-day agent use is generally clean or generally burning tokens somewhere specific. ## The burn-percentage estimate Where a session has one or more findings, antiburn also estimates the share of that session's token use associated with its failed checks, as a single combined figure rather than one number per check - so a session that fails on both overdepth and cache rehydration doesn't have the same wasted tokens counted twice just because two checks flagged them. ## Beyond per-session checks Two more things sit outside these six per-session checks, at the level of your whole session history rather than one session at a time: - **Underused capabilities** - [unused MCP servers](/docs/findings/unused-mcp-servers/), [unused built-in tools](/docs/findings/unused-built-in-tools/), and [unused skills](/docs/findings/unused-skills/) all look at what's loaded into a session's context but never actually used. - **Quota pressure** - a separate section built entirely from moments your transcripts recorded actually hitting a provider's limit, independent of the six checks above. ## Which agents these apply to Not every check works for every agent - a check needs specific evidence in an agent's logs to run at all, which is why "not assessed" exists. See [Supported coding agents](/docs/agents/supported-agents/) for what each agent's logs give antiburn to work with.
Hygiene score and findings
The Finding, Clean, and Not-assessed states behind every check, and how they roll up into a session's pass rate and burn estimate.
Three honest states, not two
Every check antiburn runs against a session lands in one of three states:
- Finding - the check found the pattern it looks for.
- Clean - the check ran, and didn’t find it.
- Not assessed - antiburn can’t say either way for this session, usually because the agent’s logs don’t record what the check needs, or because only partial evidence was available.
“Not assessed” is deliberately its own state rather than being folded into “clean.” A missing log field could be hiding the exact pattern the check looks for, so antiburn only calls a session clean when it has complete enough evidence to back that up. Partial evidence is enough to prove a finding - an observed problem is real regardless of what else is missing - but never enough to prove the opposite.
The session checks
Every analyzed session is run against six checks:
- Session overdepth
- Model overthinking
- Overpowered subagents
- Old model usage
- Fast mode overuse
- Excess cache rehydration
A session’s detail view shows each check’s verdict, and a count like “5/6 checks passed” summarizing the assessed ones. These are fixed, compiled-in rules - there’s no setting to tune a threshold, only guidance on what to change in your own workflow when a check fails.
The pass rate
Across the sessions in your activity window, antiburn also shows an aggregate figure: the share of analyzed sessions that pass every check that could be assessed for them, plus the single most common failure among the ones that don’t. You’ll see this on the onboarding Ready screen once your first scan finishes, and it’s the fastest way to tell whether your day-to-day agent use is generally clean or generally burning tokens somewhere specific.
The burn-percentage estimate
Where a session has one or more findings, antiburn also estimates the share of that session’s token use associated with its failed checks, as a single combined figure rather than one number per check - so a session that fails on both overdepth and cache rehydration doesn’t have the same wasted tokens counted twice just because two checks flagged them.
Beyond per-session checks
Two more things sit outside these six per-session checks, at the level of your whole session history rather than one session at a time:
- Underused capabilities - unused MCP servers, unused built-in tools, and unused skills all look at what’s loaded into a session’s context but never actually used.
- Quota pressure - a separate section built entirely from moments your transcripts recorded actually hitting a provider’s limit, independent of the six checks above.
Which agents these apply to
Not every check works for every agent - a check needs specific evidence in an agent’s logs to run at all, which is why “not assessed” exists. See Supported coding agents for what each agent’s logs give antiburn to work with.