The most interesting Claude Fable 5 demos are not the ones where someone builds a toy app. We have had AI toy apps for a while. The interesting part is that the first draft is starting to feel more like a serious product draft: deeper interface detail, more working mechanics, more self-verification, and fewer tiny follow-up prompts just to make the obvious pieces exist.
The video below collects a useful batch of early Fable 5 builds: a Lovable-style app builder, a 3D Library of Babel, an all-in-one productivity app, a music studio, games, a markdown editor, and Andrew's own screenshot markup tool. The practical lesson is not "Fable replaces developers." The practical lesson is that people who can describe workflows clearly can now create custom software much earlier in the conversation.
Source Note
The individual build examples below come from the supplied video and transcript unless otherwise linked. I am treating them as early demonstrations, not audited product case studies. For claims about Fable 5 itself, the source-backed baseline is Anthropic's own material: Fable 5 is positioned for ambitious, long-running coding and knowledge work, is priced at $10 per million input tokens and $50 per million output tokens, requires 30-day data retention, and can route safeguarded requests to Opus 4.8.
Anthropic's prompting guidance also matters here because it directly supports the video's core lesson: Fable 5 performs best when the task is hard enough, the goal is clear, the effort level is chosen deliberately, and the agent has verification criteria instead of a vague "make it good."
What The Demos Show
The headline is not that Fable 5 can generate a pretty UI. Many models can do that. The shift is that Fable appears better at filling in product-shaped gaps without being told every single obvious detail.
In the transcript, the repeated phrase is basically this: it gets more of the first pass right. A productivity app does not just get a text box; it gets a to-do list, calendar, notes, kanban, timer, and small break game. A 3D project does not just get a cube in a browser; it gets movement, scene structure, visuals, interaction, and a concept. A screenshot tool does not just get a canvas; it gets the user's personal friction points, like automatically pasting the screenshot and exposing only the markup controls they actually use.
That is the useful benchmark for builders: not "can it produce code?" but "can it infer enough of the product surface to give me a usable working draft that I can steer?"
The Fable 5 Builds
The video covers a wide set of early Fable 5 examples. The best way to read them is as a map of where Fable is becoming useful: app scaffolding, interaction design, simulation, creative tooling, and custom internal utilities.
| Build | What it shows | Builder lesson |
|---|---|---|
| Lovable-style app builder | A prompt-created app that itself builds apps, then creates a Notion-like interface. | Fable 5 is strongest when the goal has a known product pattern and screenshots or references guide the result. |
| Music production app | A digital audio workstation style interface with mixer and sequencer elements. | Creative tools are becoming easier to rough out because the model can combine interface, state, and interaction. |
| 3D Library of Babel | A browser-playable 3D literary world inspired by Borges, built from a single ambitious prompt in the demo. | Long-horizon prompts need a concept, not just a feature list. Fable can work with theme, environment, and interaction. |
| All-in-one productivity app | To-dos, kanban, calendar, notes, Pomodoro, and a small game in one workspace. | The "ask me questions first" pattern matters because personal productivity tools depend on user-specific preferences. |
| Markdown editor | A custom editor with document creation and comments. | The new builder default may be personal editors and internal tools instead of generic to-do apps. |
| 3D virtual drum kit | A playable drum scene with spatial layout, controls, and visual detail. | Browser toys are still useful tests because they reveal physics, audio, 3D, and interaction quality quickly. |
| Studio lighting simulator | A practical visual simulator for planning a physical room setup. | Fable 5 is interesting when it turns a real-world planning task into a small custom tool. |
| McKinsey-style AI research deck | A generated presentation based on a reference report style. | Slides still need human fact review. Style cloning is easier than making good strategic judgment. |
| AI Monopoly multiplayer game | A game interface that reportedly included multiplayer link sharing. | Unexpected infrastructure is the new surprise: the agent may add more architecture than the prompt explicitly requested. |
| Turbo Kart | A Mario Kart-style browser game with more detail than earlier one-shot game demos. | Games are a good stress test, but business value comes when the same capability is aimed at real workflow friction. |
| Andrew's screenshot markup tool | A personal screenshot tool built around one person's actual markup habits. | This is the highest-signal example: small, specific, personal, and useful every day. |
Does This Kill Notion, Slack, Or Lovable?
No, not in the simple version people like to argue about. A custom Fable app can replace a narrow personal workflow. It does not automatically replace security, collaboration, permissions, enterprise support, integrations, audit logs, mobile polish, billing, templates, onboarding, uptime, and the thousand small pieces that make mature SaaS valuable.
But the video points to a real pressure point. If your company pays for a tool and then spends months bending the business around that tool, Fable-style building becomes tempting. A custom app does not need to beat Notion at being Notion. It only needs to beat your current awkward spreadsheet, copy-paste chain, shared inbox, screenshot workflow, or client status board.
That is where JQ AI SYSTEMS readers should pay attention. The strongest first build is not "clone Slack." It is "build the tiny workflow surface our team keeps recreating manually."
Three Prompting Patterns
The video closes with three patterns that are more important than the demos themselves. They line up closely with Anthropic's own Fable prompting guidance.
1. Use Fable As A Thought Partner Before You Build
Fable is expensive and can work for a long time. That means the planning step matters more, not less. Before asking it to build, ask it to challenge the idea, identify missing constraints, and recommend the smallest useful version.
A useful opening move:
I want to build [tool] for [user/workflow].
Before writing code, act as a product partner.
Challenge the idea, identify missing assumptions, and tell me the smallest version that would be genuinely useful.
2. Make It Interview You
The "interview me" pattern is the best bridge for non-developers. You do not need to know every technical requirement, but you do need to make product decisions. The agent can extract those decisions from you with questions.
This is why Andrew's screenshot tool example is more useful than a flashy game. He did not ask for a generic image editor. He described his current frustration, linked a reference, listed what mattered, and let Claude ask clarifying questions. The result fit his workflow because the prompt captured the workflow.
3. Define Verification Criteria Before The Run
Anthropic's prompting docs are explicit that longer autonomous tasks need verification. Ask the agent to define what "done" means, then test against that definition. For UI work, that may include screenshots. For code, tests and linting. For internal tools, sample data and user-flow checks.
Fable's value is not that it never makes mistakes. The value is that it can plan, build, and check more of its own work when the harness and prompt require it.
Cost And Effort Control
The transcript also names the biggest downside: Fable 5 can be slow, expensive, and token-hungry. That matches the official guidance. Anthropic says effort is a primary control for the tradeoff between intelligence, latency, and cost. Use higher effort for complex builds, and lower effort for routine work.
A practical rule:
- Low or medium: quick edits, simple explanations, small copy changes, low-risk UI tweaks.
- High: normal app building, planning, refactors, product reasoning, and multi-step implementation.
- xhigh or dynamic workflows: hard migrations, large feature builds, end-to-end prototypes, and work where verification quality matters more than speed.
The expensive mistake is using Fable as a magic autocomplete box. The better pattern is to spend a few minutes making the task sharper before you let it run for an hour.
A Reusable Starter Prompt
If you want to copy the spirit of the video without copying any single app, use this:
I want to build a small custom tool for this workflow:
[Describe the workflow in plain English.]
The current pain is:
[What is slow, annoying, repetitive, or error-prone?]
Before building anything:
1. Interview me with up to 10 clarifying questions.
2. Identify the smallest useful version.
3. Challenge any weak assumptions.
4. Propose the data model, screens, and user flow.
5. Define verification criteria for "done."
After I answer, build the simplest working version.
Use a dynamic workflow or separate verification pass to check:
- The main user flow works.
- The UI matches the intended use.
- The app handles obvious edge cases.
- No extra features were added beyond scope.
- The final result is easy for a non-technical user to understand.
That prompt is deliberately not "make me Notion." It starts with the workflow, asks for interview questions, narrows scope, and creates a verification target. That is what separates a builder from someone buying lottery tickets with tokens.
Builder Checklist
- Start with a real irritation. Screenshot markup, client notes, report formatting, inbox triage, internal dashboards, and personal editors are better first targets than giant SaaS clones.
- Bring references. Screenshots, examples, old tools, spreadsheet exports, and "I like this but hate that" notes help Fable infer the right surface.
- Ask for questions first. If the agent never interviews you, it will invent product decisions on your behalf.
- Choose the effort level. Do not run every prompt at the most expensive setting.
- Define done in testable terms. "Looks good" is weak. "Can paste screenshot, draw arrow, copy result with keyboard shortcut, and reload without losing canvas state" is better.
- Keep review gates. Generated decks, code, client tools, and research outputs still need human review.
- Build the tiny daily-use tool first. A tool you use ten times a day teaches you more than a flashy demo you open once.
The short version: Fable 5 makes ambitious first drafts easier. It does not remove the need for taste, constraints, review, or a real workflow. The people who win with it will not be the ones shouting the biggest prompt into the void. They will be the ones who can turn messy work into clear product decisions.