🧭 The Turning Point: Models That Operate on Intent

For three years, the recipe was the same: the model makes a mistake, you write one more rule. "Always run the tests." "Read the documentation before changing anything." "Ask permission at every step." Each line came from a real failure by a weaker model. In September 2026, that recipe was turned upside down: the two new generations follow instructions so well that follow the crutches — and the crutches started costing you quality.

Claude Fable 5.1 (Anthropic, 1/Sep/2026). Same model as Mythos 5.1, with different safeguards. It was built for long-running, autonomous work: it can sustain tasks for hours or days, keep its own records, reprioritize, and pick up where it left off. Fable 5’s official prompting guide says, verbatim, that skills designed for earlier models “are too prescriptive and may degrade output quality.” Version 5.1 is about 25% cheaper in typical use and up to 45% cheaper in agentic work, and at medium effort delivers what Fable 5 did at high effort.

GPT-6 Astra (OpenAI, preview 3/Sep, public 4/Sep/2026). Major gains in computer use, coding, science, and long context. A new behavior that catches everyone by surprise: it asks more questions before acting and format everything as lists. A prompt that only describes the task often comes back with a question and a summary instead of the completed work. According to OpenAI’s own guidance (cited by the guides we read), the antidote is to tell the model to infer intent from context and persist until the objective is complete — and make it clear that recognizing that could doing isn’t the same as having done it.

Notice the pattern. The two errors are opposites (one goes beyond the request, the other stops too soon), but they have the same cause: the model is following what you wrote, not what you wanted. If your text still describes steps, the model executes steps. If it describes firm boundaries, the model stops at the boundary. What’s missing isn’t more instruction—it’s writing the intent in a way the model can complete on its own.

On 5/Sep/2026, the Codex developer experience team at OpenAI published a guide telling its own users to "stop overengineering prompts": skills, instruction files, and task requests had accumulated "fat — the scaffolding a weaker model needed and a stronger one doesn’t." At Anthropic, the recommendation is the same in different words: review your old instructions and remove what the default behavior already does better.

For this course, there’s good news. The 5 pillars from day 2 don’t disappear—they change form. Context becomes source of truth (what’s authoritative, not everything you know). Objectives become result + definition of done. Rules become authority boundaries (what it decides on its own, where it stops). Memory becomes lessons file that the model reads and writes. Validation becomes verification with evidence before declaring it complete. That’s what we’ll build today.

An honest caveat: all of this is time-sensitive. The two models have been out in the wild for less than a week as we write this, and their behavior is still being measured. What doesn’t change is the method: with each generation handoff, you re-audit what you wrote. This day teaches the method using the facts from Sep/2026 as a case study.

Writing for the next generation is, above all, an exercise in delete. Not because instructions stopped mattering, but because every line is now taken seriously. A useless line is no longer ignored—it’s followed, taking the place of a line that mattered.

The cutoff comes down to one question, asked line by line: “does the model I use today still need this?” If a line exists because a 2024 model forgot to run a test, and the 2026 model runs it without being asked, remove it. If it exists because the action is truly dangerous (deleting data, publishing to production, spending money), keep it — and give it the right name: boundary, not step.

The most common targets for cuts, according to the guides from both providers: (1) required rituals (“read all the documentation before making any changes”); (2) obvious reminders (“run the tests”, “don’t make things up”); (3) “ask permission” generic, created after an scare with an older model; (4) formatting rules in both senses — Fable 5.1 already uses less bold text and fewer lists than earlier versions, so “never use bullets” now removes structure that would be useful; (5) “show your reasoning” — in Fable, this may even trigger a refusal due to reasoning extraction; if you need to see progress, ask for progress updates, not a transcript of the model’s thoughts.

Skills and project instruction files (CLAUDE.md, AGENTS.md) suffer from the same problem, with one added complication: they're global. One bad line there contaminates every task. The Codex guide's recommendation is direct: keep skill descriptions short and a specific trigger (“use when reviewing a database migration file — not for general questions”) instead of “use whenever something is related to databases”. Overlapping skills are consolidated; skills that dump the entire workflow become routers, with the details in a separate file.

Subtracting doesn't mean being left with nothing. The Fable guide's rule is: one short statement of intent replaces the list of behaviors. Instead of listing “don't make long PRs, don't comment line by line, don't list options you won't pursue,” write one sentence: “Start with the result; details and reasoning come next; to shorten it, cut what won't change the reader's decision—don't compress it into fragments.” The model generalizes.

And what takes the place of what was removed? Explicit permissions for safe, repeatable workflows. “Local tests use disposable data and don’t touch production: run them, fix what the change broke, and rerun them without asking for approval at every step.” That’s the opposite of a crutch: instead of slowing you down, it sets you free—within guardrails you designed.

One detail that changes how you test: both companies say the same prompt behaves differently at each effort level and in each generation. So the audit doesn’t end with the cut — it ends by running the real case after the cut and comparing it with before. Subtraction without rerunning is a guess.

On day 2, the Rules pillar answered "what AI can't do." In the new generation, it answers a more nuanced question: how far it decides on its own, and exactly when it stops and calls you. This is the Authority pillar. Too little authority stalls the work; too much leads to actions nobody asked for.

The two new models show the two sides of the error. According to the official guide, Fable “may occasionally take actions that weren’t requested”—drafting an email nobody asked for, creating a backup as a precaution, fixing a nearby bug the task didn’t mention. Astra does the opposite: “takes your boundaries seriously and can stop where you’d prefer it to continue”, in the Codex team’s description. A guardrail written to correct a disobedient model becomes an unwanted stop for an obedient one.

The answer isn’t to erase boundaries or multiply them: it’s to rescope. The Fable guide sums up in one sentence what a 2025 prompt took twenty to say: “Stop for the user only when the work truly requires it: a destructive or irreversible action, a real change in scope, or information only they have. If you hit one of those, ask and end the turn instead of ending with a promise.” These are the three stops. Anything that isn’t one of those—reversible actions that follow from the request—proceeds without asking.

On Astra’s side, the mirrored instruction: “infer the intent from what you already have, list your assumptions at the top, and proceed based on them”. Notice it doesn’t say “never ask”—that would force a guess when a real decision is missing. It redirects the question: instead of stopping, the model states what it assumed and continues. You stay informed without getting stuck. The guides also suggest making it explicit that read-only, review, and reversible actions already carry implied authorization.

On Fable’s side, the guardrail against excess, also from the official guide: "If, while working, you find a pre-existing bug or behavior that the task doesn’t mention, don't fix or extend this in this change; report it as an open item in the summary. Where the task is ambiguous, implement the interpretation best supported by the text, state your assumption, and don’t build for the other interpretations.” And the distinction that’s worth its weight in gold in operations: when the user is describing a problem or thinking aloud, the deliverable is the assessment—report it and stop; don't apply the fix before being asked.

There's a second reason to write boundaries carefully, and it's security. A third-party reading that circulated this week sums it up well: “a prompt represents intent; a permission represents a constraint”. The stronger the model, the weaker “the prompt said not to” is as a control. High-risk boundaries (deploying, deleting, paying) also need to exist outside the text—in tool permissions, access, and the environment. The prompt says where to stop; the environment enforces it.

The Authority pillar test is simple: read your list of rules and classify each one as stop (one of the three), permission (approved safe workflow) or crutch (a rule that exists because of an older model). The first stays and gains a guarantee in the environment. The second stays and gives it freedom. The third goes.

If the model takes care of the "how," the most valuable part of your text becomes the finish line. A guide about Astra sums it up: “the best prompt defines a finish line—it says what result to produce, what evidence governs the answer, what it can decide on its own, how the deliverable should be structured, and what to check before finishing.” The last two parts— ready e verification — are what separate a prompt that delivers work from one that returns a question.

Definition of done is the test that you would apply before accepting. It’s not "a good report"; it’s "totals match the spreadsheet, change versus the previous week, three items with actions." Written this way, it does three things at once: gives the model a criterion for knowing when to stop, prevents it from stopping too soon (Astra) or going on too long (Fable), and becomes the day 3 validation checklist without extra work.

Verification with evidence addresses a problem that has become more visible precisely because models now run for hours: fabricated progress reports. The Fable guide provides the instruction that, in Anthropic’s tests, "practically eliminated" this: "Before reporting progress, audit every claim against a tool result from this session. Only report work for which you can point to evidence; if something hasn’t been verified yet, say so explicitly. If tests failed, say so with the output; if a step was skipped, say so; when something is done and verified, state it without hedging."

There are a couple of new pitfalls. The first, on Astra's side: recognizing that you could do it doesn’t mean you’ve done it. Without this in writing, it sometimes responds with a competent plan and stops. The second, from Fable 5.1’s perspective: on long, asynchronous tasks, it may end the turn by describing the next step (“I’ll do this next…”) or asking permission for something already covered by the request (“should I apply it?”). The official guide gives this closing instruction: “Before ending, reread your last paragraph. If it’s a plan, a question, or a promise about work you haven’t done, do that work now.” This doesn’t apply to live pair work—it applies when you aren’t watching.

Even better verification is the kind that isn't done by the person who produced it. The Fable guide is explicit: “separate verifiers with clean context tend to outperform self-critique.” For long tasks, the instruction is to establish a rhythm: “Set a method for checking your own work every [interval]; run it against the spec with subagents.” If you don’t use subagents, the equivalent is Day 3: have another person or another session run the checklist.

Put the pieces together and you have the structure the Astra guides call six-part prompt, which is, in practice, our Day 2 Brief, updated: Outcome · Source of truth · Constraints · Authority · Output contract · Verification. “Outcome” prevents aimless analysis; “source of truth” controls the evidence; “constraints” define the solution’s boundaries; “authority” reduces unnecessary pauses; “output contract” makes the result usable; “verification” defines done.

A note about sources that applies to anything using search: Fable 5.1 at low effort tends to answer from memory instead of searching. When the subject changes quickly (AI models are the guide’s own example), say that recognizing a name doesn’t mean knowing its current state and that it should look for before answering. It’s a definition of done for research: done includes having checked.

When the model handles the “how,” three controls are still yours, and the previous generation didn’t have them in quite the same way: how much it thinks (effort), what it remembers between rounds (file-based memory) and how it keeps you informed in work that lasts for hours. The three replace a lot of old instructions.

Effort is the main control. Both houses use the same five-level scale — low, medium, high, extra high, and maximum — and mean the same thing: it’s the dial that trades intelligence for latency and cost. In Fable 5.1, the default is high (in Claude Code) or medium (in chat), and at medium it delivers what Fable 5 delivered at high, for less. At low, it competes on cost with smaller models and scores higher. The guide says to retest the scale with each generation: the same level name doesn't mean the same amount of thinking across models. Rule of thumb from the Astra guides: extraction and formatting at low; writing and routine changes at medium; multi-file work and long analysis at high; broad refactoring at extra-high; architecture decisions you’ll put into practice at maximum.

High effort has a familiar side effect: on routine tasks, Fable "may gather context and deliberate beyond what the task requires" and be tempted to fix things no one asked for. The line in the guide that prevents this replaces ten rules: “Don’t add features, refactor, or introduce abstractions beyond what the task requires. Do the simplest thing that works well.” If the task gets done but takes too long, lower the effort level before changing the prompt.

Memory becomes a file — and the model writes to it. The day 2 Memory pillar was what you stored for the AI to read. Now Fable “does particularly well when it can record lessons from previous runs and consult them.” The official instruction fits in three lines: “Keep one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches, including why they mattered. Don’t store what the repository or history already records; update the existing note instead of duplicating it; delete notes that turn out to be wrong.” And to get started: “Reflect on our previous sessions, identify themes and lessons, and save them in [folder].” It’s the day 3 continuous improvement plan, except the system writes the log.

Long work calls for a rhythm, not surveillance. Fable 5.1 writes less updates during long runs than Fable 5 — the user sees the agent disappear for minutes. The guide says to first delete old lines that suppressed narration ("save everything for the final answer") and only then ask: "Before starting, say in one line what you’re going to do; give brief updates as you work; finish with a self-contained summary." For agents that run without anyone watching, there’s also the "send to user" tool, which delivers an intact message mid-run — but the model rarely uses it unless the prompt says to.

Delegation has become the default. Fable dispatches parallel subagents more easily than earlier versions; the guide recommends using them often, stating when delegation is appropriate, and preferring asynchronous communication—the orchestrator keeps working while they run and steps in if one goes off track. For you, who may not build any agents, the lesson is the same as on day 3: break the system into steps that can run in parallel, and separate the work of producing from the work of checking.

Finally, the money. 5.1 lowered the price of reading from cache, which is what makes long tasks cost up to 45% less. A practical consequence mentioned in the guide itself: compacting the history early to save money "may no longer be the right tradeoff"—try compacting later. And the course’s old advice still holds: use the lowest effort level that meets the definition of done for the task. Run it at two levels and compare against the definition of done; that tells you more about your case than any benchmark.

You left day 3 with a System Sheet run and validated. Today it won’t go in the trash: it will migrate. Each pillar in Brief v1 has a place in Intent Brief v2, and the migration exercise shows exactly what was a crutch, what was a boundary, and what was missing. At the end, you run the same real case in both formats and compare them—that comparison is your proof that you understand the shift.

Step 1 — Audit by subtraction. Take System Sheet v1 and the prompt/document that runs the system. Go line by line, asking: "Does today’s model still need this?" Mark each as a crutch, boundary, or permission. Delete the crutches. Note how many lines you removed—that’s your debt paid number.

Step 2 — Rewrite Context as the source of truth. From the context on day 2, separate what is authoritative (the catalog, the delivery-time table, the policy) rather than just a description. Say which source takes precedence in case of conflict and what to do when information is missing: flag the discrepancy, don’t make anything up.

Step 3 — Turn Rules into Authority. Write what the system decides on its own, the three stop points with examples from your case, and the fixed limits that remain. For each high-risk stop point, note where it is enforced outside the text (access, permission, environment).

Step 4 — Write Done and Verification. Your Day 3 validation checklist becomes the definition of done: the test you apply before accepting. Add the requirement for evidence ("only report what you can point to; for anything unverified, say you didn't verify it") and assign verification to someone separate from the person producing the work.

Step 5 — Adjust Effort and install the lessons folder. Choose the effort level for each type of case (routine at medium, shutdown at high, for example). Create the lessons folder with rules for adding, updating, and discarding lessons, and put in it the first gap you fixed on day 3.

Step 6 — Run the same case in both formats and compare. Take the real case from day 3. Run it with System Sheet v1 and v2, preferably on the same model and, if you can, on two models (one from Anthropic, one from OpenAI). Note: Did it ask or act? Did it stop where it should? Did it meet the done criteria? How many instruction lines did it use? This comparison table, together with the completed System Sheet v2, is your day 4 deliverable.