AI Search Nerd Alert: Fable 5.2's Leaked Search Modes and Partial Page Reads
Pliny's unofficial Fable 5.2 prompt describes standard and extended search plus partial page reads. Compare the September Opus core and the evidence limits.
A price at the end of a long page is useful only if the system answering the question reaches it. Pliny's leaked Fable 5.2 web-app prompt gives SEO teams a reason to examine that assumption. Its WebFetch definition includes an offset for continuing through a long page, while WebSearch has a separate choice about how much effort to spend finding information.
I compared the unofficial Fable 5.2 web-app text in Pliny's CL4R1T4S repository with the official Opus 5.5 app core prompt dated September 22, 2026. The useful SEO question is whether a current fact and the conditions attached to it survive retrieval. A leaked instruction can suggest a check, but it cannot establish the result of that check.
TLDR. The leaked text defines standard and extended search, supports reading long pages in parts with WebFetch offset, and instructs proactive search when facts may have changed. Places queries retain the user's qualifiers, and subagents require an explicit request. This snapshot did not substantiate IP-based location or a mandatory partial-read disclosure rule. No chunk size or completed test result is established here.
The September comparison boundary
The official September Opus core prompt describes giving the latest pre-cutoff information with a caveat and suggesting search for newer facts. The leaked Fable text instead instructs searching without asking permission when search is available and information may have changed. It singles out current office-holders and binary events, including deaths or elections. Present-tense questions about whether something exists also get that treatment.
This comparison concerns the Claude consumer app. It does not import details from the separate Claude Code leak. A core document from September supplies a baseline for the written cutoff guidance, without establishing which tool definitions every September app session had.
The official Fable core prompt dated November 9 is a separate, shorter public document. It retains caveated cutoff guidance and does not authenticate the fuller tool sections attributed to Pliny. No Anthropic confirmation of the leak is established by the sources used here. Calling every tool detail a confirmed new release would exceed this comparison.
Standard and extended WebSearch
WebSearch requires mode alongside the query. The leaked definition describes standard as quick and cheap, suited to simple reference lookups. Extended is more thorough and fresh, at several times the cost and latency. The text supplies no exact price, numerical multiplier, or measured waiting time.
| Situation in the leaked instructions | Search route |
|---|---|
| Simple reference lookup | Standard by default |
| Standard results are thin, off-topic, or possibly stale | Escalate to extended |
| Niche facts or very recent events | Extended from the start |
| Prices, availability, or research with several steps | Extended from the start |
When several searches are planned, the appended guidance says to send them in the same turn. For political and other high-stakes questions, the leak calls for at least one search before answering. Competing candidates or positions require separate searches for adequate coverage.
For a publisher, the implication is to maintain information that can answer the current question. A timestamp or schema property is not a demonstrated trigger for extended search. The Claude SEO task guide provides related ways to define the job and give it the evidence it needs.
WebFetch offset and page segments
WebFetch converts a page to Markdown and uses a small fast model to process it against the supplied prompt. Its optional offset specifies a starting character position for reading further through a long page. That definition supports partial page retrieval, without saying how much text fits in one part.
The tool also restricts fetching to URLs supplied in the conversation or returned by earlier search or fetch calls. A recalled URL, or one constructed by editing a known path, may require approval or be rejected. Finding a resource and reading it remain distinct operations, as the Claude search walkthrough helps illustrate.
A citation alone cannot establish how much of the linked page was considered. The explicit instruction to disclose an unfinished partial read was not found in this snapshot. It would be an additional claim, beyond the existence of offset, to say that the leak guarantees such a disclosure.
For long content, place key facts where a reader can locate them quickly and keep their conditions nearby. A retrieved price without its market or billing period can still produce an incomplete answer. This is a content recommendation, with no measured citation improvement behind it.
Infographic: search effort and page coverage
A proposed long-page retrieval test
On a long page, I would keep the question fixed and put the relevant fact in different sections of controlled copies. I would save each page with its answer, then check which facts Claude recovered. That would examine visible retrieval behavior without claiming to measure an internal chunk size.
For the offset check, I would first establish whether actual tool calls and continuation positions are visible. If they are available, I would record them beside the page and answer. If they are hidden, the conclusion would stay limited to observable answer behavior. We'll test it 🤓. No results from that test are available yet.
An answer containing a fact from later on a page would be an observation under the conditions of that run. It would not, by itself, identify the internal path taken to obtain the fact. The proposed test needs that distinction before anyone reports a page-reading limit.
Local qualifiers and places-query guidance
The places-search description recommends a query for a named place, 2 queries for focused discovery, and 2 to 4 for broad or multipart requests. Every query should preserve the user's qualifiers, including neighborhood and budget. These are recommendations for choosing query counts, rather than a universal hard budget.
For a local comparison, I would keep the neighborhood and budget unchanged while checking the returned businesses against the request. A recommendation outside the area would need an explanation rather than a wider query that silently drops the constraint.
The approximate_location tool and the proposed last-message IP mechanism were not found in the retrieved web-app snapshot. That leaves the near-me-from-IP conclusion unverified here. Local-query guidance can be discussed on its own without supplying the missing mechanism from Claude Code.
Subagents and the publisher's next decision
The Agent description reserves subagents for explicit user requests. Asking for thoroughness, multiple angles, or several parts does not count. Its explanation is that a new agent starts without the context already available and takes the more expensive path on that plan.
For an SEO team, the practical next step is a check against an actual page and a defined question. Keep prices and availability current, with the qualifications that make them usable. Treat the proposed retrieval test as upcoming work, and retain the difference between written instructions and observed behavior when reviewing an AI SEO audit.
The SEOFrancisco guide and prompt pack for Claude can help prepare that task. A site rewrite should follow evidence about the page and its readers, rather than an assumed chunk size from an unofficial prompt.
FAQ
Is the leaked Fable 5.2 prompt official?
It is an unofficial text attributed to Pliny's CL4R1T4S repository. The separate November 9 official core prompt does not authenticate its tool definitions.
What is the difference between standard and extended search?
The leaked text describes standard as quick and cheap, and extended as more thorough and fresh at higher cost and latency. It recommends extended for niche facts, recent events, prices, availability, and research with several steps.
How much of a page fits in a WebFetch part?
The retrieved text does not specify a chunk size. Offset allows continued reading, but no measured page-reading limit or completed test result is established here.
Does this snapshot confirm IP-based local search?
No. The approximate_location tool and last-message IP mechanism were not found in the retrieved web-app snapshot. The places-query guidance is supported separately.
About the author
Francisco Leon de Vivero writes about SEO and AI search at SEOFrancisco. Explore AI SEO services for work on page evidence and visibility measurement.