Shipping: cost, latency, and reliability

A prototype has to work once; production has to work at p99, under load, at a price that survives contact with the finance team, without leaking data or obeying a hostile document. The good news: everything in this final lesson is an application of tools you already hold. This is the assembly manual — the levers in the order they pay, and the checklist to run before real users arrive.

Cost: pull the levers in this order

1. Cache the prefix. The caching lesson's discipline — frozen system prompt, stable tools, marker at the boundary — is worth more than every other optimisation combined on context-heavy workloads. Verify with cache_read_input_tokens, not with faith.

2. Right-size the model per route. Your evaluation suite tells you where Sonnet or Haiku holds quality; adjacent tiers differ roughly 2× in price. A router pattern — Haiku classifies the request, then dispatches to the cheapest capable model — is often a lunch-break implementation with a 60% bill reduction.

3. Batch everything that can wait. The Message Batches API runs asynchronous workloads at half price — nightly enrichment, backfills, evaluation runs, bulk classification. Submit up to 100,000 requests, poll, collect results within hours. If a human is not waiting on the response, it belongs in a batch.

4. Control output length. Output tokens cost ~5× input. Concise-output instructions, structured outputs instead of prose, and per-route effort tuning all trim the expensive side of the meter.

Latency: what users actually feel

Users feel time to first token, and you already own the three levers that move it: stream everything user-facing (the first token arrives in moments even when the full answer takes thirty seconds); cached prefixes process faster as well as cheaper — one more return on the same discipline; and smaller models start faster, which is one reason the router pattern helps latency, not just cost. For multi-step flows, look for parallelism you are leaving on the table — independent calls should be concurrent, and Claude's parallel tool calls (returned together, as the tools lesson insisted) already batch what naive loops serialize.

Reliability: assume every failure will happen

The SDK retries transient failures — 429s, 5xxs, dropped connections — with exponential backoff out of the box; your job is the layer above. Respect retry-after on rate limits and know your tier's requests-per-minute and tokens-per-minute ceilings before launch day discovers them for you. Branch on stop_reason everywhere — max_tokens truncation and refusal are normal states, and each needs a designed path, not a stack trace. Log request_id and usage on every call: the first is your lifeline with support, the second your cost telemetry. And decide your degradation story now — queue, retry with backoff, fall back to a smaller model, or fail honestly — because "the API had a bad minute" is an eventuality, not a hypothesis.

Security: the two rules that cover most of it

Prompt injection: any text your system did not write — user input, retrieved documents, tool results, web pages — may contain adversarial instructions. Layer the defences from the MCP lesson: delimit data as data, instruct the model that retrieved content is never instructions, and — the guarantee that holds even when the first two fail — scope tools so an injected instruction couldn't do damage anyway: least privilege, read-only defaults, human confirmation on anything irreversible. Secrets and data: API keys live in environment or secret managers, never in code or prompts; send the minimum user data the task needs, redacting what the model doesn't require; and remember that conversation history you persist is user data under every regulation that applies to you.

The pre-launch checklist

• Evaluation suite green, wired into CI, seeded with your ugliest real cases.
• Cache hit rate verified in usage on realistic traffic — not assumed.
• Every route on the cheapest model your evals clear; batch-eligible work actually batched.
• stop_reason branches: truncation retried or surfaced, refusals handled honestly, pause_turn resumed.
• Streaming on every user-facing path; timeouts and retries configured; rate-limit headroom checked against expected load.
• Tools least-privileged; irreversible actions gated; injected-instruction damage bounded by design.
• request_id, usage, and tool-call traces logged; cost per route on a dashboard someone looks at.

Where you stand

You came into this course to use Claude well; you leave with the full production loop: choose models by evidence, specify tasks precisely, get guaranteed structure, hand Claude tools safely, make context cheap and delivery instant, ground answers in your data, escalate to agents only when the task earns it, integrate through MCP, drive Claude Code as a daily multiplier, and hold the whole thing to a test suite. The field will keep moving — models will improve, prices will shift, features will land — but every practice here is written against the invariants underneath: specification beats incantation, measurement beats vibes, and the harness you build around a model is what turns capability into a product.