Claude Opus 4.8 Masterclass

Section 01

What Actually Shipped on May 28

Anthropic released Claude Opus 4.8 on a Wednesday, exactly 41 days after Opus 4.7 — the fastest version cadence in the company's history. The announcement covered four products, not one. Knowing which is which matters because each has different plan availability and different surface controls.

Two smaller changes worth knowing: the minimum cacheable prompt length dropped from 4,096 to 1,024 tokens, which means short prompts can now create cache entries with no code changes. And Fast mode is now three times cheaper than it was on previous Opus models, at $10 per million input and $50 per million output, for 2.5× the output speed.

Section 02

The 30-Second Demo (Proof of Value)

Before the deep dive, one before-and-after. The same task, identical inputs, two different models. The point isn't the syntax — it's the shape of the new model's response.

The task: a vibe coder pastes a 40-line Python function and asks “does this look right? Ship it?”

The function looks good. It handles the happy path correctly and the
naming is clear. You can ship it.

A few small suggestions:
- Consider adding a docstring
- The variable name 'x' on line 12 could be more descriptive
- You might want to add some unit tests later

Before I sign off on this, I see two things that would fail in
production:

1. Line 23 silently swallows exceptions inside the loop. If the API
   call fails for one item, the function returns partial results
   without indicating which items were skipped. Either re-raise or
   return a (results, errors) tuple.

2. The function assumes 'config' has a 'timeout' key. If the caller
   passes an empty config dict, this raises KeyError on line 8 with
   no helpful message. Use config.get('timeout', DEFAULT_TIMEOUT) or
   validate upstream.

The happy path is fine. The two issues above are exactly the kind
of thing that ships unnoticed and fires on a Tuesday.

Want me to draft the fix, or are these acceptable trade-offs for
your use case?

That's the difference, in one demo. Opus 4.7 found the right answer in style: comment quality, naming, “you might want to add tests later.” Opus 4.8 found the bugs that would actually ship. Same prompt, same model family, $25 more honest per million output tokens.

Section 03

The Honesty Story (Why 4.8 Matters)

The headline isn't a benchmark number. It's a behavioral shift Anthropic measured across four separate honesty evaluations, and that early testers reported as the most-felt change. For vibe coders — people who depend on the model's self-report of progress — this is the most consequential release since Opus 4.0.

The three measurable shifts

Zero. Opus 4.8 is the first Claude model to score 0% on uncritically reporting flawed analytical results. When given data that has a subtle defect (a few points that should be dropped but default to zero instead, a malformed timestamp column, a missing value coded as -1), 4.8 catches the data problem first and flags it. Every prior model, including Opus 4.7, sometimes noticed the issue and reported the requested numbers anyway. That changes how you can use Claude for analysis. The model is now an honest filter, not a fluent reporter.

Four times. Compared to Opus 4.7, Opus 4.8 is roughly 4× less likely to let a flaw in code it generated pass without flagging it. The measurement comes from Anthropic's internal “code summary honesty” evaluation: the model summarizes a coding session that secretly contained failures, and is graded on whether it glosses over them. Opus 4.8 glosses over failures only 3.7% of the time. Sonnet 4.6 on the same eval is 17× worse.

Ten times less overconfident. A more than ten-fold reduction in claiming certainty about things the model should not be certain about. Combined with the first two, this is what makes 4.8 the first model honest enough to lengthen the autonomous segment before a human checkpoint without paying for it in production incidents.

What the honesty shift actually changes for you

If you use Claude for coding: spend less time auditing claims of progress, more time reviewing actual changes. The model is now substantially more likely to surface the thing you would have caught in review, before you have to ask.

If you use Claude for analysis: trust the model's data-quality check more than you did. Previous Claudes would sometimes notice a data defect and run the math anyway. 4.8 flags it first. This is the single biggest unlock for analysts.

If you use Claude for research: the “according to my sources” problem is dramatically smaller. Overconfident citations were one of the most common 4.6 and 4.7 failure modes. 4.8 hedges more accurately and admits uncertainty more often.

If you use Claude in production agents: the autonomous segment between human checkpoints can stretch further. Not infinitely, but the math of how much human oversight you need per token of agent output has shifted in your favor for the first time in a year.

Section 04

The Effort Slider You Now Have

Every Opus 4.8 user gets a new control next to the model picker: a five-level slider that decides how deeply Claude thinks before answering. Previously this was an API-only parameter most people never touched. Now it's on every claude.ai and Cowork session, every plan, including free. Choose wrong and you either burn tokens for no extra quality or get a shallow answer to a hard problem. Choose right and the model's value goes up while your token spend stays controlled.

The five levels

Anthropic's official recommendation, from the Opus 4.8 docs: “Start with xhigh for coding and agentic use cases, use high for most other intelligence-sensitive workloads, and step down to medium or low only when you've measured that the lower level holds quality on your evals.”

Where the slider lives

In claude.ai and Cowork, the slider sits in the dropdown next to the model picker at the top of the chat. The default is High. Change it per task, not per session — the right level depends on what you're asking, not how you're feeling about cost.

In Claude Code, type /effort followed by the level. The five named options are low, medium, high, xhigh, and max. There's also a sixth setting called ultracode that sets effort to xhigh and lets Claude decide whether to invoke a Dynamic Workflow automatically. Save it for hard problems where you're willing to spend more for a higher chance of a single-pass success.

The single rule that matters

Pick the effort level before you write the prompt, not after the model disappoints you. The default High is rarely wrong, but the cost-quality math shifts dramatically when you tune it deliberately. Build the habit once: every task you start, think about whether it's Low (cheap), High (default), or xhigh (hard), and set the slider before you type. That single habit captures most of the value the new control unlocks.

Section 05

Vibe Coder Patterns in claude.ai Chat

Six paste-ready prompts for the most common claude.ai workflows. Every one follows the 5-block intent template — the recipe explained in Section 10. The shape is what does the work: you can rewrite the words, but keep the blocks.

I need a sparring partner on a product decision.

OUTCOME: by the end of this conversation, I want to have made the
call between option A and option B with clearer reasoning than I
have right now.

CONSTRAINTS:
- I have ~30 minutes for this
- I'm leaning toward option A but unsure
- The decision is reversible within 60 days
- Audience for the decision is my team of 4 (not investors)

CONTEXT: here are the two options, with what I know about each:
[paste your options + what you know]

TEST: a good answer surfaces 2-3 considerations I have not thought
of, and ends with a recommendation I can defend in tomorrow's
standup.

GATE: before recommending, ask me one clarifying question if my
context above is missing something important. Don't fill gaps by
assumption.

Draft a launch announcement in my voice.

OUTCOME: a 200-word announcement post ready for LinkedIn that
sounds like me, not like an AI.

CONSTRAINTS:
- Direct, no hype, no buzzwords ("revolutionary", "game-changing",
  "thrilled to announce" are banned)
- Lead with what changed, not how I feel about it
- One short paragraph for the what, one for the why-it-matters,
  one specific use case, one ask
- 200 words target, under 240 max

CONTEXT: here are 3 things I've written before, in my voice, so
you can pattern-match:
[paste 3 samples of your writing]

The product: [paste the launch info]

TEST: a good draft makes someone who knows me read it and not
notice an AI wrote it. The voice patterns I'm proud of: short
sentences. Confidence without overclaim. One specific over three
generic.

GATE: if the product info above is missing the one detail that
would make this concrete (a number, a customer, a date), flag it
before drafting.

I'm preparing a one-page brief on this earnings call.

OUTCOME: a structured brief I can hand my team that captures what
actually changed, not what management said.

CONSTRAINTS:
- One page max (around 400 words)
- Four sections: Headline Result · What Actually Changed · What
  Management Said vs What The Numbers Say · What To Watch
- Numbers over adjectives. Every claim cites a specific figure.
- Skip the boilerplate ("delivered strong quarter", "well-positioned")

CONTEXT: the earnings call transcript and the 10-Q are attached.

TEST: a good brief lets a colleague who didn't read the transcript
walk into a meeting tomorrow and answer "so what changed?" in 30
seconds.

GATE: if any management claim in the transcript is contradicted
by the numbers, flag the contradiction explicitly. If the
attached documents are missing something a real analyst would
need (segment data, guidance, footnotes), say so before drafting.

Explain this contract clause to me like I'm a smart non-lawyer.

OUTCOME: I understand what this clause does, what it could be
used for against me, and what's standard vs unusual about it.

CONSTRAINTS:
- Use everyday language, no Latin
- Define every legal term the first time it appears
- Flag anything that's a departure from typical commercial
  contracts in this space

CONTEXT: the clause in question is below. The full contract is
attached for context but I only need to understand this one
clause.

[paste the clause]

TEST: after reading your explanation, I should be able to
re-explain this clause to a colleague in 60 seconds.

GATE: be explicit about what you can and can't tell me. You are
not my lawyer. If there's a risk this clause has consequences
that depend on jurisdiction, my company structure, or facts I
haven't shared, name those dependencies. Don't give legal advice.
Help me understand the document.

Turn this process I've described informally into a real SOP.

OUTCOME: a numbered SOP a new hire can follow in their first week
without me hovering.

CONSTRAINTS:
- Markdown headings, numbered steps
- Each step is one action verb followed by what to do
- Include "what good looks like" after every major section
- Include a Troubleshooting section with the 3 most likely
  things that go wrong
- Under 600 words

CONTEXT: here's the process as I've described it informally. I've
done this maybe 50 times so I assume a lot of knowledge.

[paste your informal description]

TEST: a good SOP lets a smart new person do this task correctly
the first time without asking me a question.

GATE: read my description as a hostile reviewer. If I've assumed
knowledge a new hire wouldn't have ("just go to the dashboard",
"the usual file"), call those out as gaps before drafting. Ask
me up to 3 clarifying questions if needed.

Help me plan next week against real constraints.

OUTCOME: a realistic week plan (Monday through Friday) with the
top 3 outcomes by day and what I should explicitly NOT do.

CONSTRAINTS:
- 6 hours of focus time available per day max (I have meetings)
- One big project takes priority; everything else is supporting
- I want one full afternoon of deep work blocked off
- No working past 6pm

CONTEXT: here are my goals for the week, my recurring commitments,
and the open threads I'm carrying:

GOALS:
[list goals]

COMMITMENTS:
[list standing meetings, commitments]

OPEN THREADS:
[list things you're carrying forward]

TEST: a good plan looks like something I can actually execute, not
an aspirational list. By Friday end, I should have closed the top
3 things, with the rest deliberately deferred.

GATE: be willing to tell me my goals exceed my available hours.
If 6 hours x 5 days can't fit the goals I've listed, say so and
help me cut, don't pretend it fits.

Section 06

Vibe Coder Patterns in Cowork

Cowork is the surface where Claude does multi-step research and document work alongside you. Six prompts for the patterns where Cowork outperforms chat: long-horizon research, structured synthesis, multi-language work, slide-building, dataset analysis, and angle exploration. These lean toward Extra or Max effort because the cost of getting them wrong is high enough to justify the depth.

Research the competitive landscape for [category/space] and give
me a structured one-pager.

OUTCOME: a one-page brief I can paste into a strategy doc that
covers the 5-7 most relevant competitors, what each is good at,
where they're weak, and where the white space is.

CONSTRAINTS:
- 5-7 competitors max (cut anything that's not a real threat)
- For each: one-line positioning, key strength, key weakness,
  one notable recent move (last 12 months)
- Group the competitors by archetype, not alphabetically
- End with 3 specific white-space opportunities, each tied to a
  weakness in the landscape

CONTEXT: my company does [what you do]. Our positioning is [your
positioning]. The category I want analyzed is [the category].
Geographic scope: [US / global / etc].

TEST: a good brief lets me walk into a strategy meeting and
defend a specific positioning move. White space recommendations
should be defensible against "but competitor X is already doing
that" — i.e. you've actually checked.

GATE: search the web before drafting. Cite specific sources for
every concrete claim (a date, a number, a customer name, a
funding round). If you can't find evidence for a claim, hedge
it explicitly or leave it out. Don't fabricate.

Translate this report into Spanish (LatAm), German (DE), and
Japanese (JP).

OUTCOME: three localized versions, each appropriate for a
business reader in that market. Not a literal translation —
a localization.

CONSTRAINTS:
- Preserve the document structure exactly (headings, bullets,
  tables stay in the same order)
- Adapt examples to the target market when the original uses
  US-specific brands or units (currency, distance, food, sports)
- Keep proper nouns (product names, company names) in their
  original form
- Use formal register in DE and JP (Sie, keigo). Use neutral
  professional register in LatAm Spanish.

CONTEXT: the source report is attached. The audience for each
language is mid-level business readers in those markets. The
document will be published as-is, not further edited.

TEST: a good localization reads as if written by a native speaker
who knows the topic. A bad one reads as a translated American
business doc.

GATE: flag any concept that doesn't map cleanly to a target
language (e.g. legal terms, US-only product categories) before
translating. Don't invent a translation for something that should
stay in English. If a paragraph relies on a cultural reference
that won't land in one of the target markets, suggest a
replacement instead of translating literally.

Build me an 8-slide deck on [topic].

OUTCOME: a deck I can present in 10 minutes that opens, makes 3-4
substantive points with evidence, and ends with a clear ask.

CONSTRAINTS:
- Exactly 8 slides
- Each slide has: a headline (the conclusion, not the topic), 3
  supporting bullets, and 2-3 sentences of speaker notes
- Headlines tell the story alone — someone flipping through
  without speaker notes should follow the argument
- The 8-slide arc: 1 hook · 1 context · 3-4 substance · 1
  implication · 1 ask

CONTEXT: the audience is [describe the audience]. The forum is
[meeting type]. The decision they're being asked to make is
[the ask]. Background materials are attached.

TEST: a good deck looks coherent if a colleague flips through it
without me presenting. The story is in the headlines.

GATE: if my topic, audience, and ask don't add up to a coherent
narrative in 8 slides, tell me before drafting. Suggest cutting
the topic to fit or expanding to 12. Don't pad an 8-slide outline
that should be 5, and don't compress a 15-slide story into 8 by
losing substance.

Analyze this dataset and tell me what's actually changing.

OUTCOME: a structured analysis (under 600 words) that surfaces
the 3-5 most material changes in the data, separates real signal
from noise, and tells me what to investigate next.

CONSTRAINTS:
- Don't just describe the data — name what changed and by how much
- For each finding, give: the metric, the magnitude of change,
  the time window, and a confidence assessment
- Skip findings where the change could be noise (small samples,
  short windows, normal variance)
- End with 3 specific follow-up questions a real analyst would ask

CONTEXT: the dataset is attached. The business context is
[describe what the data represents and what would matter to know].

TEST: a good analysis tells me something I would have missed
eyeballing the spreadsheet. The follow-up questions should
sharpen my next investigation, not just list more things to look
at.

GATE: this is where Opus 4.8's data-quality check matters most.
Before reporting findings, audit the dataset itself. If columns
have suspicious values (impossible dates, negative counts where
they shouldn't be, "0" placeholders that should be NULL), flag
the data issue first and STOP. Don't run analysis on broken data
and report the numbers. Tell me what's wrong with the data
before telling me what the data says.

Synthesize these 12 PDFs into one structured brief.

OUTCOME: a single 2-page brief that captures the cross-cutting
themes, the genuine disagreements between sources, and the
specific facts worth carrying forward.

CONSTRAINTS:
- Organize by theme, not by source document
- For each theme: what the consensus view is, where sources
  disagree (and which is more credible and why), one or two
  concrete data points worth remembering
- Cite the source document by short name for every specific claim
  ([Doc 3], [Doc 7], etc.)
- Skip themes that only appear in 1 source unless they're
  important enough to flag for follow-up

CONTEXT: the 12 PDFs are attached. My purpose is [what you're
doing with this synthesis]. Cross-document patterns matter more
than the contents of any individual doc.

TEST: a good synthesis lets me read 2 pages instead of 12 PDFs
and lose nothing critical. The disagreements section should
identify real disagreements, not surface differences in language.

GATE: if 12 PDFs is too few to identify cross-cutting themes
(every doc has unique content), say so. If two PDFs are
near-duplicates of the same content, note it instead of
double-counting. If I'm missing a category of document that
would change the synthesis (an opposing viewpoint, regulatory
context, primary source), flag it.

Draft three angles for this campaign, with honest pro and con
for each.

OUTCOME: three genuinely different angles I can take to my team,
each ready to develop further, with the trade-offs surfaced.

CONSTRAINTS:
- The angles must be strategically different (not just different
  taglines for the same idea)
- For each: a one-sentence angle, 3 bullets on why it could work,
  3 bullets on why it could fail, the audience it targets best
- Be willing to recommend one — don't leave me with three equal
  options
- End with which angle you'd pick and why, in one paragraph

CONTEXT: the product is [what you're marketing]. The campaign
budget is [budget]. The audience is [audience]. The constraint
that's bounded our previous campaigns: [the thing that keeps
biting us].

TEST: a good angle set forces a real strategic choice. If two
of the three angles are obviously inferior, you've cheated and
made the third look strong by comparison. All three should be
defensible — the trade-offs are what differ.

GATE: this is creative work where confidence matters. Don't hedge
your recommendation. After laying out three honest options, pick
one and own the call. If you genuinely can't pick between two,
say so and tell me what would tip you — but don't punt the
decision back to me without a stance.

Section 07

Vibe Coder Patterns in Claude Code

Claude Code is where Opus 4.8 does its hardest work. Eight prompts for the developer patterns where a well-written prompt pays back the most: scaffolding, refactoring, test-first development, adversarial review, mystery debugging, observability, codebase migration, and codebase audit. Most of these run at xhigh effort; one uses Dynamic Workflows. Every one assumes you have a CLAUDE.md in the project with your conventions — if you don't, see Foundation 02.

Scaffold a new [type of project] following the conventions in
this repo.

OUTCOME: a working project skeleton I can `cd` into and run
within 60 seconds, structured to match how we already build
things here.

CONSTRAINTS:
- Match the directory structure of [existing similar project
  path] exactly
- Reuse the existing tsconfig / pyproject / package.json patterns
- Include the same test runner setup we use elsewhere
- Add a README that documents commands and the spec for what
  this project will do
- Do NOT install new dependencies unless absolutely required;
  prefer what's already in the lockfile

CONTEXT: read CLAUDE.md and AGENTS.md first for team conventions.
Look at [reference project path] for the pattern to mirror.
The project I want to scaffold: [describe what it does].

TEST: after scaffolding, I should be able to run the test command
from the README and get a passing empty test suite. The project
should pass our linter and type checker with zero errors.

GATE: before creating files, list every file you're about to
create and wait for my OK. Do NOT modify any existing file in
this repo without explicit permission. If the existing
conventions disagree with each other across the codebase, ask
which to follow.

Refactor [file path] into smaller composable pieces.

OUTCOME: the module is split into smaller files with single
responsibilities, the public API is unchanged, all existing tests
still pass without modification.

CONSTRAINTS:
- The public exports of the module must be identical before and
  after — every external caller continues to work
- One concept per file (no "utils.ts" catch-alls)
- Files under ~200 lines each after the split
- Use the same import/export style already used in the project
- Keep commits atomic: one logical extraction per commit

CONTEXT: the module at [path] has grown to [size]. The pieces I
think are extractable: [list any obvious ones, or "you tell me"].
Read the test file at [test path] first so you know what behavior
must be preserved.

TEST: running the existing test suite after the refactor passes
with no test modifications. Running the linter passes. A
follow-up `git diff` shows the file moves and the import updates,
nothing else changed.

GATE: before refactoring, propose the split as a plan: which
pieces become which new files, the new directory structure, and
the import graph. Wait for my approval. Then make the changes in
small atomic commits so I can review each step. If you discover
the module has hidden coupling that prevents a clean split, stop
and tell me.

Build [feature description] using a test-first cycle.

OUTCOME: the feature is implemented with tests that were written
BEFORE the implementation, exercising both happy paths and the
unhappy paths a real user would hit.

CONSTRAINTS:
- Step 1: write the failing test. Show me the test. Run it.
  Confirm it fails for the right reason (assertion failure, not
  setup error).
- Step 2: implement the minimum code to make the test pass.
  Don't add anything beyond what the test demands.
- Step 3: extend the test set with edge cases (empty, null,
  malformed, oversized, concurrent if relevant).
- Step 4: extend the implementation just enough to cover the new
  cases. Tests pass.
- Step 5: refactor for clarity. Tests still pass.

CONTEXT: the feature: [describe]. The relevant existing files:
[paths]. The test framework: [framework]. Style conventions in
CLAUDE.md.

TEST: at the end, the feature works, the test suite passes, and
the test code itself is short enough to be the documentation for
what the feature does. A new developer reading just the tests
should understand the feature's contract.

GATE: stop after step 1 and show me the failing test before
writing any implementation. Stop again after step 3 and show me
the extended test set before extending the implementation. The
discipline is the point — don't collapse steps to save time.

Adversarially review the diff in [PR URL or branch name]. Find
what's wrong with it.

OUTCOME: a findings list ranked by severity, each finding tied
to a specific line, with the fix described in one sentence.
Don't praise. Findings only.

CONSTRAINTS:
- Severity scale: critical (production breakage), high (latent
  bug), medium (maintainability), low (style/nit). Don't pad
  with low-severity items.
- For each finding: file:line, severity, one-sentence issue,
  one-sentence fix.
- End with one of two verdicts: READY TO MERGE or DO NOT MERGE:
  [reason]. No middle ground.

CONTEXT: the PR description is [paste description]. The
specification it was supposed to satisfy: [paste spec or link].
Existing code patterns: read CLAUDE.md and the files adjacent to
the diff.

TEST: a good review finds the thing the author missed. If the
diff genuinely has no issues, say so — but don't invent issues
to fill a quota.

GATE: this is adversarial mode. You did not write this code. Your
job is to find what's wrong with it. If the diff matches the spec
and looks correct, your finding should be "DO NOT MERGE: the
spec itself is insufficient" or "READY TO MERGE." Don't soften
findings to be polite. Don't hedge. Speak in observations, not
suggestions.

Help me debug this bug. We're going to do it properly.

OUTCOME: the bug is reproduced reliably in a minimal test case,
then fixed, with a regression test added.

CONSTRAINTS:
- Step 1: WRITE A FAILING TEST that reproduces the bug. No fix
  yet. The test must fail for the same reason the bug occurs in
  production.
- Step 2: only after the test fails reliably, propose the fix.
- Step 3: apply the fix. The new test passes. Existing tests
  still pass.
- Step 4: explain what the bug actually was in one paragraph, and
  what class of bug this is (so we can search for similar issues
  elsewhere).

CONTEXT: the bug report: [paste report or describe what happens].
The component involved: [path or area]. Recent changes that might
be related: [list any]. Reproduction steps so far: [what you've
tried, or "I can't reproduce it reliably"].

TEST: a good debug session ends with a reproducible test, a
targeted fix, and a one-paragraph explanation a teammate can read
in 30 seconds. If you can't reproduce the bug, that itself is a
finding — say so and ask for more information.

GATE: do NOT write a fix before reproducing the bug. The most
common debug failure is fixing a different bug that happened to
look similar. If reproduction is hard, say so and walk me through
what information you need to reproduce it. Investigation is
allowed; speculation is not.

Add observability to [script path].

OUTCOME: the script now produces structured logs at key decision
points, useful metrics for understanding behavior in production,
and clear error traces when things go wrong.

CONSTRAINTS:
- Use the logging/metrics library already in this project (read
  CLAUDE.md / existing scripts to find it). Do not introduce a
  new dependency.
- Log at INFO for normal progress, WARN for recoverable issues,
  ERROR for failures. Use structured fields (key=value), not
  string interpolation.
- Add one metric per major operation: count of items processed,
  duration, success/fail count.
- Catch exceptions at the right level — fine-grained where it's
  useful to know which item failed, coarse where the whole run
  needs to abort.

CONTEXT: the script does [describe]. It currently has [describe
existing logging]. The deployment surface is [where it runs].
What we want to learn from production: [the questions we can't
answer today].

TEST: after the changes, when I run the script locally, I can
trace any decision the script made from the logs alone. The
production-question list above should be answerable from the
metrics this script emits.

GATE: before adding logs everywhere, list the 5-8 key decision
points you'll log. Don't carpet-bomb the file with print
statements. Useful observability is selective. If a function is
trivial, it doesn't need a log line.

Create a dynamic workflow to migrate this codebase from
[old framework/library/language] to [new].

OUTCOME: the migration completes end-to-end with the existing
test suite still passing. The work is broken into parallel
chunks that subagents can handle independently.

CONSTRAINTS:
- The existing test suite is the bar. If a migration changes
  observable behavior, that's a regression — back it out.
- Migrate file-by-file in parallel where dependencies allow.
  Files with shared imports get migrated in waves, not in
  parallel.
- Each migrated file gets reviewed by an adversarial subagent
  before being marked complete.
- Use the existing project conventions for the new framework
  (read CLAUDE.md, look at any pilot files already migrated).
- Save progress as you go — this run will take hours, possibly
  days. I want to be able to resume if interrupted.

CONTEXT: the project: [describe]. The current stack: [what it
is now]. The target stack: [what it will be]. The migration
guide we're following: [link or paste]. Pilot files already
migrated: [paths, or "none yet"].

TEST: the migration is complete when every source file is in
the new framework, the existing test suite passes on the new
codebase, the linter is clean, and the build artifacts are
equivalent.

GATE: before fanning out, propose the migration plan: the
dependency graph, the wave order, the per-file budget. Wait for
my approval. If during the run a wave reveals a coupling that
makes parallel work impossible, STOP that wave, surface it, and
ask whether to redesign before continuing. Don't ship a
half-migrated codebase under "made progress" framing.

Audit this codebase against [constraint].

OUTCOME: a list of every place the constraint is violated, with
file:line citations and a brief explanation of each violation.
No fixes, just findings.

CONSTRAINTS:
- Search across the entire repo, not just obvious files
- For each finding: file:line, the offending content, why it
  violates the constraint
- Group findings by category (true violation, ambiguous case
  that needs review, false positive that the heuristic flagged
  but is actually fine)
- Don't carpet-bomb the report with style nits. Stay focused on
  the constraint.

CONTEXT: the constraint to audit: [paste the constraint or
policy]. Examples of violations look like: [paste examples].
Examples of acceptable patterns: [paste counter-examples].

TEST: a good audit catches the violations that exist and doesn't
flag patterns that look similar but aren't violations. If a
single category has 100+ findings, it's probably a
false-positive class — surface that and ask whether to refine.

GATE: before running the audit, confirm the constraint by
restating it back to me in your own words. If the constraint
is ambiguous, ask for clarification before searching the
codebase. Don't audit against a constraint you don't understand.

Section 08

Dynamic Workflows: What They Are and When to Use Them

Dynamic Workflows is the most consequential Claude Code feature shipped in the 4.x cycle. It is also the one most likely to be misunderstood. Strip away the marketing and it's this: Claude writes a JavaScript orchestration script that runs tens to hundreds of subagents in parallel, checks their work, iterates until results converge, and reports a single coordinated answer back. The plan lives in script variables, not in the model's context window — so only the final answer returns to your session.

The three things that make Dynamic Workflows different

Parallel by default. A normal Claude Code session is sequential: one agent, one context, one tool call at a time. A Dynamic Workflow fans the work across many subagents. Each subagent has its own context, its own tools, its own piece of the problem. Caps: 16 concurrent agents and 1,000 total per run.

Verifiable. Adversarial subagents are part of the design. After a finding is produced, another subagent tries to refute it. After a port is written, another subagent reviews it. The run keeps iterating until answers converge, which is how a workflow reaches conclusions a single pass can't.

Resumable. Progress saves as the run goes. If a job is interrupted (your laptop sleeps, your network drops, you hit a rate limit), the workflow resumes where it left off instead of starting over. Workflows are designed for runs that take hours or days — resumability is what makes that practical.

How to invoke one

Two paths.

Path 1: ask for a workflow directly. Anywhere in Claude Code, say “Create a dynamic workflow to do X.” Claude plans the workflow, shows you what it's about to run, asks for confirmation the first time, and then executes.

Path 2: enable the ultracode setting. This is a Claude Code-specific effort level accessed through the effort menu (/effort ultracode). It sets effort to xhigh AND lets Claude decide automatically when a problem is large enough to warrant a workflow. Use this when you don't want to keep deciding manually whether a task should fan out.

When to use them, when not to

Use them for: codebase-scale migrations, audits across hundreds of files, security scans, dead-code discovery, profiler-guided optimization, anything where many similar tasks run independently. Use them when the cost of a wrong answer is high enough that you want adversarial verification built in. Use them for work you want to walk away from and come back to.

Don't use them for: tasks where outputs depend on each other sequentially (the model still has to wait, you just paid more tokens to discover that). Don't use them for prototyping or single-file changes — the overhead exceeds the benefit. Don't use them when you're still figuring out the right approach — figure that out first in a normal session, then use a workflow to scale it.

The cost reality: Dynamic Workflows consume meaningfully more tokens than a typical Claude Code session. Anthropic's own framing is to “start scoped and verify outputs.” Run a small workflow on a small slice of the work first. Look at the result. Look at the cost. Then decide whether to scale up. Don't fire off a 1,000-subagent run on your first try.

What “hundreds of parallel subagents” actually looks like

A workflow run shows you: the plan Claude generated, the wave structure (which subagents fire in which order), live progress as agents complete, the adversarial review of any non-trivial finding, and the consolidated final report. You don't see every subagent's context — that's the point. You see the plan, the checkpoints, and the result. The model is doing the orchestration; you're reviewing the output of the orchestration.

Section 09

The Bun Hero Story (Undeniable Proof)

If you remember one example from this masterclass, remember this one. It's the canonical proof that codebase-scale work with parallel AI agents is now a real thing, not a demo.

What happened

Jarred Sumner, the creator of Bun (a JavaScript runtime alternative to Node and Deno), used Dynamic Workflows in Claude Code with Opus 4.8 to port Bun from Zig to Rust. The numbers:

How it actually ran

The work decomposed into discrete workflow phases, each one a separate Dynamic Workflow:

Workflow 1: lifetime mapping. A workflow mapped the right Rust lifetime annotation for every struct field in the entire Zig codebase. Lifetimes are a Rust concept that doesn't exist in Zig; getting them wrong is the single biggest source of port failures. This workflow ran across the whole codebase, with adversarial agents checking each mapping.

Workflow 2: file-by-file translation. Once lifetimes were mapped, a workflow wrote every .rs file as a behavior-identical port of its corresponding .zig counterpart. Hundreds of agents worked in parallel, with two reviewers per file. The constraint was strict: the public API and the observable behavior had to match byte-for-byte where possible.

Workflow 3: build and test fix loop. A workflow drove the build and the existing test suite until both ran clean. When a test failed, the workflow investigated, proposed a fix, applied it, and re-ran. The loop converged at 99.8% test pass.

Workflow 4: overnight optimization. After the port landed, a workflow ran overnight to address unnecessary data copies introduced by the port. It opened a PR for each optimization for final human review.

What this proves

Three things vibe coders should take from this.

The unit of work is now the codebase, not the file. Before Dynamic Workflows, a 750,000-line port was a multi-quarter project for a team. Now it's 11 days for one engineer plus a workflow orchestrator. The economic implications are large, but the practical implication for a single developer is that ambitions can scale up. The migration you postponed because it was too much code is now tractable.

Adversarial review is the secret sauce. Two reviewers per file is what got Bun to 99.8% test pass instead of 80%. Workflows that skip the adversarial step produce code that compiles and ships bugs. Workflows that keep it produce code that ships clean. When you design your own workflows, this is the line not to cut.

You still own the test suite. Sumner's test suite was the bar. The workflow ran until tests passed. If the test suite is weak, the workflow fails quietly — producing code that passes a low bar. If the test suite is strong, the workflow can't cheat. Strong tests are now more valuable than ever; they're the only thing that scales with AI-generated code.

Section 10

The 5-Block Intent Recipe (The Class Signature)

Every paste-ready prompt in this masterclass uses the same five blocks, in the same order. The blocks are the recipe. The words inside them are negotiable. If you can carry away one thing from this class, carry this.

The five blocks, in order

1. OUTCOME. What you want when this is done. One sentence. The model orients around the goal first — everything that follows is in service of the outcome. Bad outcomes: “help me with my project,” “think about this.” Good outcomes: “a 200-word announcement post ready for LinkedIn that sounds like me,” “a numbered SOP a new hire can follow in their first week without me hovering.”

2. CONSTRAINTS. Anything that bounds the answer. Tech stack, audience, length, tone, files in scope, things to avoid. Bullets work fine. This block is what prevents the model from defaulting to a generic answer optimized for a generic audience. The more specific your constraints, the more useful the output.

3. CONTEXT. The files, URLs, prior decisions, attached documents the model should treat as authoritative. Less is sharper than more here. Three sharp samples of your writing voice teach the model more than ten meandering ones. The right CLAUDE.md teaches the model more than a thousand-line spec. Pick context that does work.

4. TEST. How will you know the answer is correct? Sometimes this is a literal test to pass. Sometimes it's a checklist, a comparison, a target metric. The TEST block matters because it lets the model self-verify before responding. Without it, the model has no way to grade its own draft. With it, the model can iterate internally and ship a stronger first pass.

5. GATE. The verification gate. Tell the model to flag uncertainty, ask before assuming, and stop at clear checkpoints. This is the block that activates Opus 4.8's honesty improvements. Earlier models often ignored the gate. 4.8 honors it reliably. A well-written GATE is what separates a confident wrong answer from a thoughtful pause that saves you from shipping the wrong thing.

Why these five

The five blocks match how Opus 4.8 actually reasons. The model orients around the goal first (OUTCOME), then attends to bounds (CONSTRAINTS), then to authoritative context (CONTEXT), then verifies against the test (TEST), then surfaces uncertainty at the gate (GATE). Skipping any block produces measurably worse output, because the model has to either guess what you meant or fill the gap with average-quality assumptions.

Skip OUTCOME and you get a generic response. Skip CONSTRAINTS and you get enterprise-scale advice for your three-person team. Skip CONTEXT and you get a response that sounds right but isn't about your situation. Skip TEST and the model can't self-verify. Skip GATE and the model fills missing information with plausible guesses instead of asking you.

The minimum viable version

You won't always have time to write all five blocks. The minimum viable version is two: a one-line OUTCOME and a one-line GATE. Even that is dramatically better than “help me with X.” If you build the habit of always opening with the outcome and always closing with a gate that says “ask before assuming,” you'll capture most of the value of the full recipe.

How to grow into the full recipe

Start with the minimum (OUTCOME + GATE). Add CONSTRAINTS the next time the model gives you an answer that's right but not for your situation. Add CONTEXT the next time the model writes something that sounds generic. Add TEST the next time you want to be able to verify the answer yourself. Within a few weeks of deliberate practice, the full recipe becomes automatic and you write the blocks in 30 seconds before any non-trivial prompt.

The 20 prompts in Sections 5, 6, and 7 of this masterclass are all worked examples of the full recipe. Read them again with the recipe in mind and the structure becomes obvious. Then write your own.

Section 11

Pricing & Cost Reality

The headline number is that pricing for Opus 4.8 standard mode is unchanged from Opus 4.7: $5 per million input tokens, $25 per million output tokens. What changed is the cost math around effort levels, Fast mode, and prompt caching.

The four pricing surfaces

The effort-level cost math

The most important cost lever in Opus 4.8 is not the model — it's the effort level. A Low-effort response uses a fraction of the tokens a Max-effort response uses on the same task. Anthropic publishes the following rough guidance:

Low. Roughly half the tokens of High on the same task. Use for triage, formatting, simple lookups. The savings on Low for routine work pay for the spend on Max for hard work.

High (default). Roughly the same token spend as Opus 4.7's default, but with better output. This is a free quality improvement at the same cost — the main reason to upgrade from 4.7 even if you don't use any of the new features.

Extra / xhigh. Roughly 2–3× the tokens of High. Pays off when the cost of getting the answer wrong is high.

Max. No token ceiling. Can spend 4–8× the tokens of Low on the same task. Use for one-shot critical work.

Prompt caching just got cheaper for short prompts

The minimum cacheable prompt length dropped from 4,096 to 1,024 tokens in Opus 4.8. Prompts that were too short to cache on Opus 4.7 can now create cache entries with no code changes. For workloads where the same system prompt or context block repeats across many requests, this is meaningful savings — cached input tokens are billed at a fraction of the standard rate.

The Databricks data point worth knowing

Databricks ran Opus 4.8 inside their Genie AI agent on the same multimodal PDF and diagram workload they used for Opus 4.7. The token cost for the same workload was 61% lower on 4.8 than on 4.7. That number is not from Anthropic; it's from a customer running the model in production. The implication: multimodal cost economics shifted meaningfully in 4.8, even though headline pricing didn't change.

Section 12

The Numbers (Brief)

This section is for the skeptics. The benchmark table is included once, then we move on. Opus 4.8 wins six of seven major benchmarks in the Anthropic-published comparison set; the one it loses is Terminal-Bench 2.1, where GPT-5.5 still edges it on pure command-line agent loops.

What to read from this table, briefly

Two numbers are worth flagging. The +27.4 point jump on USAMO 2026 math proofs is the largest single-cycle improvement in the entire 4.7-to-4.8 comparison — it signals a qualitative change in mathematical reasoning, not just incremental refinement. The +27.8 point jump on GraphWalks BFS 1M measures long-context retrieval over a million tokens, and that scale of improvement is what makes 1M-context use cases practical for the first time.

The Terminal-Bench loss to GPT-5.5 is real. If your work lives in heavy CLI scripting, devops automation, or shell-first agents, test both models before committing. For everything else — coding, analysis, computer use, knowledge work — Opus 4.8 leads.

One transparency note from Anthropic worth knowing: the OSWorld-Verified harness was updated between 4.7 and 4.8 evaluations. Part of the 4.7-to-4.8 improvement on that benchmark reflects methodology cleanup, not pure capability gain. Anthropic flagged this in the footnotes. Read the +0.6 point delta as “near ceiling on both,” not as a meaningful jump.

Section 13

The Architect's 4.8 Practice (Migration from 4.7)

If you were running Opus 4.7 yesterday, here's the migration plan for moving your daily practice to 4.8. The model ID swap is a one-line change. The habits that get the most value out of 4.8 are the part worth investing in.

What changes immediately, no work required

Better output at the same cost. Set model: "claude-opus-4-8" (or rely on the opus alias, which now routes to 4.8) and you get measurable quality improvements at the same token spend. Your existing prompts and tool schemas continue to work.

Honesty improvements show up everywhere. The 4× reduction in missed code flaws and the 0% flawed-data misreporting apply to every workflow, not just new ones. The first week of using 4.8 on your existing prompts is usually a steady stream of “oh, the model flagged that, 4.7 never would have.”

Default effort is now High, was xhigh. In Claude Code, the default effort changed. If you relied on the old xhigh default, you'll want to set it explicitly: /effort xhigh. Otherwise the model is now using less compute by default than before.

What changes that requires habit shifts

Pick the effort level deliberately. The single biggest behavior change. The new five-level slider in claude.ai and Cowork is wasted if you leave it at the default for every task. Build the habit of choosing per task. Within a week you'll spend less on routine work and more on hard work, and quality goes up everywhere.

Use the 5-block intent template. Detailed plans win on 4.8 even more than they did on 4.7. The model attends more carefully to constraints and gates than its predecessor. The class signature recipe in Section 10 is the highest-leverage habit in this masterclass.

Trust the model's “I'm not sure” more. Opus 4.8 hedges more accurately. When it says it doesn't know something, believe it. When it pushes back on a plan, take the pushback seriously — that's the new behavior the alignment team measured. Earlier models hedged for politeness; 4.8 hedges for accuracy.

What changes that requires API changes

Manual budget_tokens is gone on 4.8. If you carried over thinking: {type: "enabled", budget_tokens: N} from 4.6 or 4.7, switch to adaptive thinking plus the effort parameter: thinking: {type: "adaptive"} with effort: "xhigh" (or whichever level fits). Passing budget_tokens to 4.8 returns a 400 error.

The cacheable prompt minimum dropped to 1,024 tokens. Workloads with short system prompts can now create cache entries without changes. If you previously avoided prompt caching because of the 4,096-token minimum, revisit it.

Mid-conversation system messages are now supported. The Messages API now accepts role: "system" entries inside the messages array without breaking the prompt cache. Use this to update permissions, token budgets, or environment context as an agent runs.

When to use Sonnet instead of Opus 4.8

The simple rule: Sonnet for most normal tasks, Opus 4.8 for work that's difficult, expensive to get wrong, or spread across many steps. If you would not delegate the task to a junior engineer because the cost of a wrong answer is high, use Opus. If you would, Sonnet is faster and cheaper. Opus 4.8's honesty improvements make it especially worth the premium for high-stakes work where catching its own mistakes matters more than raw speed.

Section 14

What's Next: Mythos Preview

Anthropic teased it in the Opus 4.8 announcement: a new class of model with even higher intelligence than Opus, coming to all customers in the weeks ahead. The model is Claude Mythos Preview, and it's already running — just not for you yet.

What we know

Mythos Preview is currently restricted to a small set of organizations under Project Glasswing, Anthropic's cybersecurity research initiative. The reported result from one month of Glasswing partner usage: Mythos identified over 10,000 critical software vulnerabilities in production codebases. That's the kind of capability that requires careful safeguards before general release.

Anthropic's own framing in the Opus 4.8 announcement: “Models of this capability level require stronger cyber safeguards before they can be generally released. We're making swift progress on developing these safeguards and expect to be able to bring Mythos-class models to all our customers in the coming weeks.”

Why Opus 4.8 matters for what comes after

Opus 4.8's alignment improvements close most of the gap between 4.7 and the restricted Mythos baseline. Read between the lines: every honesty and alignment improvement in 4.8 is Anthropic stress-testing the safety properties it needs in production before releasing a model that can autonomously find and exploit vulnerabilities at scale.

The practical implication for vibe coders is that the workflows you build on 4.8 today — the prompt habits, the effort-level discipline, the use of Dynamic Workflows for codebase-scale work — transfer directly to Mythos when it lands. You're not learning a model. You're learning a way of working with a class of model that's about to get more capable.

What to do now

Use Opus 4.8. Build the habits. Run Dynamic Workflows on real work. Develop your own prompt library on top of the 5-block recipe. When Mythos ships, you'll be ready — and the workflows you've been running will scale up rather than needing to be rebuilt.

FAQ

Frequently Asked Questions