Build a router that survives lineup changes and capacity hiccups.
1. Read the current models overview. Start from the models overview page, not your memory: it lists the current lineup, which model to default to, and which one is for demanding reasoning and long-horizon agentic work. All current models support text and image input, text output, and tool use, so route on capability needs (context window, reasoning depth, cost) rather than feature support.
2. Token-count before routing. Call the token counting endpoint on the request first. Use the count to pick the smallest model whose context window fits the input plus your output budget, and to estimate cost. Send images and PDFs as base64 for counting; url and file sources are rejected.
3. Define the fallback chain explicitly. Order: primary model, then a cheaper or faster model for retry, then a degraded mode (cached answer, queue for later, or a clear error). Never fall back silently to a weaker model on quality-critical tasks without logging it: silent downgrades are how quality rots.
4. Handle 429s and overloads, not just errors. On rate_limit_error, read the retry-after header and the anthropic-ratelimit-requests-remaining and reset headers to decide whether to wait or fail over. Use exponential backoff with jitter for retries; the SDKs retry automatically on some errors, so know which errors yours retries and which it does not.
5. Know your tier. Start, Build, and Scale tiers carry monthly spend caps; when usage is paused, requests return 429 with no retry-after and retries fail until access resumes. A fallback chain cannot fix a paused org: surface that state to the user instead of looping.
6. Re-run evals on every routing change. Changing the model for a task class is a behavior change. Run your eval suite with-arm (new routing) and without-arm (old routing) before rolling out, and watch the quality-sensitive criteria, not just the average.