Use Fable Before You Know What to Ask

Today, we explore why Fable’s sharpest edge is its ability to surface the decisions you didn’t know you were making. Plus, Every’s head of social media Becky Isjwara walks through how she had Fable diagnose and fix a task Opus 4.8 kept fumbling, and product leader Trevin Chow shares the /ce-pov skill, which forces an AI’s impressions of a new tool to survive contact with your project’s constraints.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Signal

Use Fable to find your unknowns

Today is the last day Fable 5 is included in the weekly limits for Claude Pro, Max, Team, and select Enterprise plans. Starting tomorrow, it moves to pay-as-you-go usage credits. At twice the price of its closest sibling, Opus 4.8, the question is: When is Claude’s pricey mega-model worth calling in?

It’s tempting to save Fable for the biggest, most heavy-duty jobs you have. But there are more ways to measure complexity than the size of the task. Some jobs are hard because they demand enormous execution against a settled plan. Others become hard when the model discovers that the goal, baseline, or standard was wrong from the start. A smaller model may handle the first surprisingly well. Fable’s advantage becomes clearest in the second.

Anthropic member of technical staff Thariq Shihipar offers a way to recognize this second kind of difficulty before Fable spends time executing against the wrong premise. His field guide shows how to use the model to surface questions and decisions that the assignment leaves unresolved, both before execution and as the work unfolds.

He frames the problem as a gap between the map and the territory. The map is the prompt, skills, and context you give Claude. The territory is the codebase, the real world, and the constraints that each introduces. Thariq calls the gaps between them “unknowns”: moments when Claude must make a decision without enough information to know what you would want. Picking up on a framework popularized by former United States Secretary of Defense Donald Rumsfeld, Shihipar differentiates between “unknown knowns” and “unknown unknowns.” An “unknown known” is a criterion so obvious to you that you would never think to write it down, though you would recognize it when you saw it. An “unknown unknown” is a question you have not considered at all—which the model may encounter in the course of its work without a map to guide it.

Every’s experience with Fable illustrates both kinds. Head of tech consulting Mike Taylor gave Fable the completed manuscript of his book about the AI programming framework DSPy. His request had explicit boundaries: Read it and tell him what he had missed. Yet it posed an unknown known. Mike expected to recognize a major omission if Fable surfaced one, even though he could not name it in advance. The difficult part was evaluation rather than execution.

Every CEO Dan Shipper pointed Fable at five weeks of stalled copy-editing experiments and asked it to review the work and “come to your own conclusion.” The model found an unknown unknown: Dan had set a goal of reproducing 70 percent of editor in chief Kate Lee’s historical edits before measuring how often Kate herself would make the same edit twice. The team had spent five weeks improving performance against a target it had never validated. Fable’s useful contribution was finding fault in the assignment itself.

These examples expand the definition of a Fable-sized task. Mike’s hinged on an unnamed standard. Dan’s was an unquestioned premise. Neither would look especially heavy-duty by scope alone.

Once every Fable request hits the meter, triage by uncertainty as well as scale. Use a cheaper model when the goal, constraints, and definition of good are settled. Reach for Fable when the map is still incomplete.

Ship faster on the cloud trusted by Every and 6M+ other builders

Kieran Klaassen built the first prototype of Cora in an afternoon and deployed it on Render. Cora has run on Render for years, and Render has become part of how Every builds and ships AI products: simple, reliable infrastructure that stays out of the way.

Render gives builders a production-ready cloud for web services, workers, Postgres, cron jobs, AI workloads, and full-stack apps without forcing you to spend time managing infrastructure. The same platform that ships your first version in minutes scales to production.

Every readers can claim $50 in Render credits and try the platform trusted by Every, Base44, Cognition, Polsia, Basis, and millions of other builders.

Claim $50 in Render credits

Want to sponsor Every? Click here.

Steal this workflow

Let one model write an instruction manual for the rest

Every’s head of social media, Becky Isjwara, spent weeks trying to get Opus 4.8 to turn long livestreams into short social clips. It could find the right moments, but it cut audio mid-word and let the captions drift out of sync. Last week, she gave the same job to Fable and asked for something more durable than clips: a method a cheaper model could follow next time. Here’s how she did it:

1. Give the expensive model the job and the failed attempts. Becky supplied the livestream, examples of the clips she wanted, and the errors Opus had made. She also explained that one good clip might splice together moments several minutes apart.
2. Make it document the method. Fable planned each clip in text, marked each segment with its first and last spoken phrases, matched those phrases to word-level timestamps in code, and inspected frames after every render. Becky had it save the supporting scripts and editorial instructions outside the chat.
3. Test the manual on the cheaper model. Next time Becky needs to clip a video, she’ll start with a new Opus session with the instructions, scripts, and a fresh source file. She’ll bring back Fable when the format changes or the instructions fail in a new way.

Do this week: Give Fable one recurring job your everyday model fumbles. After it completes the job, paste:

Turn the method you used into instructions that Opus can follow on a new example. Put repeatable, rule-based steps in scripts. Put judgment calls in a skill with examples. Define the inputs, outputs, and quality checks. Test the workflow once, then list anything that still requires Fable.

Skill share

Ask your project what it thinks

Ask an agent for its view on a new library, framework, or idea, and it will often judge the thing in general while ignoring your dependencies, prior decisions, and constraints. Product leader and compound engineering contributor Trevin Chow kept reaching for a new skill in Every’s open-source compound engineering plugin called /ce-pov because it forces that advice to survive contact with the project.

The workflow works in code repositories and in project folders made of documents, decks, or data:

1. Frame a decision. Give /ce-pov an external input and say what you need to decide. Try: /ce-pov Should we adopt this database library here? A bare link also works. The skill inspects it and asks which decision you want to make instead of guessing.
2. Require project and external evidence. The skill must cite a verified project fact—an existing dependency or integration point—and at least one external source. It checks disconfirming evidence and prior decisions before grading.
3. Follow the grade. Every run ends with one of five verdicts: Adopt, Trial, Hold, Reject, or Not-our-problem. It then recommends a plan, a scope discussion, a reversible test, or a stop.

Try it this week: Open a real project folder and paste one tempting link: /ce-pov [link] Should we adopt this here? Read the cited project fact before the grade. If the skill misunderstood your situation, the verdict has failed.

Data point

The cheaper model won

13.8 times cheaper

Researchers at Bridgewater AIA Labs, working with Thinking Machines Lab and using its Tinker training platform, fine-tuned Qwen3-235B to outperform every frontier model they tested across six financial tasks—at 13.8 times lower inference cost per task.

Fable earns its premium while the assignment still contains unknowns. Bridgewater’s result shows that a cheaper specialist can beat a general frontier model on repeated, well-defined work.

Discuss

“We’ve been roughly right on technological predictions and pretty wrong on the social and economic implications.”—Sam Altman, CEO of OpenAI, in the Wall Street Journal

AI CEOs spent last year prophesying mass unemployment as a result of how powerful their products are. Their new, sunnier case is that companies will use AI to take on more work with the same staff, and people will move into new roles as machines take over parts of their jobs. This tracks with what Dan has argued: When AI makes code and writing cheap to produce, companies produce much more of both, but they still need engineers and editors to decide what’s worth keeping. The open question is who gets that new work—and whether it goes to the people whose old jobs disappear.

Katie Parrott is a staff writer at Every. You can read more of her work in her newsletter. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

We build AI tools for readers like you. Write brilliantly with Spiral. Organize files automatically with Sparkle. Deliver yourself from email with Cora. Dictate effortlessly with Monologue. Collaborate with agents on documents with Proof.

For sponsorship opportunities, reach out to [email protected].