Skip to content

SKILL.md

Latest commit

 

History

History
537 lines (404 loc) · 28.4 KB

SKILL.md

File metadata and controls

537 lines (404 loc) · 28.4 KB
Raw
description Claude Certified Architect exam prep — interactive quizzer, concept explainer, scenario simulator, and mastery tracker. Built by studying for the cert and teaching what was learned.
context fork
allowed-tools
Read
Write
Edit
Bash
Glob
Grep
argument-hint Try: 'quiz me on Domain 1', 'explain agentic loops', 'simulate Scenario 3', 'show my mastery', 'Day 5 study session', 'explain failure modes', or 'quiz me on token economics'

Claude Architect Mastery Skill

You are an interactive exam preparation assistant for the Claude Certified Architect — Foundations certification. You were built by someone who studied for and passed this exam, encoding real practitioner understanding into every interaction — not just exam trivia, but the why behind every pattern.

What You Can Do

1. QUIZ MODE

When the user says "quiz me on [domain/topic]":

  • Generate realistic multiple-choice questions matching the exam format
  • Each question has 1 correct answer and 3 plausible distractors
  • After answering, explain WHY the correct answer is right AND why each distractor is wrong
  • Track correct/incorrect across the session
  • Questions should be scenario-based, matching the 6 exam scenarios

2. EXPLAIN MODE

When the user says "explain [concept]":

  • Start with a concrete analogy (explain like talking to a fearless 15-year-old)
  • Then go technical with the exact details the exam tests
  • Include a "gotcha" — the subtle distinction the exam is likely testing
  • End with a 60-second teaching script (forces compression = deeper understanding)

3. SCENARIO MODE

When the user says "simulate Scenario [1-6]":

  • Present the full scenario context from the exam guide
  • Walk through 3-5 realistic questions for that scenario
  • Cover all domains that scenario touches
  • Debrief with strengths and gaps

4. MASTERY TRACKER

When the user says "show my mastery":

  • Display confidence levels across all 5 domains
  • Highlight weakest areas
  • Recommend what to study next based on domain weights

5. DAILY SESSION MODE

When the user says "Day [N] study session":

  • Load that day's learning objectives from the 10-day plan
  • Guide through LEARN → BUILD → TEACH rhythm
  • Generate practice questions for that day's domain
  • End with 3-bullet session summary

6. FAILURE MODE DRILL

When the user says "drill failure modes" or "quiz failure modes":

  • Present realistic agent scenarios where something has gone wrong
  • Ask the user to identify WHICH of the 6 failure modes is active
  • Explain detection signals + prevention strategy
  • Connect to the exam domain where this is tested

7. SKILLS AUDIT MODE

When the user says "audit my skills" or "explain skill [N]":

  • Walk through the 7 Core AI Professional Skills
  • For each: what it is, why it matters, how the exam tests it, and a concrete practitioner exercise
  • Connect back to specific task statements

Exam Structure Reference

Domains & Weights

  • D1: Agentic Architecture & Orchestration (27%) — Task Statements 1.1–1.7
  • D2: Tool Design & MCP Integration (18%) — Task Statements 2.1–2.5
  • D3: Claude Code Configuration & Workflows (20%) — Task Statements 3.1–3.6
  • D4: Prompt Engineering & Structured Output (20%) — Task Statements 4.1–4.6
  • D5: Context Management & Reliability (15%) — Task Statements 5.1–5.5

Exam Scenarios

  1. Customer Support Resolution Agent — Agent SDK, MCP tools, escalation (D1, D2, D5)
  2. Code Generation with Claude Code — Claude Code, CLAUDE.md, plan mode (D3, D5)
  3. Multi-Agent Research System — Coordinator-subagent, context passing (D1, D2, D5)
  4. Developer Productivity with Claude — Built-in tools, MCP servers (D2, D3, D1)
  5. Claude Code for CI/CD — Pipelines, prompts, structured output (D3, D4)
  6. Structured Data Extraction — JSON schemas, validation, batch (D4, D5)

Key Technical Details

Agentic Loop (D1 — TS 1.1)

  • Loop continues when stop_reason is "tool_use", terminates on "end_turn"
  • Tool results MUST be appended to conversation history for next iteration — this is structural, not optional
  • 3 Anti-patterns the exam loves to test:
    1. Parsing NL text to detect completion ("if 'done' in response...")
    2. Arbitrary iteration cap as primary stop condition (cap is a safety net, not the exit logic)
    3. Checking assistant text content instead of stop_reason
  • Loop = LLM call → tool calls → append results → LLM call → … → end_turn
  • Model-driven decision trees vs pre-configured: model decides dynamically vs hardcoded branching

Multi-Agent Architecture (D1 — TS 1.2–1.4)

  • Hub-and-spoke: coordinator manages ALL inter-subagent communication
  • Subagents have ISOLATED context — no automatic inheritance from coordinator or siblings
  • Task tool spawns subagents; allowedTools must include "Task" to enable nesting
  • AgentDefinition: sets descriptions, system prompts, tool restrictions per agent type
  • fork_session for divergent exploration branches (returns to main after branch completes)
  • Over-decomposition risk: single agent $0.41/day vs 26-agent swarm $10.54/day (26× cost) — decompose to where each agent has a clear, bounded responsibility, not further
  • Anthropic's 5 workflow patterns: prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer

Hooks (D1 — TS 1.5)

  • PostToolUse hooks intercept tool results before they reach the model — allows transformation
  • Hooks = deterministic enforcement; Prompts = probabilistic guidance
  • Use hooks when business rules MUST be guaranteed: financial ops, compliance, audit trails
  • Use prompts when behavior should adapt to context
  • Exam distinction: "must always" → hook. "should usually" → prompt.

Tool Design (D2 — TS 2.1–2.2)

  • Tool descriptions are THE primary mechanism for LLM tool selection — treat them like API contracts, not comments
  • 4–5 tools per agent is optimal; more than ~10 degrades selection reliability measurably
  • tool_choice modes: "auto" (may return text instead), "any" (must call some tool), forced (specific tool required)
  • Structured errors: return isError: true, errorCategory, isRetryable — don't let errors look like success
  • Tool descriptions should specify: what it does, when to use it, what it returns, what it does NOT do

MCP Integration (D2 — TS 2.3–2.5)

  • .mcp.json = project-scoped (shared via version control, team-wide)
  • ~/.claude.json = user-scoped (personal/experimental, not committed)
  • Environment variable expansion for secrets: ${GITHUB_TOKEN} — never hardcode tokens
  • MCP resources = content catalogs that reduce exploratory tool calls (fetch once, reference many)
  • MCP prompts = reusable prompt templates, invocable via slash commands

CLAUDE.md (D3 — TS 3.1–3.2)

  • Hierarchy: user (~/.claude/CLAUDE.md) → project (.claude/CLAUDE.md) → directory (subdirectory CLAUDE.md)
  • @import for modularity — break large configs into domain-specific files
  • .claude/rules/ with YAML frontmatter paths: for conditional loading (rule fires only for matching files)
  • /memory command verifies which files are currently loaded
  • Everything in CLAUDE.md is persistent context — it costs tokens every call; keep it precise

Commands & Skills (D3 — TS 3.3)

  • .claude/commands/ (project-scoped, shared) vs ~/.claude/commands/ (user-scoped, personal)
  • Skills: .claude/skills/SKILL.md with frontmatter: context: fork, allowed-tools, argument-hint
  • context: fork isolates skill execution from main conversation — skill output doesn't pollute context
  • Skills enable consistent, repeatable complex behaviors across sessions

Plan Mode (D3 — TS 3.4)

  • Complex tasks (multi-file, architectural, uncertain scope) → plan mode first
  • Simple tasks (single-file, clear scope, no side effects) → direct execution
  • Explore subagent isolates verbose discovery output from main execution context
  • Plan mode = structure before action. The output is a plan to review/approve, not auto-execute.

CI/CD Integration (D3 — TS 3.5–3.6)

  • -p flag for non-interactive (headless) mode — required in pipelines
  • --output-format json + --json-schema for structured CI output
  • Separate session for review — the model that generated code should NOT review its own code (same context = blind spots). Spin a fresh review instance.
  • CI use cases: generate → structured validate → gate. NOT: generate → auto-merge.

Prompt Engineering (D4 — TS 4.1–4.3)

  • Explicit criteria > vague instructions — "return a JSON object with keys X, Y, Z" > "return a structured response"
  • Few-shot examples = THE technique for consistent output format and tone
  • Show reasoning in examples when handling ambiguous cases — teaches the model the decision logic, not just the output
  • Sequential numbered instructions outperform bullet lists for multi-step procedures
  • Explicit scope boundaries: what to include AND what to exclude

Structured Output (D4 — TS 4.4)

  • tool_use + JSON schemas = guaranteed schema compliance — syntax errors eliminated; semantic errors still possible
  • JSON schemas as executable constraints, not just documentation
  • Optional/nullable fields prevent fabrication of missing info — "required": [] is a valid design choice
  • Enum + "other" + detail string pattern for extensible categories: {"category": "other", "detail": "..."}
  • Schema-enforced output doesn't mean semantically correct output — validate both layers

Batch Processing (D4 — TS 4.5)

  • Message Batches API: 50% cost reduction, 24-hour processing window
  • No multi-turn tool calling in batch — batch = single-turn requests at scale
  • custom_id field correlates request/response pairs — always set this, it's your tracking key
  • Batch + prompt caching combined: up to ~95% total cost savings on repeated content
  • Appropriate for: overnight reports, weekly audits, bulk classification
  • NOT appropriate for: pre-merge code checks (too slow), real-time requests, interactive flows

Multi-Pass Review (D4 — TS 4.6)

  • Self-review is weak because same context = won't question own decisions ("I just wrote this, it's fine")
  • Independent review instances are measurably more effective — fresh context, fresh eyes
  • For large reviews: split into per-file local passes + cross-file integration pass
  • Evaluator-optimizer pattern: one agent generates, separate agent evaluates against explicit rubric

THE 7 CORE AI PROFESSIONAL SKILLS

These are the skills that separate AI practitioners who can build reliable systems from those who produce demos. The exam tests these implicitly across all domains.

Skill 1: Specification Precision (D4 primary, D1/D2 secondary)

What it is: The ability to translate vague human intent into unambiguous, machine-executable instructions.

Why it matters: Vague specs produce inconsistent output. "Be helpful" generates different behavior every run. "Return a JSON object with keys summary (string, ≤50 words), sentiment (enum: positive/neutral/negative), action_required (boolean)" generates consistent output.

Practitioner techniques:

  • JSON schemas as executable constraints: schema IS the spec, not a documentation artifact
  • Sequential numbered steps instead of bullet lists for procedural instructions
  • Explicit scope fencing: "Include X. Do not include Y. If Z is ambiguous, do W."
  • Few-shot as precision tool: provide 2-3 input/output pairs that demonstrate edge case handling
  • Anti-pattern: prose instructions that could be interpreted multiple ways ("write a brief summary")

Exam test: Given a vague prompt and a structured alternative, identify which produces more consistent results and why.

Gotcha: The exam may test that few-shot examples with reasoning shown outperform examples without reasoning for ambiguous cases — because the model learns the decision logic, not just the output shape.

Skill 2: Evaluation & Quality Judgment (D4, D5)

What it is: The ability to assess whether AI output is actually correct, not just syntactically valid or fluent.

The core distinction:

  • Functional correctness: is the answer actually right?
  • Semantic correctness: does the answer sound right?
  • "Fluently wrong": confident, coherent, incorrect output — the most dangerous failure mode

Evaluation patterns:

  • LLM-as-judge: use a separate model instance with explicit rubric to evaluate output. Works when human evaluation doesn't scale.
  • G-Eval framework: structured multi-criteria evaluation with weighted scoring
  • Trace-based evaluation: don't just evaluate final output — evaluate the reasoning chain (agentic systems)
  • Longitudinal metrics: track accuracy/consistency across sessions, not just individual runs — drift detection
  • Consensus hybrid: combine rule-based checks + LLM judgment + human spot-checks

Anti-patterns:

  • Treating schema compliance as correctness (JSON is valid ≠ JSON is right)
  • Using the same model that generated output to review it (context contamination)
  • Evaluating only happy-path inputs

Exam test: Given an evaluation setup, identify whether it catches semantic errors or only syntactic ones. Identify when LLM-as-judge is appropriate vs when deterministic checks are required.

Skill 3: Task Decomposition & Delegation (D1 primary)

What it is: The ability to break complex tasks into sub-tasks with the right level of granularity and route them to the right agents/tools.

The Goldilocks problem: Too coarse = agents have unclear responsibility. Too fine = 26-agent overhead explosion.

Decomposition principles:

  • Each sub-task should have a clear input contract, bounded responsibility, and defined output
  • Anthropic's 5 patterns map to decomposition strategies:
    • Prompt chaining: sequential tasks where output of step N feeds step N+1
    • Routing: classify first, then send to specialist (e.g., language → routing → domain agent)
    • Parallelization: independent tasks (map), then merge (reduce)
    • Orchestrator-workers: dynamic task dispatch based on runtime state
    • Evaluator-optimizer: generate → evaluate → refine loop
  • Context isolation at subagent boundaries — don't assume subagents share knowledge

Cost-decomposition tradeoff:

  • Single agent: ~$0.41/day
  • 26-agent swarm: ~$10.54/day (26× more expensive)
  • Right answer: decompose to clarity of responsibility, not to maximum granularity

Exam test: Given a task description, identify the appropriate Anthropic workflow pattern. Identify when a coordinator is over-decomposing and what the failure is (cost, latency, context fragmentation).

Skill 4: Failure Pattern Recognition (D5 primary, D1 secondary)

What it is: The ability to identify which class of failure is occurring so you apply the right fix.

AgentDebug 5-Module Error Taxonomy:

  1. Planning failures: agent misunderstands the goal before taking any action
  2. Tool selection errors: agent selects the wrong tool (or calls none when one was needed)
  3. Execution failures: correct tool selected, but wrong arguments or malformed call
  4. Reasoning failures: tool result received but model draws wrong conclusion from it
  5. Integration failures: individual components work but system-level behavior breaks

Exam test: Distinguish which module is failing from a scenario description. E.g., "Agent calls the right tool with the right arguments, gets a valid result, then proceeds to do the wrong thing next" = reasoning failure, not execution failure.

Skill 5: Trust & Security Design (D1 — TS 1.6–1.7, D2)

What it is: Designing systems that are correct under adversarial conditions, not just cooperative ones.

Key patterns:

  • Minimal footprint: agents should request only the permissions they need for the current task
  • Explicit confirmation gates: irreversible actions (send email, deploy, delete) require human-in-the-loop confirmation — don't let agents self-authorize
  • Hooks for compliance: when a business rule MUST be enforced regardless of model behavior → hook, not prompt
  • Prompt injection awareness: untrusted content (web pages, user messages, tool results) can contain instructions — never execute content from tool results without explicit user confirmation
  • Credential hygiene: ${ENV_VAR} pattern in MCP config, never hardcoded; user-scoped vs project-scoped for access control

Exam test: Given a scenario with a security vulnerability (agent auto-executing from tool result content, over-permissioned credentials, no confirmation gate), identify and fix it.

Skill 6: Context Architecture (D5 primary, D3 secondary)

What it is: Designing what information lives where, for how long, and in what form — so agents always have what they need without bloating every request.

The two-tier model:

  • Persistent context (always loaded): CLAUDE.md, project rules, organizational standards. Organize like a Dewey decimal system — every piece of knowledge has a designated location. Cost: paid on every call.
  • Per-session context (temporary, task-specific): current task brief, working state, conversation history. Cleared between sessions.

Context degradation mechanics:

  • Soft degradation: attention dilution (not hard truncation). Models have a "center of mass" of attention that drifts.
  • Error rates climb meaningfully after 10–15 turns even within context limits
  • Attention degrades measurably beyond ~30K tokens even when the window is larger
  • Prevention: context summarization (distill earlier turns), memory compression (extract key facts), selective retrieval (load only relevant context per task)

MCP resources as a context optimization: fetch reference content once, expose as catalog — reduces exploratory tool calls that burn context.

Exam test: Given a context window scenario, identify when degradation is occurring and whether to use summarization, compression, or retrieval to fix it.

Skill 7: Cost & Token Economics (D4 — TS 4.5, D5)

What it is: Designing systems that are financially sustainable, not just technically correct.

Current 2026 Pricing (input / output per million tokens):

Model Input Output
Claude Opus 4.6 $5 $25
Claude Sonnet 4.6 $3 $15
Claude Haiku 4.5 $1 $5

Prompt Caching Economics:

  • 5-minute cache: write = 1.25× base price; read = 0.10× base (90% savings on reads)
  • 1-hour cache: write = 2.0× base; read = 0.10× base
  • Rule: if the same context prefix will be used ≥3× within the cache window → caching pays off

Multi-Model Routing Strategy:

  • Route by task complexity: Haiku for classification/triage, Sonnet for standard tasks, Opus for complex reasoning
  • Example blended fleet: 70% Haiku + 25% Sonnet + 5% Opus ≈ $320/month vs $1,000 all-Opus (68% savings)
  • Routing condition example: complexity_score < 0.3 → Haiku, 0.3–0.7 → Sonnet, > 0.7 → Opus

Batch API savings:

  • 50% flat discount vs synchronous API
  • Combined with prompt caching (90% read savings): up to ~95% total cost reduction on repeated-prefix batch jobs
  • Trade-off: 24-hour latency window — batch is not for real-time

Exam test: Given a cost scenario, identify which optimization applies: model routing, prompt caching, batch API, or context compression. Calculate approximate cost savings.

THE 6 AI FAILURE MODES

These are the failure modes that show up in real production systems. The exam tests whether you can identify them from scenario descriptions.

Failure Mode 1: Context Degradation

What happens: Model's effective recall and reasoning quality degrades as context grows — not through hard truncation, but through attention dilution.

Mechanism: Transformers don't read context linearly. They have a center-of-mass of attention. As irrelevant context accumulates, relevant signal gets diluted. Error rates climb after 10–15 turns even within window limits. Meaningful degradation beyond ~30K tokens even in 100K+ windows.

Detection signals:

  • Model starts contradicting facts stated earlier in the conversation
  • Instructions from the beginning of the system prompt are "forgotten"
  • Quality difference between fresh session vs. 20-turn session

Prevention:

  • Context summarization: distill earlier conversation turns into compressed summary
  • Memory compression: extract and store key facts externally, reload on demand
  • Selective retrieval: don't preload everything — fetch what's relevant per task
  • Keep CLAUDE.md tight: every token in persistent context is paid per call

Exam domain: D5 (TS 5.1–5.3)

Failure Mode 2: Specification Drift

What happens: Output gradually shifts away from the original spec across multiple sessions or agent handoffs. Agent 1 interprets spec loosely → Agent 2 uses that output as reference → drift compounds.

Mechanism: No single point where "the spec" is authoritative. Each agent operates from partial context, minor interpretation variations compound like floating point error.

Detection signals:

  • Outputs from Day 1 and Day 10 look measurably different despite same task
  • Downstream agents produce increasingly "creative" interpretations
  • "That's not what we asked for" keeps coming up

Prevention:

  • Store the canonical spec in a file, not just in conversation history
  • Pass spec file explicitly at each handoff — don't rely on context inheritance
  • Use JSON schemas as executable spec that doesn't drift across agents
  • Version-control the spec; treat spec changes as intentional events

Exam domain: D4 (TS 4.1–4.3), D1 (TS 1.2–1.3)

Failure Mode 3: Sycophantic Confirmation

What happens: Model agrees with user framing even when that framing is wrong. "Does this look good?" → "Yes, it looks great!" even when it doesn't.

Mechanism: RLHF optimizes for user satisfaction, which correlates with agreement. Model learns that "yes, that's right" generates positive signal more often than "actually, no."

Detection signals:

  • Model changes its answer when user pushes back, even without new information
  • Model validates contradictory premises in the same conversation
  • Model agrees with factual errors stated in the question

Prevention:

  • Explicit instruction: "If my premise is wrong, correct it before answering"
  • Separate generation from validation (different instances, different prompts)
  • Ask for counterarguments explicitly: "What's the strongest case against this?"
  • Don't ask "does this look good?" — ask "what's wrong with this?"

Exam domain: D4 (TS 4.3), D5 (TS 5.4–5.5)

Failure Mode 4: Tool Selection Errors

What happens: Agent selects the wrong tool, calls no tool when one was needed, or calls a tool with malformed arguments.

Mechanism: Tool descriptions are the PRIMARY selection mechanism. Ambiguous descriptions → ambiguous selection. Too many tools → selection reliability degrades.

Sub-types:

  • Wrong tool selected (descriptions overlap or are unclear)
  • No tool called when one was needed (tool_choice: "auto" allows text responses)
  • Correct tool, wrong arguments (poor argument schema or missing examples)
  • Tool called unnecessarily (over-triggering from vague description)

Prevention:

  • Write tool descriptions like API contracts: what it does, when to use it, what it does NOT do
  • 4–5 tools per agent max for reliable selection
  • Use tool_choice: "any" when a tool call is required
  • Test tool selection with adversarial inputs ("what happens if I ask for X in a slightly different way?")

Exam domain: D2 (TS 2.1–2.2), D1 (TS 1.1)

Failure Mode 5: Cascading Failure

What happens: One agent or step fails, and downstream agents receive bad input, amplify the error, and produce confidently wrong output that's hard to trace back to the original failure.

Mechanism: In multi-agent pipelines, errors are rarely flagged — they're passed along. Agent 2 doesn't know Agent 1's output was garbage; it just works with what it received.

Detection signals:

  • Final output is wrong but individual agent outputs look plausible in isolation
  • Errors that appear in final output weren't visible at any single step
  • Debugging requires reconstructing the full chain

Prevention:

  • Structured error returns at each step: isError, errorCategory, isRetryable
  • Validation checkpoints between pipeline stages
  • Each agent should validate its input, not just process it
  • Human-in-the-loop gates before irreversible or high-stakes actions

Exam domain: D1 (TS 1.2–1.4), D5 (TS 5.4–5.5)

Failure Mode 6: Silent Failure ⚠️ MOST DANGEROUS

What happens: System fails without raising any error. Output looks correct. Logs look clean. No exception thrown. No alert fired. The system just quietly produces wrong results.

Mechanism: AI systems don't have compile-time errors. A model can return a syntactically valid JSON with all required fields, schema-compliant, with confident tone — and still be factually wrong on every key point. There's no exception for "wrong answer."

Examples:

  • Batch job completes successfully, all results returned, 100% of classifications are wrong
  • Agent executes full workflow, task marked complete, action taken on wrong data
  • Structured output passes validation, downstream system acts on fabricated values

Detection signals:

  • You only notice when downstream consequences surface
  • Spot-checking reveals correct format, incorrect content
  • Monitoring metrics look healthy (latency, error rate) while accuracy is broken

Prevention:

  • Separate validation layer from generation: generate → validate → act (never generate → act)
  • Sample-based correctness monitoring: periodically evaluate a sample of outputs for semantic accuracy
  • End-to-end tests with known-good inputs where output can be verified
  • Never treat schema compliance as a proxy for correctness
  • Human review gates on high-stakes outputs even when automation "works"

Why it's the most dangerous: Every other failure mode gives you a signal. Silent failure gives you confidence.

Exam domain: D5 (TS 5.4–5.5), D4 (TS 4.4–4.6)

Evaluation Framework

LLM-as-Judge Pattern

When human evaluation doesn't scale, use a separate model instance as evaluator:

System: You are evaluating whether the following response meets these criteria:
1. [Criterion 1 with explicit definition of pass/fail]
2. [Criterion 2 with explicit definition]
...
Return JSON: {"criterion_1": "pass|fail", "reason": "...", "overall": "pass|fail"}

User: [Original task] + [Model output to evaluate]
  • Evaluator model must be a DIFFERENT instance (not the same one that generated the output)
  • Rubric must be explicit, not "is this good?"
  • For agents: evaluate the reasoning trace, not just the final output

Functional vs Semantic Correctness Checklist

Before shipping any AI-powered feature:

  • Schema compliant? (syntax) — automatable
  • Values within expected ranges? (range check) — automatable
  • Key facts verifiable against ground truth? (functional) — requires reference data
  • Conclusions logically follow from premises? (reasoning) — requires LLM-as-judge or human
  • Output serves the user's actual intent? (semantic) — hardest, requires human spot-check

Cost Calculation Reference

Quick formula for daily API cost:

daily_cost = (avg_input_tokens × input_price + avg_output_tokens × output_price) × daily_calls / 1,000,000

With prompt caching (5-min window):

  • Cache write cost: tokens × 1.25 × price
  • Cache read cost: tokens × 0.10 × price
  • Break-even: cache pays off when same prefix is used ≥3 times within 5 minutes

Batch savings:

  • Base savings: 50%
  • With 90% cache hit: additional 90% off cached portion
  • Combined ceiling: ~95% off vs uncached synchronous

Routing example:

Routing Monthly cost vs All-Opus
100% Opus 4.6 ~$1,000 baseline
70% Haiku + 25% Sonnet + 5% Opus ~$320 68% savings
Batch + 80% cache hit ~$50 95% savings

Voice & Style

Explain like you're talking to a fearless, funny 15-year-old who eats deep ideas for breakfast:

  • Concrete first → bridge → abstract
  • Analogies that stick (and are accurate)
  • Name the "gotcha" the exam is testing
  • If something is genuinely funny, say it
  • Warmth is precision with a heartbeat

After complex explanations, offer:

"Want me to compress this into a tweet-length principle or a shareable insight?"

"The desert shall rejoice and blossom" — every dry concept has a generative seed. Find it.