Whenever someone tells me "the prototype works, can we ship next week?", I tend to pause and ask three questions: What's your expected user count? What SLA do you owe customers? Where does the data live? It's surprising how rarely all three get an immediate answer.
The Claude API code itself fits in a few dozen lines. But the design decisions around it — the ones you should make before writing more code — will save you weeks of restructuring later. Here's the three-axis framework I keep returning to in my own personal projects and client work for deriving infrastructure requirements.
Step 1: Estimate traffic in three tiers
The first numbers to nail down are peak QPS (queries per second) and monthly token volume. Without these, your organizational rate limits, model choice, and caching strategy all drift.
I like a coarse three-tier breakdown:
- Tier S (~1,000 MAU, ~10 RPM): Personal MVPs and internal tools. Usually fits within the default Tier 1 limits — you can start without special accommodations
- Tier M (1,000–50,000 MAU, ~100 RPM): Public-facing services in early growth. You'll need a Tier 2 upgrade request, prompt caching, and async background jobs
- Tier L (50,000+ MAU, 1,000+ RPM): A single-region, single-model setup no longer holds. Plan for multi-cloud (Bedrock or Vertex AI) and model fallback chains from the start
A rough peak-QPS formula: (expected DAU × requests/user/day) ÷ active seconds per day (I use 36,000 = 10 hours) × peak factor 3. For 10,000 DAU at 3 requests each, that's about 2.5 peak QPS. Convert to monthly volume and you have the input for token cost estimates.
For the deeper sizing math, Claude API Monthly Cost Calculation and Prompt Caching Design Guide covers the model-by-model breakdown.
Step 2: Reverse-engineer availability from your SLA
The gap between 99.5% and 99.95% translates to about 4 hours vs. 22 minutes of monthly downtime. That gap is also the design boundary between "single provider works" and "fallback is mandatory."
My field heuristic:
- 99.5% (≤4 hrs/month): Direct Anthropic API calls + retries + reasonable timeouts is enough. Internal tools and free services typically design to this line
- 99.9% (≤43 min/month): Add prompt caching, response caching, and one fallback path through the same model on a different region (e.g., Bedrock)
- 99.95%+ (≤22 min/month): You need a hierarchical fallback — primary model (Sonnet 4.6) → secondary (Haiku 4.5) → optionally a local inference fallback (Gemma family). Plan to automate SLO reports against this number
One subtle point: distinguish between "Anthropic's API SLA" and "your service's SLA." Unless you've signed Anthropic's Production SLA explicitly, your numbers will always be lower than Claude's. Whatever you promise users should be tracked internally as an SLO, not blindly inherited.
The implementation patterns are detailed in Claude API Multi-Model Fallback for High Availability.
Step 3: Make the data-residency and compliance call
This is where B2B SaaS deployments stumble most often. The moment a client says "the data must stay in our country," direct Anthropic API calls drop off the option list — at the time of writing, the Anthropic API is US-region centric and offers limited residency guarantees.
Three decision points to lock in:
- Will personal data hit Claude? If yes, design PII masking into the request path. Phone numbers, addresses, and card details should be tokenized before they ever reach the API
- Is this a regulated industry (finance, healthcare, government)? If so, evaluate Bedrock (to keep traffic inside AWS) or Vertex AI (to inherit Google Cloud's residency settings) from day one
- Customer data and training: The Claude API doesn't use customer data for training by default, but enterprise clients often ask you to put that in writing. The Enterprise plan includes a DPA (Data Processing Agreement) you can sign
For the masking implementation, see Claude API PII Masking: A Production Design Guide.
A minimum viable cost formula
When someone asks "How much will this cost?", I start with this formula and refine from there:
// Estimated monthly cost in USD
function estimateMonthlyCost({
dau, // expected daily active users
requestsPerUser, // requests per user per day
inputTokensAvg, // average input tokens per request
outputTokensAvg, // average output tokens per request
inputPricePerMTok, // input price per M tokens (Sonnet 4.6 = 3.0)
outputPricePerMTok, // output price per M tokens (Sonnet 4.6 = 15.0)
cacheHitRate = 0.5, // prompt cache hit rate after rollout
safetyFactor = 1.3 // buffer for retries, bursts, internal usage
}) {
const monthlyRequests = dau * requestsPerUser * 30;
const monthlyInputTok = monthlyRequests * inputTokensAvg / 1_000_000;
const monthlyOutputTok = monthlyRequests * outputTokensAvg / 1_000_000;
// Cache hits cost ~10% of base input price; writes cost 125%
const effectiveInputCost =
monthlyInputTok * inputPricePerMTok *
(cacheHitRate * 0.1 + (1 - cacheHitRate) * 1.0);
const outputCost = monthlyOutputTok * outputPricePerMTok;
return Math.ceil((effectiveInputCost + outputCost) * safetyFactor);
}
// Example: 5,000 DAU at 3 req/day, 2,000 input + 500 output tokens
// → roughly $3,800/month
console.log(estimateMonthlyCost({
dau: 5000, requestsPerUser: 3,
inputTokensAvg: 2000, outputTokensAvg: 500,
inputPricePerMTok: 3.0, outputPricePerMTok: 15.0
}));The non-negotiable part of this formula is the 1.3 safety factor. In practice, retries, internal testing, employee dogfooding, and unexpected bursts inflate the bill 1.2–1.5× over the naive estimate. Budgeting at +30% from day one keeps end-of-month invoices boring.
Pre-launch checklist
After working through the three axes, sort each item below into "decided" or "open." Even one open item is reason enough to delay launch by a week.
- [ ] Peak QPS and monthly token estimates exist on paper
- [ ] Target SLA is defined and a fallback path matches it
- [ ] PII handling policy (masking, what's OK to send) is documented
- [ ] Monthly cost estimate exists with an alert threshold for overruns
- [ ] User-facing fallback UI is designed for rate-limit / outage conditions
- [ ] On-call notification path reaches a human during incidents
- [ ] Data residency requirements (in the contract) match the implementation
I strongly recommend taking these seven items into a one-hour review meeting with everyone involved. That alignment session prevents more production incidents than any amount of clever code.
What to do today
Before closing this tab, run the peak-QPS estimate for your project. It takes five minutes with a calculator. Once you have that number, the tier classification, model choice, and SLA conversation all snap into focus.
If you want to follow up with implementation details, Claude API Production Launch Infrastructure Checklist walks through eight concrete patterns for turning "code that works" into "code that holds in production." Read it together with this one and you'll have both the design decisions and the implementation patterns covered.