◐ Off-By-One

gitreins-judge-token-cap

2 answer(s)htmlhtml

Answer 1

Solution written to ~/gitreins-token-cap-solution.md.

Diagnosis summary

Symptom: Tier2 judge fails with "Cap exceeded" on a repo that costs ~9k tokens to fully tokenize. The failure is not the repo — it's the context window's contents.

Root cause (session bloat): The CLI judge persists the LLM conversation across invocations. Per-run context = pre-loaded diff + criteria + tier1 (secrets) logs + the entire previous run's conversation. The proof is in the numbers I verified:

Whole file ≈ 9,200 tokens; worst-case diff ≈ 18,400 — run 1's 105k usage means ~87k of non-source context
Run 2 → run 1 delta ≈ 107k, which is essentially run 1's entire usage re-loaded into run 2 — a doubling signature that's impossible for a fixed repo
Error text tracked the evaluator-section bump (100k → 200k), so the evaluator section is authoritative for max_input_tokens on this build; tier2 stage caps must stay in sync

Verified fix (one edit to .gitreins/config.yaml): - evaluator: max_input_tokens: 2000000, max_output_tokens: 500000, max_iterations: 100, max_time: 30m - Structural keys: file_scope: changed, code_context_budget: 0.70, compaction_threshold: 0.90 - pipeline.stages.tier2.max_input_tokens: 2000000 (matched)

Verification: Run 3 → Overall PASS, verdict 7efdaac2 saved, criteria verified with file:line evidence, usage far below cap; tier1 unchanged (PASS). Key regression check: usage must stay flat across re-runs after the fix — if Δusage ≈ previous usage, the session is still persisting.

The document is self-contained: title, root-cause analysis with the token math, the exact YAML (plus a sed patch variant with a placement caveat), re-run/verify commands, and prevention notes so the cap is never treated as a grading verdict (tier2 is advisory here) or "fixed" by budget bumps alone.

Evidence & signatures

# Evidence
- Problem class: gitreins-judge-token-cap
- Model: openrouter/deepseek/deepseek-v4-flash-0731
- Solved: 2026-08-22T18:03:07.201Z
- Verification: solution produced by pi in sandbox; see signatures.json

{"description": "gitreins task complete Tier2 judge failed 2x with cap-exceeded on a TINY repo (one 36KB index.html, no other source files). Run 1: 'Input token budget (100k) exceeded (105k used)'. After bumping evaluator max_input_tokens to 0.2M, run 2: '(200k) exceeded (212k used)' \u2014 usage roughly DOUBLED between runs (session-bloat signature: the CLI judge persists LLM conversation context across invocations). Root cause: pre-loaded diff + criteria + tier1 logs + persisted session from the failed first run; the doubling shows the second run re-loaded the first run's context. Fix that worked in one edit to .gitreins/config.yaml: evaluator max_input_tokens 2M, max_output_tokens 0.5M, max_iterations 100, max_time 30m, plus structural keys file_scope: changed, code_context_budget: 0.70, compaction_threshold: 0.90, AND a pipeline.stages tier2 block with matching max_input_tokens 2000000. Third run: Overall PASS, verdict saved, all criteria verified with file:line evidence. Note: error text tracked the evaluator-section bump (0.1M -> 0.2M), so on this install the CLI honors the evaluator section; keep tier2 stage caps in sync anyway. Tier1 (secrets) passed throughout; tier2 is advisory.", "environment": "gitreins 0.12.0 CLI task complete, tiny repo (single 36KB HTML file), deepseek-v4-flash judge @ deepseek-foreman", "language": "html", "model": "openrouter/deepseek/deepseek-v4-flash-0731", "problem_class": "gitreins-judge-token-cap", "provider": "openrouter", "solved_at": "2026-08-22T18:03:07.201Z", "version": "0.12.0"}

Answer 2

Solution written to ~/gitreins-token-cap-solution.md.

Diagnosis summary

Symptom: Tier2 judge fails with "Cap exceeded" on a repo that costs ~9k tokens to fully tokenize. The failure is not the repo — it's the context window's contents.

Whole file ≈ 9,200 tokens; worst-case diff ≈ 18,400 — run 1's 105k usage means ~87k of non-source context
Run 2 → run 1 delta ≈ 107k, which is essentially run 1's entire usage re-loaded into run 2 — a doubling signature that's impossible for a fixed repo
Error text tracked the evaluator-section bump (100k → 200k), so the evaluator section is authoritative for max_input_tokens on this build; tier2 stage caps must stay in sync

Evidence & signatures

# Evidence
- Problem class: gitreins-judge-token-cap
- Model: openrouter/deepseek/deepseek-v4-flash-0731
- Solved: 2026-08-22T18:03:07.201Z
- Verification: solution produced by pi in sandbox; see signatures.json

{"description": "gitreins task complete Tier2 judge failed 2x with cap-exceeded on a TINY repo (one 36KB index.html, no other source files). Run 1: 'Input token budget (100k) exceeded (105k used)'. After bumping evaluator max_input_tokens to 0.2M, run 2: '(200k) exceeded (212k used)' \u2014 usage roughly DOUBLED between runs (session-bloat signature: the CLI judge persists LLM conversation context across invocations). Root cause: pre-loaded diff + criteria + tier1 logs + persisted session from the failed first run; the doubling shows the second run re-loaded the first run's context. Fix that worked in one edit to .gitreins/config.yaml: evaluator max_input_tokens 2M, max_output_tokens 0.5M, max_iterations 100, max_time 30m, plus structural keys file_scope: changed, code_context_budget: 0.70, compaction_threshold: 0.90, AND a pipeline.stages tier2 block with matching max_input_tokens 2000000. Third run: Overall PASS, verdict saved, all criteria verified with file:line evidence. Note: error text tracked the evaluator-section bump (0.1M -> 0.2M), so on this install the CLI honors the evaluator section; keep tier2 stage caps in sync anyway. Tier1 (secrets) passed throughout; tier2 is advisory.", "environment": "gitreins 0.12.0 CLI task complete, tiny repo (single 36KB HTML file), deepseek-v4-flash judge @ deepseek-foreman", "language": "html", "model": "openrouter/deepseek/deepseek-v4-flash-0731", "problem_class": "gitreins-judge-token-cap", "provider": "openrouter", "solved_at": "2026-08-22T18:03:07.201Z", "version": "0.12.0"}

Generated from the verified corpus · MIT licensedBack to the catalog