Skaleringsstrategi

Faseinndelt skaleringsplan fra lansering til millioner av brukere. Dekker bade kostnadsskalering (AI-forbruk) og kapasitetsskalering (rate limits, samtidighet, infrastruktur).

Grunnleggende antakelser

Parameter	Verdi	Kilde
Impulser per bruker per maned	3.5 (snitt)	Estimat — valideres mot telemetri
Sonnet-kall per impuls	5 steg	Fem isolerte steg, arkitekturbeslutning
Haiku-kall per impuls	~2	Klassifisering + moderasjon
Input tokens per Sonnet-steg	~2 000	Estimat — valideres mot telemetri
Output tokens per Sonnet-steg	~800	Estimat — valideres mot telemetri
Sesjon-varighet (5 steg)	~20 sek	3-5 sek per steg
Cache hit-rate (malt)	~50%	Verifisert i produksjon
Peak-fordeling	60% i 4 peak-timer/dag	Check-in-monster (morgen + kveld)
Latency-budsjett per steg	2-5 sek	Akseptabelt per produktspesifikasjon

Modellvalg

Bruksomrade	Modell	Begrunnelse
Fem-stegs impuls-prosessering	Claude Sonnet 4.6	Balansert kvalitet/kost, 1M context
Klassifisering og moderasjon	Claude Haiku 4.5	Separat rate limit-pool, ~5x billigere input

API-lag er implementert via Vercel AI SDK med generateObject() og Zod-schemas. Modell-agnostisk routing er en konfigurasjonsendring, ikke rewrite.

Flaskehals-analyse

To uavhengige begrensninger ved Anthropic API:

Spend limits (manedstak): Hardt tak pa totalforbruk per kalendermaned.

Rate limits (per minutt): Tre samtidige begrensninger per modell — RPM, ITPM, OTPM.

Rate limit-tall pa Tier 4

Modell	RPM	ITPM	OTPM
Sonnet 4.6	4 000	2 000 000	400 000
Haiku 4.5	4 000	4 000 000	800 000

Hvilken begrensning er bindende?

For Impulse AI-profilen ved peak-kapasitet (100 impulser/min):

• RPM: 500/4 000 (12.5% utnyttelse)
• ITPM: 500 000/2 000 000 (25% utnyttelse)
• OTPM: 400 000/400 000 (100% utnyttelse)

OTPM er den harde flaskehalsen. Cache reduserer ikke output-forbruk.

Fase 1 — Lansering til 10 000 brukere

Status: Aktiv (april 2026)

Peak-utnyttelse ved 10K: ~4% av OTPM, ~1.5% av ITPM, ~4% av RPM

Handlinger:

1. Deposit $400 for umiddelbar Tier 4-aktivering
2. Customer-set spend limit til sikkerhetsniva (f.eks. $10 000/mnd)
3. Retry-logikk med exponential backoff pa 429-feil (implementert i BullMQ)
4. Logg anthropic-ratelimit-*-headers per response
5. Verifiser cache hit-rate per steg
6. Alarm ved 70% OTPM-utnyttelse i peak-time

Manedlig kost ved 10K brukere: ~$2 680

Infrastruktur (implementert)

Komponent	Oppsett	Skaleringsgrep
Railway API	api (web) + api-worker (worker)	Replicas via dashboard
BullMQ concurrency	Multiplier = 2-3 (env var)	Bump uten deploy
Cron locks	withCronLock() pa alle 6 crons	Klar for multi-replica
SSE bridge	job.updateProgress() via Redis Streams	Cross-process
Service config	Deklarativ service-config.ts	Ny mode = 1 linje

Fase 2 — Vekst til 100 000 brukere

Utloser: 50 000 betalende brukere, eller >40% OTPM-utnyttelse i peak

Handlinger:

1. Dialog med sales@anthropic.com ved 50 000 brukere
2. Forbered forhandlingsdata: faktisk forbruk, cache hit-rate, peak-profil, vekstprognose
3. Forhandle Custom tier: hoyere RPM/ITPM/OTPM (2-3x Tier 4), Monthly Invoicing, volum-rabatt (10-20%)

Infrastruktur:

• Bump QUEUE_CONCURRENCY_MULTIPLIER til 3-5
• Legg til web-replicas ved behov (stateless, Railway scale)
• Legg til worker-replicas (BullMQ distribuerer, cron locks forhindrer duplikater)

Manedlig kost ved 100K brukere: ~$27 000 (for rabatt)

Fase 3 — Skalering til 500 000 brukere

Utloser: Peak OTPM over 60%, eller vekstrate som prognostiserer kapasitetsbrudd innen 3 maneder

Spor A: Hybrid modell-routing

Evaluer hvilke steg som kan handteres av Haiku uten kvalitetstap:

1. Bygg eval-rammeverk (Sonnet vs Haiku per steg)
2. A/B-test i produksjon pa 5% av trafikken
3. Gradvis migrasjon ved akseptabel kvalitet

Kapasitetsgevinst: ~1.7x (Haiku OTPM er separat 800K-pool)

Spor B: Multi-provider redundans

Routing-lag mellom Anthropic 1P, AWS Bedrock og Google Vertex AI:

1. Primaer: Anthropic 1P (raskest, billigst)
2. Sekundaer: AWS Bedrock (spillover ved 80% rate limit)
3. Tertiaer: Google Vertex AI (siste fallback)

Kapasitetsgevinst: ~2x (parallelle rate limit-pooler)

Manedlig kost ved 500K brukere: ~$135 000 (for rabatt)

Fase 4 — Millioner av brukere

Utloser: 500K+ brukere med vedvarende vekst

Handlinger:

1. Priority Tier — committed monthly spend mot garantert kapasitet
2. Asynkron ko-arkitektur — peak-utjevning, 100% rate limit-utnyttelse (vs 60-70% ved synkron)
3. Dedicated capacity — bespoke losninger ved 2M+ brukere

Samlet multiplikator pa Tier 4 baseline:

Custom tier (2.5x) x Hybrid routing (1.7x) x Multi-provider (2x) x Async (1.5x) = ~12x

Praktisk kapasitet: 4-5M betalende brukere for ny forhandling kreves.

Kostprognoser

Basert pa $0.27 per betalende bruker per maned (verifisert). Ingen volum-rabatt inkludert.

Brukere	Manedlig AI-kost	Arlig	Fase
10 000	$2 680	$32 160	Fase 1
50 000	$13 500	$162 000	Fase 1/2
100 000	$27 000	$324 000	Fase 2
500 000	$135 000	$1 620 000	Fase 3
1 000 000	$270 000	$3 240 000	Fase 4
5 000 000	$1 350 000	$16 200 000	Fase 4

Ved 20% volum-rabatt (realistisk ved 1M+) reduseres kostnaden tilsvarende.

Monitorering og alarmer

Metrikker per forespørsel

• Modell brukt, input/output tokens, cache read/creation tokens
• Latency (ms)
• anthropic-ratelimit-*-headers (requests, input-tokens, output-tokens remaining)
• 429-feilrate (per time, per modell)

Alarmer

Terskel	Handling
Manedlig forbruk > 70% av spend limit	Varsel til operasjonsteam
Peak OTPM > 60%	Vurder fase 2-overgang
Peak OTPM > 80%	Aktiver fase 2-planer umiddelbart
Cache hit-rate < 40% (3 dager)	Undersoek cache-implementasjon
429-feilrate > 0	Kritisk varsel
Per-bruker-kost > $0.40/mnd	Kostoptimalisering pakrevd

Arkitektoniske beslutninger

Modell-agnostisk API-lag (gjennomfort)

Vercel AI SDK gir ferdig abstraksjon. Modell-valg er konfigurerbart per kall. Hybrid routing i fase 3 blir en konfigurasjonsoppdatering.

Provider-agnostisk klient (fase 3)

Vercel AI SDK stotter flere providers via samme interface. Oppgrader SDK-konfigurasjon for fallback-routing. Ingen rewrite.

Synkron vs asynkron (fase 4)

Async ko-arkitektur gir kapasitetsgevinst forst nar peak-utnyttelse naermer seg 70%. Synkron er enklere a bygge, debugge og overvake. Ikke migrer for tidlig.

Risikoer

Risiko	Sannsynlighet	Mitigering
Viral spike overstiger rate limits	Medium	Retry-logikk + ko-buffer
Anthropic-nedetid	Lav	Multi-provider fallback (fase 3+)
Cache-regresjon dobler kost	Medium	Alarm ved hit-rate < 40%
Cost runaway fra bug/misbruk	Lav	Spend limit + per-bruker quotas

Kontaktpunkter

• Anthropic sales (fase 2+): sales@anthropic.com
• Console (limits): console.anthropic.com/settings/limits
• Usage dashboard: console.anthropic.com/usage