/insights facet generation hits its own 500-output-token cap on large sessions, then writes cached facets blaming the analyzed session — false 'sessions rendered unusable' findings in every report

Environment

• Claude Code v2.1.214, Linux (Raspberry Pi 5, aarch64)
• /insights run headless biweekly: echo '{"type":"user","message":{"role":"user","content":"/insights"}}' | claude -p --input-format=stream-json --output-format=stream-json --verbose --dangerously-skip-permissions
• No CLAUDE_CODE_MAX_OUTPUT_TOKENS or related env vars set anywhere

Symptom

Five consecutive biweekly /insights reports told the user that "a large share of your
sessions were rendered completely unusable because Claude's responses repeatedly exceeded
the 500 output token maximum" and advised keeping responses short / writing to files.

This is false. Grepping every session transcript under ~/.claude/projects/ (~1,000
sessions): zero real sessions contain an output-token-limit error. The only
transcripts containing "response exceeded the 500 output token maximum" are the five
/insights generation sessions themselves (25 occurrences total).

Mechanism (verified locally)

1. During facet extraction (Phase 3), per-session analysis subcalls appear to run with a

500 output-token cap (undocumented; nothing in our env sets it).

1. On some large sessions (in our corpus: 11 sessions with 1.3–5.2 MB transcripts), the

facet subcall itself exceeds that cap and errors.

1. A fallback facet is then written that misattributes the failure to the analyzed

session, e.g.:
> "underlying_goal": "Unclear from transcript - session content was not captured due
> to API output token errors" ... "brief_summary": "Session content could not be
> analyzed because the transcript only contains API output token limit errors with
> no visible user requests or Claude responses."
The referenced transcript is a normal 5 MB working session with zero errors.

1. The report generator aggregates these facets in good faith → a top "Where Things Go

Wrong" finding that the user's sessions are burning, repeated identically in every
report because the bug is structural. Users may adopt unnecessary workflow rules
based on this false diagnostic (we did).

Notes

• Failure is flaky, not strictly size-based: sessions up to 171 MB produced clean facets;

the 11 failures were 1.3–5.2 MB. Deleting the poisoned facets and re-running /insights
regenerated clean ones where the session still fell in the analysis window.

• Facets falsely claiming token errors are cached indefinitely, so the false finding

persists across all future reports until manually deleted.

• Related but distinct: #24039 (facets not generated at all), #25569

(CLAUDE_CODE_MAX_OUTPUT_TOKENS not applying to subagents).

Suggested fixes

• Raise or make configurable the facet-subcall output cap; retry on cap-exceeded.
• On facet-generation failure, write an explicit "analysis_failed" facet (excluded from

report aggregation) rather than prose that misattributes the error to the session.

• Report section generators should not present pipeline-internal failures as user

workflow findings.