← All sessions, cheat sheets & labs
Project 2 · Week 3 · due Sun Aug 2

Cost & Latency Budget + Failure-Mode Runbook

Ceilings you can defend, a ranked map of how each part fails, and one runbook entry a teammate could follow at 3am. The runbook is finished in Week 5.

What this is

The least glamorous, most career-defining document.

Ops is where LLM features live or die. This artifact puts numbers on your hot path and names how it breaks, ranked by pain. Pairs with Lab 3 if you want to build the wrapper.

💡 In plain English

A budget so you know what "too expensive" means, and a map of what breaks so you are not debugging live for the first time at 3am. Depth beats breadth here: one great runbook entry, not ten vague ones.

Do this, in order

The drill.

  1. 1
    Budget your hot pathFill the ceilings (cost and latency, typical and worst), find the dominant cost, tick the levers you'll switch on.
  2. 2
    Walk the request, list failuresAt every hop, retrieval, model, tool, ask: slow, wrong, or down? One row each: component, failure, blast radius, mitigation.
  3. 3
    Rank by blast radiusSort so the most painful failures sit at the top. A cosmetic glitch and a double-charge are not equal.
  4. 4
    Write one runbook entryTake your worst failure and write symptom → check → act → prevent, executable by someone who didn't build it.

Fill this in

The budget + one runbook entry.

Request
the hot path:
Cost ceiling
typical < $… · worst case < $…
Latency ceiling
p95 < … ms · first token < … ms
Dominant cost + levers
dominated by · levers on: cache / route / right-size / stream / batch
Failure map
ranked rows: component · failure · blast radius · mitigation →
Runbook entry
failure · symptom · check · act · prevent

How it's marked

Actionable vs decorative.

✓ Actionable

  • Ceilings are real numbers, typical and worst case.
  • Failures are ranked by blast radius; each has a specific mitigation.
  • The runbook entry could be executed by someone who didn't build it.

✕ Decorative

  • "Be fast, be reliable" with no ceiling.
  • A flat list where a glitch sits next to a double-charge.
  • A runbook that says "investigate and resolve".

Wrapping up

The budget, the ranked map, one runbook entry.

It is fine, expected even, that the runbook has a single entry, it is a seed you grow in Week 5 from real traces. The map tells Week 5 exactly what to build evals and alerts for.

Deliverable
Budget table + ranked failure map + one runbook entry. Due Sun Aug 2.
submit on Maven
Stuck?
Use the S5 cheat sheet pricing table to price your worst-case request. A defensible estimate beats a blank.
rewatch S5 + S6
For the instructorHow to teach thisclick to open ▾

The ranking is where the value is, sorting by blast radius tells them what to fix first and what to ignore. And the runbook bar is concrete: a teammate who didn't build the system could follow it at 3am. If they couldn't, it isn't done.

Reassure them a single runbook entry is the goal, not a coverage sprint. Depth over breadth. The prevent line is what turns an incident into a permanent fix, and it is the one people skip.