Hur vi sänkte AI-driftkostnaden 32% med prompt-caching och Haiku-routing

Tidigt i pilot-fasen mätte jag driftkostnad per säljare och dag. Den var $1.32 — högre än jag räknat med.

På Pro-paketet är det 76% bruttomarginal istället för 81%. Inte katastrof, men inte heller försvarbart över tid.

Två ändringar tog ner kostnaden till $0.90 per säljare och dag. -32%. Inga features försvann. Latens blev marginellt bättre.

Här är vad vi gjorde.

Ändring 1: Anthropic prompt-caching

Claude:s prompt-cache är 90% billigare än att skicka samma kontext upprepade gånger.

I våra edge-functions skickar vi ofta samma system-prompt + deal-kontext + mötes-historik. Anthropic API stödjer en cache_control parameter som säger “lagra dessa tokens i 5 min, returnera cache-hit på återanvändning”.

Före:

const response = await anthropic.messages.create({
  model: "claude-haiku-4-5",
  system: SYSTEM_PROMPT,
  messages: [{ role: "user", content: dealContext + meetingHistory + question }],
});

Efter:

const response = await anthropic.messages.create({
  model: "claude-haiku-4-5",
  system: [
    { type: "text", text: SYSTEM_PROMPT, cache_control: { type: "ephemeral" } },
  ],
  messages: [{ role: "user", content: [
    { type: "text", text: dealContext, cache_control: { type: "ephemeral" } },
    { type: "text", text: meetingHistory + question },
  ]}],
});

System-prompt och deal-kontext cache:as. Bara meetingHistory + question är “färska” tokens.

Resultat: input-tokens blev 88% billigare på cache-hit. På AI-coach (där säljaren skriver 8-15 prompts per sammtalstimme) sänkte det kostnaden 41% bara för den funktionen.

Caveat: cache lever bara 5 min. Vi tappar cache-hit om samtalet pågår 6+ min. För det fallet är cache fortfarande +88% nettovinst på första 4 minuterna.

Ändring 2: Haiku-routing

Vi använde claude-sonnet för allt. Sonnet är 5x dyrare än Haiku.

Det är onödigt för vissa flöden.

parse-deal (“Stefan Thelander AB, AI 25k engång + 2k/mån” → strukturerad data) är ett extraction-jobb. Haiku klarar det med 97% precision på svenska. Bytte till Haiku.

voice-memo → mötesnotat är samma — extraktion av deltagare, talking points, next_steps. Haiku räcker.

AI-coach live krävde Sonnet — vi behöver närvaron av medel-tier reasoning för att föreslå rätt nästa fråga. Behöll Sonnet.

enrich-company med web-search — Sonnet ger märkbart bättre sammanfattning. Behöll Sonnet.

generate-quote för offerter — Sonnet ger bättre prose. Behöll Sonnet.

Resultat: 5 av 12 flöden bytt till Haiku. De stod för 60% av API-anropen men bara 12% av tokenkostnaden. Sänkte total drift 28%.

Vad som INTE funkade

Två saker vi testade som inte gav vinst:

1. Egen lokal LLM (Ollama med Llama 3.1 8B)

Tanken: kör basala extraction-jobb lokalt på Magnus dator. Spara API-kostnad.

Verkligheten: kvalitet på svenska sänktes 18-22%. Ollama drog 4GB RAM permanent. Magnus dator blev seg. Avstod.

2. Batching av flera deal-parse i en API-call

Tanken: ta 5 deals i en prompt istället för 5 anrop. Spara latens + token-overhead.

Verkligheten: kvalitet sänktes — Claude blandade ihop attribut mellan deals. Och latens-vinsten var marginal eftersom vi redan kör parallel. Avstod.

Vad vi gör härnäst

OPTIMIZATION-ROADMAP.md i repot har 3 fler optimeringar:

• Selective web-search — bara kalla enrich-company när deal-värdet >50k SEK (50% av API-cost för enrich-company)
• Embedding-cache — för battlecard-genererings-flödet
• Stale-deal-batching — schedulera 1 anrop/dag istället för on-demand

Totalt estimerar vi -44% till från där vi är nu. Det skulle sätta Pro-paketets bruttomarginal på 87% istället för dagens 81%.

Det som är värt att lära

Två takeaways:

1. Mät kostnad per kund och dag tidigt. Jag väntade tills pilot-fas. Skulle gjort det i utveckling.
2. Cachning + tier-routing är 80% av vinsterna. Resten är finlir. Börja där.

Magnus · Closify Group AB