Budgetera till listpris, inte kampanjpriset

Varför introduktionspris kräver en annan baslinje

När en leverantör lanserar en modell med en tillfällig rabatt och samtidigt publicerar det framtida listpriset spelar båda siffrorna roll. Rabatten är verklig och rimlig att använda. Fällan är arkitektonisk: teamet dimensionerar funktionen, sätter budget och räknar hem business caset på introduktionspriset — och behandlar sedan den redan schemalagda höjningen som en överraskning.

Ett aktuellt exempel, och en påminnelse om att datumet betyder mer än riktningen: Anthropic lanserade Claude Sonnet 5 den 30 juni 2026 med introduktionspris 2 USD per miljon indatatokens och 10 USD per miljon utdatatokens till och med den 31 augusti 2026, och publicerade samtidigt listpriset 3 respektive 15 USD som skulle gälla från den 1 september — en höjning på 50 % på båda sidor för samma icke-cachade tokenvolym. Den 10 augusti 2026 gjorde Anthropic introduktionspriset permanent och höjningen ställdes in. Sonnet 5 kostar fortfarande 2 och 10 USD (källa: Anthropics lanseringsartikel, aktuell prissida, kontrollerad 23 sep 2026).

Att det gick åt det hållet försvagar inte rådet — det är argumentet för det. Ett team som budgeterat på det aviserade listpriset fick behålla överskottet. Ett team som budgeterat på introduktionspriset låg i sex veckor ett besked från en femtioprocentig kostnadsökning, utan möjlighet att veta åt vilket håll det skulle sluta. Det publicerade datumet är beroendet, inte riktningen.

Ett enda publicerat utgångsdatum räcker för att motivera principen: behandla introduktionspriset som ett versionerat beroende, inte en tidlös konstant. Detsamma gäller förhandsversioner, kampanjfönster som stänger och prismodeller som byggs om.

Så ser fällan ut i praktiken

Felet är sällan "vi glömde att priser ändras". Det är en kedja av små, rimliga beslut: teamet prototypar på introduktionspriset och demoekonomin ser bra ut. Business caset godkänns med en kostnad-per-användare baserad på det priset. Funktionen lanseras, användningen växer, och den månatliga fakturan blir en rad någon skummar igenom. Sedan stänger kampanjfönstret, fakturan hoppar med hälften, och funktionen som var lönsam blir olönsam — utan en enda kodändring, utan förändrad trafik och utan att någon tydligt ägde frågan.

Fyra skyddsräcken

Beställning: prisgranskning

Lista varje ställe i den här kodbasen där en AI-modell väljs eller dess kostnad antas: modell-id i konfiguration, hårdkodade modellsträngar, budgetkonstanter och kostnadsberäkningar i dokumentation eller kommentarer.

För varje ställe, rapportera:
- vilken modell som används,
- vilket pris som antas (om synligt),
- om en billigare modell skulle kunna hantera samma anrop.

Presentera som en tabell så jag kan lägga till kontrolldatum och ansvarig person för varje rad.

Kör beställningen en gång när ni väljer en modell med introduktionspris, och igen ett par veckor innan kampanjen tar slut. Utdata blir er arbetslista för skyddsräcke två och fyra ovan.

Vad detta har med kontraktstestning att göra

En prishöjning ändrar inte modellens svar, bara kostnaden för det. Det gör den lättare att hantera än ett beteendeskifte — men lika lätt att missa om ingen äger bevakningen. Om er integration redan har kontraktstester för modelluppdateringar, är prisutgångsdatumet en naturlig trigger att köra dem: byter ni till en billigare modell vid prishöjningen är det precis den situationen kontraktstesterna finns till för.

Slutsats

Introduktionspris kan vara en genuint bra affär — det sänker kostnaden för utvärdering och tidig produktionsanvändning. Ta rabatten. Vägra bara låta den bli arkitekturens baslinje: budgetera på listpris, kalenderlägg utgångsdatumet, bevaka kostnad per anrop, och ha nedgraderingsbeslutet klart innan datumet kommer. De team som skadas av introduktionspriser är inte de som använde dem, utan de som byggde på dem.