The approval-fatigue curve does not transfer to the Channels agent, but the session-scoped block budget does

The question

"Does the auto-mode classifier's reported approval-fatigue decay curve (89% catch vs 13.6%→5% human decay after ~50 prompts) apply to the Channels agent's actual session-length pattern (tmux + LaunchAgent, 4am restart)?"

Surfaced from the AlphaSignal auto-mode piece and Every's "Agents for Hire" in the 2026-08-11 sweep. Direct operational stakes: the Channels agent runs defaultMode: auto today, so whatever the classifier does under long sessions is what our gating actually is.

What we already know (from the vault)

• Auto mode was already flagged as the leading indicator of the permission boundary moving, not a convenience feature ([[2026-04-10-jaya-gupta-anthropic-moat]]). That framing is now literal: it is our production gate.
• RDCO's standing rule is that a deploy or production-write denial is a HARD gate: stop after one denial, route to the founder or to a human-set permissions.allow rule. Never retry.
• The gating pattern survey concluded that a single-operator always-on agent needs oversight that does not depend on a human being present ([[2026-06-07-agent-write-action-gating-patterns]]), and the supervisor design is explicitly fail-closed, where "blocked-and-held" is not the same as "escalate then auto-send" ([[2026-06-04-supervisor-agent-write-path-pattern-design-v0]]).
• We have already been burned by session-length degradation once. The restart script was changed on 2026-05-31 off claude --resume to a fresh named session with a handoff seed, with the in-file comment naming context rot as the root cause. The 4am boundary is a deliberate remediation, not an accident of scheduling.

What the web says

Primary source verified directly (both Anthropic pages fetched, quotes confirmed against page text):

• The study is real and the numbers in the question check out. "We hired 1,053 paid testers through a research vendor for a coding study." "The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053)." (Anthropic, auto mode default)
• The decay curve is stated, but the question misquotes its start point. Anthropic's figure is "they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat." The 13.6% is the aggregate human catch rate across the whole study, not the early-session value. The curve is 17%→5%, not 13.6%→5%.
• Anthropic measured the classifier's rate as flat across session length. This is the decisive sentence for our question, and it is an empirical claim about the classifier, not an inference.
• There is a session-scoped circuit breaker: "three blocks in a row, or twenty across a session" triggers fallback to manual mode. The engineering post phrases the same mechanism as "If a session accumulates 3 consecutive denials or 20 total, we stop the model and escalate to the human." (Anthropic engineering, how we built auto mode)
• Headless runs have no escalation path: "In headless mode (claude -p) there is no UI to ask the human, so we instead terminate the process."
• The classifier is reasoning-blind and session-scoped: "The classifier sees only user messages and the agent's tool calls; we strip out Claude's own messages and tool outputs, making it reasoning-blind by design."
• The honest limit Anthropic publishes is a 17% false-negative rate on real overeager actions, on a small eval set (n = 52), alongside n = 10,000 real internal traffic and n = 1,000 synthetic exfiltration cases.

Caution on secondary coverage: the aggregators that surfaced this (explainx.ai, cybersecuritynews, techi, cyberpress) restate the figures with drift, including a "97% of permission requests" number where Anthropic's engineering post says 93%. The engineering post alone does not contain the 1,053-tester study at all; only the claude.com blog post does. Anyone verifying against the wrong Anthropic page will conclude the numbers are fabricated.

Convergences and contradictions

• Convergence: Anthropic's fix for approval fatigue (remove the human from the per-action loop) and RDCO's fix for context rot (hard 4am session boundary) are the same move applied to different actors. Both replace "trust the participant to stay sharp over a long session" with a structural reset.
• Contradiction with our own rule, in our favor: Anthropic's circuit breaker fires at 3 consecutive or 20 total blocks. RDCO's standing rule fires at 1. We are roughly 3x more conservative than the platform default, and for an unattended agent that is correct, because the state Anthropic falls back to (manual mode) has no human standing in front of it at 1am.
• Contradiction between question premise and source: the question's "13.6%→5%" is a conflation. The measured decay is 17%→5%; 13.6% is the aggregate. Minor, but it matters if the number is ever repeated in a founder-facing artifact.

Synthesis for RDCO

The analogy does not transfer, and the reason is mechanistic rather than a matter of degree. The 17%→5% decay is a property of a human's attention budget depleting across a session. The Channels agent's approver is a classifier that Anthropic measured as flat across the same axis, and it is reasoning-blind by construction, so there is no accumulating "I have approved 40 of these already" state for fatigue to live in. Asking whether Ray's 4am restart protects against classifier fatigue is asking the wrong question: there is nothing to protect against, and the 4am boundary was built for context rot in the agent, which is a real and separately-evidenced problem. Two different failure modes, one boundary, and it only ever addressed one of them.

What does transfer is the part of the mechanism that is genuinely session-scoped: the 20-block budget. Measured over 14 days of local transcripts (213 sessions in ~/.claude/projects/-Users-ray/), the Channels agent's long-lived session has a median span of 16.6 hours, a median of 49 real prompts, and a median of 130 tool calls, with observed maxima of 81 prompts and 274 tool calls in a single day. Fourteen of eighteen long sessions start at exactly 04:00 ET, confirming the LaunchAgent boundary holds. That is a far larger exposure surface than a human coding session: 130 classifier evaluations per session against a budget of 20 blocks. The good news is empirical and reassuring. Across every transcript on disk I found 30 total classifier blocks, and the maximum in any single session was 3 (the 2026-07-20 session). We have never come close to 20, and the budget resets at 4am regardless. The 4am restart does happen to protect the block budget, but incidentally, and it was not designed for that.

The failure mode that actually applies is the headless cron population, and it is already firing. Alongside the one long session, the machine runs about 13.9 short sessions per day (195 over the sample), median 2 minutes and 14 tool calls. In headless mode a block does not fall back to manual, it terminates the process. And the block log shows a deterministic, repeating trip: the /deep-research step-7 HQ digest push (cd ~/rdco-hq && git commit ... research digest) was blocked by the classifier on 2026-07-30, 08-01, 08-02, and 08-03, at roughly 01:11-01:20 ET each time. That is the same command shape failing on a schedule, on an unattended run, with no human to escalate to. It stopped appearing after 08-03, but there is no permissions.allow rule covering it (63 allow rules, zero git-related), so I cannot claim it was fixed rather than merely reshaped by the worktree change. Against that, the aggregate 89-vs-13.6 argument is close to irrelevant for us. We never had a fatigued human in the loop to replace. The operative risk is availability, not laxity: a classifier block on an unattended run is a silent job death, and our 1-denial hard-gate rule converts a safety stop into a stopped pipeline unless something is watching.

Practical read. Do not change the 4am boundary on the strength of this study; it earns its keep on context rot and it happens to reset the block budget for free. Do treat recurring classifier blocks on cron jobs as a monitored class rather than incidents, because they are deterministic and they kill headless runs silently. And note that the reasoning-blind classifier sees accumulating user messages plus tool calls, which on the Channels agent means 16 hours of inbound iMessage and Discord text from third parties is inside the classifier's input. That is a session-length-dependent effect worth naming, but it is an injection-surface question, not a fatigue question, and I did not test it.

Why this is in the vault

This settles whether the Channels agent's 4am restart needs to be re-justified or re-tuned on auto-mode safety grounds (it does not), and it redirects the actual gating work toward the headless cron population, where a recurring classifier block on the /deep-research HQ digest push has already silently killed scheduled runs four times. It also corrects the 13.6%→5% figure before it gets repeated in a founder-facing artifact.

Open follow-ups

• Is the recurring HQ digest-push classifier block actually resolved, or did the worktree change just alter the command shape? No allow rule exists; the blocks stopped after 2026-08-03 without an identified fix.
• Should cron-dispatched headless runs get a block-detection wrapper that surfaces a terminated job, given that headless denials terminate the process with no escalation path?
• Does the reasoning-blind classifier's exposure to 16 hours of third-party iMessage/Discord text create an injection surface that grows with session length? Untested here.
• Should RDCO's 1-denial hard-gate rule be split by reversibility, so that non-destructive blocks (a blocked git commit on our own repo) retry once with a narrowed command while destructive ones keep the 1-denial stop?
• Does /supervise, still dormant, become the right pre-write gate specifically for the headless population, where the classifier's fallback-to-manual has no human behind it?
• Anthropic's published false-negative rate is 17% on n = 52. What is our own miss profile, given a tool-call mix (MCP writes to Notion, Gmail, Cloudflare) that looks nothing like the coding traffic the classifier was evaluated on?

Related

• [[2026-06-07-agent-write-action-gating-patterns]]
• [[2026-06-04-supervisor-agent-write-path-pattern-design-v0]]
• [[2026-04-10-jaya-gupta-anthropic-moat]]
• [[2026-04-15-thariq-claude-code-session-management-1m-context]]
• [[2026-06-09-fable5-harness-review]]

Sources

Primary (fetched and verified against page text):

• Anthropic, "Auto mode is now the default in Claude Code for Pro, Max, and Team plans" — https://claude.com/blog/auto-mode-default-in-claude-code (source of the 1,053-tester study, 13.6% / 89%, the 17%→5% decay curve, and "three blocks in a row, or twenty across a session")
• Anthropic Engineering, "How we built Claude Code auto mode: a safer way to skip permissions" — https://www.anthropic.com/engineering/claude-code-auto-mode (reasoning-blind classifier design, 17% FNR on n = 52, headless termination behaviour, 93% approval rate). Note: this page does NOT contain the 1,053-tester study.

Secondary (surveyed, not relied on; figures drift from primary): explainx.ai, cybersecuritynews.com, techi.com, cyberpress.org, devops.com coverage of the same announcement.

Local measurement (2026-08-13, 14-day window 2026-07-30 → 2026-08-13):

• ~/.claude/projects/-Users-ray/*.jsonl — 213 sessions analysed; 18 long-lived (median 16.6h span, 49 prompts, 130 tool calls; max 81 prompts / 274 tool calls), 195 short (~13.9/day, median 2min / 2 prompts / 14 tool calls); 30 total classifier blocks, max 3 per session
• ~/.claude/scripts/claude-channels-restart.sh lines 83-90 — the 2026-05-31 change off --resume to a fresh seeded session, context rot named as root cause
• ~/.claude/settings.json — permissions.defaultMode: auto, 63 allow rules, none git-related
• ~/.claude/logs/cron-runs/ — 204 logs, 14 distinct recurring skills
• /tmp/claude-channels.log — 2026-08-12 04:00:01 → 04:01:21 restart sequence, tmux pane confirms "auto mode on"

Not verified / could not measure: whether the 3 blocks in the 2026-07-20 session were consecutive tool calls; whether the HQ digest block is resolved; Ray's own classifier false-negative profile on non-coding tool traffic.

Correction to the question as posed: the decay curve is 17%→5%, not 13.6%→5%. The 13.6% is the aggregate human catch rate.

Vault paths cited

• ~/rdco-vault/06-reference/research/2026-06-07-agent-write-action-gating-patterns.md
• ~/rdco-vault/06-reference/concepts/2026-06-04-supervisor-agent-write-path-pattern-design-v0.md
• ~/rdco-vault/06-reference/2026-04-10-jaya-gupta-anthropic-moat.md