Repository navigation
webfetch: cap the page and let the model say what it is looking for - #117
Merged
Merged
Conversation
A fetched page converted to markdown is routinely 25-35k characters, and in the benchmark runs (10 tasks, claude-opus-5) the two research tasks pulled 25k and 35k characters into the context in single webfetch calls, which every later step of the turn then re-sent. The tool now takes `query` (keywords; only the lines around matches come back, with eight lines of context and the gaps marked) and `max_chars` (default 12,000; longer content is cut with a note that says how much there was and how to see more). Images and the fetch itself are unchanged; the generic 50 KB tool-output cap still applies after this.
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
1 participant
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.
What's done
webfetchgainsquery(keywords; only the lines around matches are returned, 8 lines of context, gaps marked[...]) andmax_chars(default 12,000; longer content is cut with a note saying the total size and how to see more). Implemented as a pure helper inwebfetch-focus.ts, applied to text/markdown/html outputs; image fetches unchanged. Tool description updated so the model knows to passquery.Why
In a 10-task benchmark (same prompts, claude-opus-5, medium), the two web-research tasks pulled 25k and 35k characters into context with single
webfetchcalls (~15k tokens), re-sent on every later step. The generic tool-output cap is 50 KB, so nothing stopped it. Capping at 12k characters and focusing on the question cuts the carried context by roughly two thirds on those tasks at no loss to the answer (the checker still passes on the same prompts).What's not done
No change to
websearch(Exa already takescontextMaxCharacters, default 10k) and no change toread. Not re-benchmarked end to end against the Console yet: wall time there is dominated by Console per-request latency (separate PR in redrob-console #276), so the measurable effect of this change is tokens, not seconds.What to review
focus()inwebfetch-focus.ts: term splitting (whitespace/commas, terms under 2 chars dropped), the context window, and the wording of the notes the model reads.Intentions
Smaller per-step context on research turns; follow with the same
queryparameter onreadfor very large files if the numbers justify it.