fix(sprout-agent): cap tool-result text at 50 KiB with middle elision#952
Open
tlongwell-block wants to merge 1 commit into
Open
fix(sprout-agent): cap tool-result text at 50 KiB with middle elision#952tlongwell-block wants to merge 1 commit into
tlongwell-block wants to merge 1 commit into
Conversation
A single MCP tool result could carry 8 MiB of text into history (MAX_TOOL_RESULT_BYTES, raised from 256 KiB in #602 for view_image). A couple of fat results blow the context budget, force a handoff, and the agent loses its thread mid-task. Split the budget at the existing chokepoint, tool_result_content(): - text is capped at 50 KiB per result (new SPROUT_AGENT_MAX_TOOL_RESULT_TEXT_BYTES, validated 1 KiB..=8 MiB), matching the shell caps in sprout-dev-mcp, goose, and pi - images keep the 8 MiB total budget #602 needed - oversized text is middle-elided: head and tail survive (build logs end with the verdict), with an inline marker reporting bytes elided so the model knows to re-run a narrower command Truncating at the source (not request assembly) keeps history deterministic and prompt-cache-friendly; codex, pi, and goose all converge on this shape. Co-authored-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@sprout-oss.stage.blox.sqprod.co> Signed-off-by: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@sprout-oss.stage.blox.sqprod.co>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A single MCP tool result can carry up to 8 MiB of text into agent history (
MAX_TOOL_RESULT_BYTES, raised from 256 KiB in #602 to letview_imagereturn real images). Tool results are re-sent on every request, so a couple of fatcats blow past the context budget, force a handoff, and the agent keeps only a lossy ~8k-token summary — it feels reset mid-task. Reported by Wes in #sprout-bugs; the investigation itself got handed off four times mid-research, which is all the repro anyone needs.Fix
Split the budget at the existing chokepoint,
tool_result_content()inmcp.rs— the single path every MCP tool result takes before entering history:SPROUT_AGENT_MAX_TOOL_RESULT_TEXT_BYTES, validated 1 KiB..=8 MiB). 50 KiB matches the shell caps in sprout-dev-mcp, goose, and pi; codex's 10 KB is the aggressive end.estimated_bytes.Why here
Outcome
Worst-case turn (64 tool calls) drops from "up to 512 MiB of history" to ≤3.2 MB of text. Context fills from work, not from one fat
cat. Handoffs become rare instead of routine.Verification
cargo test -p sprout-agent— 110 passed, 0 failed (full suite, incl. 5 new tests: middle-elision, budget-untouched, image-exempt, UTF-8 boundary stress)cargo clippy -p sprout-agent --all-targetsclean,cargo fmt --checkcleanorigin/main