Repository navigation
Improve handling of truncated page content in Ask mode - #3331
Merged
Merged
Conversation
… page
From QA case G7 ("Summarize this page." in Ask on a very long article): in
both attempts the model answered at once with done(), with no read_page,
tree read or scroll. The page context it had was the start of the article,
cut off, and the summary was presented as covering the whole page.
Two things let that through. The page observation attached before the first
decision reads the page with maxChars 12000 and then passes it through the
8000-character tool-result limit, whose last resort chops the serialized
JSON with "[...result truncated]": the result is no longer JSON and says
nothing about where the page goes on. And nothing checks an Ask answer
against how much of the page was read; the whole-read check exists only for
a requested whole conversation thread.
- A page-content result that is too large (a tree read, a gated article's
text, a page observation) is now cut inside pageContent, stays JSON, ends
with "[...page content truncated]" and its notice names
read_page({"includeChrome":false}) for the whole page. The tree's own
continuation, which would skip the cut text, is dropped.
- page-read-coverage.js (shared by both builds) records per run whether the
page content the model was shown was cut off, and whether read_page
windows or full-depth tree slices later joined up to the end of the page.
- Before an Ask answer is accepted (done, or a plain final in either loop),
a new fixed-choice question, page_read_scope, reads the request once per
run when the rest of the page is unread; the Summarize this page action is
the whole page by construction. A sure whole_page answer is sent back once
through read-coverage-incomplete with the exact call that continues the
read (the next read_page window's continuationArgs, the tree's own
continuation, or the first read_page window). An answer given again
without reading on is accepted as partial with "Only part of the page was
read, so this answer may leave out later parts of it."
- Short pages, a question about one part of a page, unsure readings, tiny
Ask turns, Act runs and conversations are not affected.
Tests: test/page-read-coverage.mjs (new, wired into the runtime-unit shard)
and a real-browser case in test/read-continuation-browser.mjs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review of the whole-page check: on a video page the page observation is cut off like any large page, so "Summarize this video." in Ask, after a complete read_youtube_transcript, was sent back to read_page once page_read_scope read the request as whole_page, and an answer given again ended as partial with "Only part of the page was read". The check counted only read_page windows and tree slices as reading a page. - A successful read of the open page's content through a reader of its own source (read_youtube_transcript, read_pdf of the tab's PDF, iframe_read of the framed documents' text, fetch_url/research_url of the page's own address) leaves that page's text coverage unchecked: those tools have their own continuation fields and read_page is the wrong next read for them. extract_data is not counted: tables and headings are parts of a page, and an article like G7's has tables. - A recommended action decides the scope by construction: Summarize this page is the whole page, an action whose first read is not of the page text (Summarize video) is a part. page_read_scope's "part" choice also names a video, recording, PDF or other file the page shows. - Selection-scoped requests are not checked against the page. - A cut subtree's notice names the same element in smaller pages instead of read_page, and the cut drops chunkEnd, which no longer matched. - Calls after a sent-back answer are skipped with the page's own reason. - The next-read hint uses read_page's largest windows (limit 6000), about a third fewer windows on a long article. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…learing the gap Two Codex review findings (P2) on this PR, both reproduced with new tests in test/page-read-coverage.mjs before the fix. A transcript read marked the open page as read from its own source whatever video it was for. read_youtube_transcript takes an explicit url, so a transcript of another video, read during a comparison or research request, cleared the gap and a whole-page answer about the still-unread open page skipped both the read-continuation guard and the caveat. The exemption now applies only when the url (when given) and the video_id the provider reports name the open page's video, as the PDF and fetch readers already check their sources. A full-depth tree read completed the page even when the walk reported depthTruncated, which accessibility-tree.js sets only when includable content below the depth cap was left out. Reaching the end of such a tree, in one result or across its slices, no longer completes the page, and its own next slice is not named as the continuation (it cannot reach the omitted content), so the note names read_page instead. Both builds share page-read-coverage.js byte for byte. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ask mode: send a whole-page answer back to read the rest of a cut-off page
|
@esokullu is attempting to deploy a commit to the esokullu's projects Team on Vercel. A member of the Team first needs to authorize it. |
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.
No description provided.