Skip to content

feat: 10KB hard cap on tool output entering context - #155

Merged
samsja merged 1 commit into
mainfrom
feat/tool-output-cap
Aug 28, 2026
Merged

feat: 10KB hard cap on tool output entering context#155
samsja merged 1 commit into
mainfrom
feat/tool-output-cap

Conversation

@samsja

@samsja samsja commented Aug 28, 2026

Copy link
Copy Markdown
Member

Summary

Hard-caps any single tool result entering the conversation at 10KB, middle-out (keep head+tail), with a warning header naming the original size and line count:

Warning: truncated output (original token count: 12500)
Total output lines: 10001

<first 5KB>
[... 40000 bytes truncated ...]
<last 5KB>

Applies at the engine tool-result boundary — so it covers all tools (bash, edit, and ipython cell output) uniformly.

Scope: context only — tools yes, skills no

  • The session log keeps the full output (audit trail unchanged).
  • Skill return values inside the kernel stay uncapped: out = await bash(...) holds the complete string for in-cell filtering; only what the cell prints (the tool result) is subject to the cap. Capture-then-filter workflows keep full fidelity — the cap only protects the context window.

Compatibility

The function is byte-compatible with the truncation in verifiers#2454 (bash harness) and the copy bundled inside #147 (auto-compaction) — extracted standalone here so the cap can ship independently; #147 can relocate/dedupe it when it lands.

Motivation from eval traces: unclipped tool results produced single-turn context blowups (observed up to ~690k tokens from one cat on a large file), which no compaction threshold can save you from after the fact.

Tests: truncation unit test added; 139 passed (6 pre-existing test_acp.py env failures, same as clean main); ruff clean.


Note

Medium Risk
Changes what every tool returns to the model mid-run; large outputs lose middle content in context (by design), though logs retain full fidelity.

Overview
Adds a 10KB UTF-8 hard cap on each tool result before it is appended to the conversation. Oversized output is head+tail truncated with a warning that includes estimated original token count and line count.

Truncation runs in RLMEngine when building the tool message (truncate_tool_output); session.log_tool_result still records the full string, so audit trails and in-kernel skill return values are unchanged—only what the model sees in context is limited.

A unit test in test_tools.py checks passthrough for small output and warning/size behavior for large output.

Reviewed by Cursor Bugbot for commit 32bb729. Bugbot is set up for automated code reviews on this repo. Configure here.

Any single tool result (bash, edit, ipython cell output) is truncated
middle-out at 10KB before joining the conversation, with a warning naming the
original size and line count — Codex's output policy, byte-compatible with
the bash-harness truncation in verifiers#2454 and the version bundled inside
nano-rlm#147.

Scope: only what enters CONTEXT is capped. The session log keeps the full
output, and skill return values inside the kernel (e.g. `out = await
bash(...)`) stay uncapped — only the printed cell output is subject to the
cap, so capture-then-filter workflows keep full fidelity.
@samsja
samsja marked this pull request as ready for review August 28, 2026 05:20
@samsja
samsja merged commit b548016 into main Aug 28, 2026
8 checks passed
@samsja
samsja deleted the feat/tool-output-cap branch August 28, 2026 05:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant