De dolda kostnaderna med AI i stor skala

Den 1 juni 2026, GitHub pensionerade permanent flat-rate \”premium requests\” för Copilot och ersatte dem med förbrukningsbaserade AI‑krediter. När de första fakturorna under den nya modellen kom en månad senare, såg vissa agentiska användare fakturor de inte var förberedda på: En utvecklare rapporterade månadskostnaderna ökade från $29 till $750 för de mest intensiva agentiska arbetsflödena.

Det var ett synligt exempel på en bredare förändring på AI‑verktygsmarknaden under 2026 – och en som kan vänta organisationer som fortfarande betalar en fast avgift idag.

Organisationer räknar timmarna de sparar. Många av dem räknar inte med det som en fast avgift håller osynligt: kontextförbrukning och omförsök efter fel. Andra kostnader dyker aldrig upp på leverantörens faktura, inklusive den tid som läggs på att granska resultat och underhålla prompts. När faktureringen övergår till faktisk förbrukning riskerar organisationer utan kostnadsdisciplin en faktura som överraskar dem på samma sätt som Copilots nya modell överraskade vissa användare.

Den kontext som ingen prissatte

AI behöver uppenbarligen kontext; det är ingen tvekan. Frågan är om den kontext som skickas är relevant, eller bara bekvämt tillgänglig. Att skicka ett helt dokument är det snabbaste sättet att ge en modell information. Det är inte automatiskt det billigaste eller bästa sättet.

I maj 2026 publicerade Stanford’s Digital Economy Lab en analys av agentiska kodningsuppgifter över åtta frontier‑modeller och fann att dessa uppgifter förbrukar upp till tusen gånger fler token än en enkel kodchatt, där den främsta drivkraften inte är modellens output utan den indata‑kontext den skickar om och om igen. Agenten läser om hela sin historik vid varje efterföljande steg. Samma uppgift, körd flera gånger, varierade i token‑förbrukning upp till trettiotal gånger.

Noggrannheten skalar inte heller linjärt med kontextvolymen: den toppar ofta vid en måttlig mängd och lägger sedan bara till kostnad utan att tillföra värde.

Token‑blindhet handlar alltså inte om att AI inte behöver kontext. Det handlar om att utan mätning frågar ingen om all den kontexten verkligen är nödvändig. Under en fast avgift är frågan lätt att ignorera. Under förbrukningsbaserad fakturering blir den en del av kostnaden.

När du betalar för fel två gånger

Agentiska arbetsflöden medför en annan kostnad som nästan aldrig syns i ROI‑beräkningar. Föreställ dig en förenklad kedja med tio steg, där varje steg har 95 procents chans att fungera korrekt på egen hand. Det låter tillräckligt pålitligt, men när de sätts ihop, den kedjan har bara ungefär 60 procents chans att klara hela körningen utan ett enda fel.

I ett arbetsflöde som skickar den ackumulerade kontexten igen vid varje anrop, kostar varje fel och den efterföljande omförsöket dig inte bara det upprepade steget: du betalar också igen för allt som skickades innan det.

Det är ett vanligt problem som nästan alla stöter på när de bygger sin första agentiska pipeline. Jag gick igenom det själv. I början, med bara ett par agenter, spelade det inte så stor roll. Men när pipelinen växte blev varje misslyckad körning dyrare, och det var det som fick mig att börja fråga vilken kontext varje agent behövde och hur den skulle cachas, snarare än bara om körningen lyckades.

Samma analys beräknar att en tio‑stegs agent med 95 procents tillförlitlighet per steg förbrukar ungefär 40 procents fler token på omförsök än ett helt pålitligt system. Detta är en kostnad du kommer att se på fakturan men som sannolikt inte finns i något ROI‑kalkylblad.

Översyn är ingen bugg. Den hör hemma i budgeten

Denna poäng måste uttryckas exakt, för det är lätt att missförstå. Att granska AI‑output är ingen systemfel; det är en legitim, förväntad del av att arbeta med AI, på samma sätt som kodgranskning är en legitim del av att arbeta med utvecklare. Problemet är inte att output granskas. Problemet är att detta arbete nästan aldrig tas med i beräkningen av hur mycket AI faktiskt sparade.

Glean’s Work AI Institute undersökte 6 000 arbetare och fann att automatisering sparar dem cirka 11 timmar per vecka, men nästan sex och en halv timme av dessa timmar går åt till underhållsuppgifter: att ge AI‑system kontext, kontrollera deras arbete och rensa bort misstag. Den netto‑besparingen är då närmare fyra och en halv timme – mindre än hälften av huvudnumret. AI sparar fortfarande tid, bara inte lika mycket som det första talet antyder.

Promptar kräver underhåll, inte bara en författare

Promptar beter sig mer som produktionskod idag: en modelluppdatering, en förändring i kontext eller en till synes mindre redigering kan förändra hur de presterar. Utan versionering och testning kan dessa förändringar tyst introducera problem. Regressionstester som är standardpraxis för kod hoppas fortfarande ofta över när det gäller att verifiera promptar. En förändring som ser ut som en mindre redigering av en enda mening kan nå produktion och minska noggrannheten utan att någon märker det förrän problemet har byggts upp till något synligt.

Att bygga ett korrekt utvärderingsramverk – inklusive en testuppsättning och automatiserade regressionstester för varje förändring – är extra arbete som nästan aldrig syns i beräkningen \”AI sparar tid\”.

Billigare token, högre fakturor

GitHub Copilot var inget undantag. En undersökning citerad av CFO Dive fann att nästan sju av tio amerikanska företag rapporterade åtminstone delvisa AI-budgetöverskridanden under det senaste året, mestadels innan en full övergång till förbrukningsbaserad fakturering, inte efter den.

Bain & Company, i sin analys av tokenekonomi i juni, lägger till ett paradox som fångar hela situationen bäst: priset per token föll med hälften under året, medan förbrukningen under samma period ökade 4,5‑faldigt.

Modellen blev billigare, men fakturan förblir envist hög. Företag gick över till nyare modeller, gav agenter mer komplexa uppgifter och fann fler arbetsflöden för dem. En billigare token innebar inte lägre utgifter; det innebar att det fanns fler anledningar att konsumera en.

Hur du förbereder dig innan fakturan kommer

Ramverket som följer av detta handlar inte om att använda mindre AI. Det handlar om att känna till AI‑kostnaderna innan du beslutar dig för att skala upp den ytterligare.

1. Få först insyn

tills du har förbrukningen uppdelad per team, arbetsflöde, applikation och slutförd uppgift, är varje expansion ett blint spel. Den insynen är inte gratis heller: för agentbaserade arbetsflöden särskilt krävs spårning av varje steg, loggning av vad som hände och varför, samt övervakning av löpande loopar, vilket tar egen ingenjörstid och verktyg. Budgetera för detta som en del av kostnaden för att driva AI, inte som en eftertanke ovanpå den.

2. Räkna om ROI på nettobasis

Subtrahera den tid som spenderas på granskning, korrigeringar och promptunderhåll från de rapporterade sparade timmarna. Om tidsbesparing är syftet med användningsfallet och nettoresultatet är negativt eller oåtkomligt, är det inte redo för skalning. Där den avsedda vinsten är kvalitet, kapacitet, riskreducering eller intäkt, mät då den utfallet direkt.

3. Tillämpa kostnadsdisciplin, men inte enhetligt

En hård utgiftsgräns är meningsfull där misslyckande är billigt: interna verktyg, experimentella agenter, utvecklingsmiljöer. För kritisk, kundfokuserad funktionalitet – till exempel en kundtjänstassistent – är en hård gräns inte genomförbar, eftersom den skapar en risk för avbrott. Där behöver du lagerindelade reservalternativ till en billigare modell och tidiga varningslarm, inte en avstängning vid noll.

4. Behandla prompts och utvärderingar som ingenjörstillgångar

Versionera dem, testa dem och granska förändringar innan driftsättning, på samma sätt som du skulle hantera produktionskod.

Gå in i förnyelser med dina egna data

Leverantörspriser är svåra att utvärdera utan dina egna användningsdata. Före en förnyelse eller modelländring, räkna ut vad dina befintliga arbetsflöden skulle kosta under de föreslagna villkoren. Målet är inte bara att förhandla fram ett lägre pris. Det är att veta hur det priset kommer att bete sig på din faktiska förbrukningsnivå, istället för att upptäcka det via fakturan.

Tre saker du kan göra den här veckan: kontrollera om du kan bryta ner AI‑förbrukning per team och arbetsflöde; välj ett användningsfall och jämför den tid som spenderas på granskning med de rapporterade sparade timmarna; och ta reda på var en hård utgiftsgräns kan skapa ett avbrott istället för att kontrollera en kostnad.

AI‑kostnader kan hanteras. Bara inte när du får reda på dem för första gången via fakturan.