Judge a long page before spending tokens on it

An agent asked to look over a set of pages tends to do the obvious thing: read all of them. That works until one of them is a 40,000-word reference page, at which point the context window fills up with one document and the actual question goes unanswered.

The reads changed in 1.7.4 to make a better move available. Every post and page read now reports a content_length field, and it is there whether or not you asked for the content. So an agent can find out how big something is before it decides to swallow it. This prompt makes it do that deliberately, and it changes nothing on the site.

I want you to look over [these six pages] but I do not want you reading all of
them blind. Read only, change nothing.

First pass, sizes only. Read each item with include_content set to false. You
will still get the title, status, dates, excerpt, terms, and a content_length
field telling you how big the body is. Do not fetch any content yet.

Show me that first pass as a table: title, status, and content_length, biggest
first. If anything comes back with a length of 0, flag it, because that means
either a password-protected item or an empty one, and those are different
problems.

Now decide, out loud, which of these are actually worth reading in full for
[the question I asked]. Say why for each one, using the excerpt and the size.
Then fetch only those, with the content included this time.

Finish by telling me exactly what you read, what you skipped, and what you
might have missed by skipping it.

Why this is safe to run

Both abilities are reads, and switching the content off makes them smaller reads, not different ones. Nothing here can edit a post, change a status, or touch a revision.

The mechanism is worth understanding, because it is what makes the prompt work rather than just sound careful. Before 1.7.4, asking about a post meant getting the post: the body came back whether you needed it or not, so the only way to find out that a page was enormous was to already have it in your context. From 1.7.4 the read takes an include_content input, defaulting to true so nothing changed for anyone who was not asking, and content_length is always returned regardless. Set include_content to false and you get everything except the body, plus the real size of the body you did not fetch.

That turns a survey into a two-pass job. The first pass costs you a handful of numbers and metadata for the whole set. The second pass costs you the content of only the items the first pass justified. We are not going to put a percentage on that, because the saving depends entirely on your pages and your question, and an invented figure would be worth less than the mechanism. What we can say plainly is what the field does: it lets the agent see the size before it pays for the contents.

Two honest caveats. Content length is a byte count, so it ranks items against each other well and predicts an exact token cost badly. And a zero is ambiguous by design: a password-protected item reports 0 because its content is not returned to the reader at all, which reads identically to a genuinely empty draft. Ask the agent to flag zeros rather than quietly treat them as empty.

Already connected? Skip the paste. Ask your agent for the “judge a long page before spending tokens on it” recipe, or just tell it to check the sizes before it reads anything, and it runs the same two-pass survey against your own content.