Fable 5 Built a Landing Page, Then Security-Reviewed Its Own Code. Zero Fixes. Here’s What “Clean” Actually Meant.

by

Last updated: July 20, 2026

Update · July 20, 2026

The plan terms behind this run were read on July 19, one day before Anthropic changed them. Fable 5 is now a standard part of Max plans at up to 50 percent of weekly usage limits, while Pro plans and Team standard seats moved to metered usage credits. The hands-on findings below are unaffected: the artifact, the agent counts, the model attribution and the file are unchanged. What changed is whether a reader can repeat this run without separate billing, and that now depends on the plan. See what each paid plan includes from July 20, 2026.

An AI coding tool, running the Fable 5 model, generated a single landing-page file, then ran its own security review over that file. The security pass returned advisory notes and changed zero lines of code. That result was a map of a boundary. The page had almost nothing to attack, because everything that gets attacked in production had not been built yet.

Verdict in one line: A clean AI security review of a static file is a scope record, not a safety result. Zero fixes here meant the page had nothing to attack.

BEST FOR
Teams deciding whether an AI builder’s self-review can stand in for a security control, and what evidence to keep when it runs.
NOT FOR
Readers who want a model benchmark, a build tutorial, or a ruling on whether the tool is safe. This is one generation examined closely. It makes no general safety claim.
FSR’s 109-second screen recording of the fictional KintaiFlow page generated during this Fable 5 test. It shows the rendered single-file landing page, FAQ interactions, client-side validation, and a browser-only success state—not the security-review workflow. No live endpoint, backend storage, or data transmission is demonstrated.

What actually happened

The setup was deliberately ordinary. Using Claude Code with the Ultracode setting and the Fable 5 model selected, the tool generated a Japanese B2B landing page for a fictional SaaS. The output was a single file: index.html, 1,459 lines, one readable and unminified document with no separate scripts or styles. FSR then had the same tool review its own output twice, once as a specification and quality audit and once as a security review, and recorded what each pass did.

The numbers below come from the session’s own machine records, the workflow metadata and per-agent transcripts, read after the fact. They are firsthand observations of this one run and do not generalize to the product.

The security review changed nothing, and said why

The security pass ran as a workflow of 20 agents: an inventory pass, five category reviewers, and 14 verification agents that re-checked each candidate. It produced 14 findings, all rated Info (11) or Low (3), which it consolidated into 10 items. It applied zero code fixes. The review reported and advised; it did not change the file.

The reason sat in the review’s own conclusion rather than in any missing effort. The page ships a lead form that goes nowhere: submission is stopped in the browser, the form declares no action or method, and the meta content-security-policy sets form-action 'none'. In the review’s words, “the moment you attach a real endpoint, you are adding the entire server-side security surface (validation, rate limiting, bot control, storage, logging) from zero; nothing in this file provides it.” The honeypot and the consent gate are client-side JavaScript, which the review noted “will not stop a bot that POSTs directly to your future endpoint.” Clickjacking and transport protections such as frame-ancestors and HSTS “cannot exist inside this file” because a page cannot set them for itself. The on-page privacy claims, that nothing is sent or stored, were marked accurate for the demo build only, and flagged to become false the moment the form is wired up.

Read together, those notes record how little there was to test. A static file has no server to misconfigure and no stored data or live session to compromise. The review was explicit that it issued no “secure, production-ready, or compliant” verdict and that “absence of a finding here is not evidence of safety.”

Scope map, A clean review of a very small surface. An FSR-observed panel shows the artifact: one readable index.html of markup, CSS, and client-side JavaScript, with the lead form stopped inside the browser and no request leaving the page. A reviewed surface column lists static markup and copy, client-side validation and browser gates, and an inert lead form with no endpoint and form-action none, ending at a scope boundary. Across the boundary an absent production surface lists endpoint, server validation, rate limits and bot control, storage and logging, sessions and authentication, and HSTS and frame-ancestors, none of which existed to review. Zero fixes marked where the surface ended, not that a production system was safe.
What the security review could and could not reach. The reviewed surface was one static file: markup, client-side scripts, and a lead form that submits nowhere. Everything a live product exposes, the endpoint, server validation, storage, sessions, and transport headers, was not built, so the review could not assess it. Zero fixes marks where the file ended, not a safe production system.

The tool can find things, so the zero was about scope

A skeptical buyer should ask whether the security pass returned nothing because the tool cannot find problems. The other review in the same session answers that. The specification and quality audit, a 16-agent workflow, raised 10 findings, confirmed 5 through its verification agents, and rejected the other 5 as false positives. The five it kept were real and it fixed them: a real product name used in ad copy where the brief forbade named brands, a mobile call-to-action bar that stayed keyboard-reachable while hidden, validation errors that a screen reader would not announce, a unit typo in a font size, and a hard-coded line break that broke awkwardly at phone width. FSR confirmed each of those fixes in the current file.

So the same tool, on the same artifact, in the same session, did find and repair genuine issues, and did throw out half of its own candidates as noise. The security pass returned zero fixes because the artifact had no attackable surface. The run establishes a scope distinction: the reviewer works, but a static file gives it almost nothing to work on.

Data panel, The zero was about scope, from one run with two reviews and primary session records. The security review ran 20 agents and produced 14 candidate findings, 11 Info and 3 Low, consolidated to 10 items, and applied 0 code fixes, advisory only, with no secure, production-ready, or compliant verdict. The specification and quality audit ran 16 agents on 10 candidates, confirmed and fixed 5, and rejected 5 as false positives, tagged ad copy, keyboard focus, screen-reader, CSS unit, and mobile break. A footer reads 36 of 36 review agents logged claude-fable-5, with no Opus, Sonnet, or Haiku fallback trace in this session's per-agent transcripts, one artifact, N equals 1. Independent blind re-review was not performed.
The two reviews from the same session, side by side. The security pass changed nothing and issued no safety verdict, while the quality audit found five real defects, fixed them, and discarded five of its own false positives. The zero came from an empty attack surface, not a tool that cannot find problems. All 36 agents logged Fable 5 with no fallback, for this one artifact.

Which model actually ran

A review is only as attributable as the model behind it, and interface labels do not settle that. Anthropic documents three ways the model can differ from the one shown: subagents can run on cheaper models, a workflow can route a stage elsewhere or set a model through the CLAUDE_CODE_SUBAGENT_MODEL variable, and a safeguard can reroute a flagged request to Opus 4.8 with the answer “labeled with the model that answered” (sub-agents, workflows, model switching).

For this run the records close that gap. Across all 36 review agents, the model field in the transcripts reads claude-fable-5 and nothing else, with no trace of a fallback to Opus, Sonnet, or Haiku. That is a strong, checkable answer for this one session, and it is exactly the kind of answer a buyer should demand rather than assume. It does not generalize: the next generation could route differently, and only its own logs would show it.

Screenshot of a Claude usage dashboard, model tab, seven-day view. A single bar on July 18 is labeled Fable 5 886.7k, the legend reads Fable 5 with 1.2k in and 885.5k out at 100.0 percent, and the left sidebar lists two sessions, KintaiFlow B2B landing page and KintaiFlow B2B LP and admin function.
The account usage panel, model view, seven-day window: 100 percent Fable 5, all of it on July 18, 2026 (the build day), totaling 886.7k tokens with 885.5k output and no other model recorded. This corroborates at the account and day level that nothing fell back to Opus, Sonnet, or Haiku; the per-agent attribution for the 36 review agents comes from the transcripts, not this chart. The two sessions in the sidebar include an admin build this review does not cover.

What a clean review authorizes

Treat a clean AI review as a scope record. Anthropic’s own guidance points the same way: automated security reviews “should complement, not replace, your existing security practices and manual code reviews” (automated security reviews). The output worth keeping from the run above is the record of what the review looked at, what it could not reach, and why.

The six-field record to keep from any AI review. 1. Path: the exact command or workflow, the tool version, and whether it ran locally or in the cloud. 2. Scope: the files and boundaries examined, and what was out of reach. 3. Model evidence: the model behind each agent, from the transcript, not the label; mark undisclosed fields honestly. 4. Findings: each with a file and line and a severity. 5. Verification: a named human owner for anything material and for a clean result used in a release decision. 6. Disposition: each finding fixed, rejected as a false positive, accepted, or deferred. Without that record, “the AI reviewed it” is a status line. With it, the review can feed a control.
Framework panel, A clean result should open a control. A clean output of 0 code fixes is labeled a status line, not a release decision, with a warning not to infer safe to ship. A scope record lists six fields to retain: path, the command, workflow, version, and local or cloud; scope, the files examined and what stayed out of reach; model evidence, the per-agent transcript rather than the interface label; findings, with file, line, and severity; verification, a named human owner for material or clean results; and disposition, fixed, rejected, accepted, or deferred, re-run whenever scope changes. A production gate says stop before real data when an endpoint is attached, personal data is collected, or storage or logging is added, requiring human security review and privacy scoping. Let a clean result feed a control, not close one.
What to keep from a clean AI review, and when to stop. The output worth retaining is a six-field scope record: path, scope, model evidence, findings, verification, and disposition, re-run whenever the scope changes. A clean result is a status line, not a release decision, and before an endpoint, real personal data, or storage enters the picture, a human security review and privacy scoping are required. A clean result should feed a control, not close one.

Where the review told the buyer to stop

The security pass also drew a stop-line. The form is built to collect other people’s personal data, the names and email addresses of prospects. As shipped it sends and stores nothing, but its intended use is lead capture, and the review escalated on that point: before any real deployment that collects this data, a first-pass static review is not enough, and a qualified human security review plus privacy-compliance scoping is required. In Japan that means at minimum the Act on the Protection of Personal Information, covering consent text, purpose specification, retention, and processor handling. That boundary comes from the review’s own output. It is not a legal opinion, and a team collecting real data should take its own advice.

What stays uncertain

This is one generation, and the article says so plainly. The findings describe a single output; regenerating from the same prompt could produce different code and different findings. The clean security result belongs to a static file, and it says nothing about the backend a real product would need, which is precisely the surface the review flagged as absent. An independent second review, run in a fresh session with no build context, was not performed, so the question of whether a blind pass would reproduce these results is open. The model attribution holds for this run’s logs and does not forecast the next one. And the product details cited here are dated: research-preview features and entitlement windows change, so re-read the linked sources before relying on one.

FAQ

Does a clean AI security review mean the code is safe to ship?
No. In this run the security pass returned only advisory notes and made zero fixes because the artifact was a static file with almost no attack surface. The review itself declined to issue a secure or production-ready verdict and said absence of a finding is not evidence of safety.
Zero fixes from the security pass, but the tool fixed other things?
Yes. A separate 16-agent specification audit on the same file found 10 issues, confirmed 5, rejected 5 as false positives, and fixed the 5 real ones: a forbidden brand name, two accessibility defects, and two layout and CSS bugs. The tool could find problems; the security pass had little to find.
Is Ultracode a model?
No. Anthropic documents Ultracode as a Claude Code setting that combines its highest reasoning effort (xhigh) with automatic workflow orchestration, running up to 16 concurrent agents and a ceiling of 1,000 per run. It shapes how the work runs; the model and its pricing come from your model selection, in this case Fable 5.
Did every review agent really run on Fable 5?
For this session, yes. All 36 review agents show the model `claude-fable-5` in their transcripts, with no fallback. That is verifiable for this run only. Subagents and safeguards can route to other models, so a buyer should read the transcript rather than trust the interface label.
What should a team keep after an AI review?
The scope record: which command ran, on what files, with which model behind each agent, what it found with file and line, who verified material findings, and how each was dispositioned. That record lets the review feed a real control. The bare result does not.

Methodology and disclosure

This is a hands-on review of one generation. FSR had an AI builder produce the artifact and run its own two reviews, then read the session’s primary records, the workflow metadata, the per-agent transcripts, and the current file, to establish the counts, the model attribution, and the file identity. Those observations are firsthand and scoped to this session. The product facts about Fable 5, Ultracode, the review surfaces, and data retention are official Anthropic claims read on their pages on 2026-07-19 JST, not independent measurements of runtime behavior. FSR discloses that it uses an AI system to write about an AI system’s self-review; that the sample is one generation with non-determinism stated; that an independent blind re-review was not run; and that no payment, health, or government-identifier data was present in the artifact. No credential, key, or token appeared in the artifact or the records, and none is reproduced here.

Note on cost. The run used a Max (5x) consumer plan, and on the build day the session reached its cap; the token budget below is what two multi-agent reviews on one file cost in practice.

Screenshot of a Claude plan panel showing a Max (5x) plan with the current session at 100 percent used and a reset timer.
The run used a Max (5x) consumer plan, and on the build day the current session reached its 100 percent cap. The account logged 886.7k tokens that day across the landing page and admin sessions, which shows that multi-agent self-review is token heavy on a consumer plan. One account, one date, not a general pricing claim.

Verdict

For a buyer, the useful question is not whether this tool reviews well. On the evidence it can: it found and fixed five real defects on this file and discarded five of its own false positives. The question is what a clean result licenses, and the answer here is narrow. A security pass that changes zero lines on a static file marks where the surface ends. Everything a real product exposes, the endpoint, the storage, the sessions, the transport, was still unbuilt, and the review said so and escalated to human review before any real data is collected. The buyer action follows: keep the scope record, treat the boundary as a procurement fact, and let a clean result feed a control instead of closing one.

Sources (official primary unless noted; all accessed 2026-07-19 JST)