Ett säte visar inte nyttjande

Ett återkommande mönster i AI-native-offerter: en rad för licenser och en rad för förbrukning, båda presenterade som vidarefakturerad självkostnad, båda fasta per månad.

Förbrukningsraden beter sig i alla fall som förbrukning. Licensraden beter sig inte som någonting. Ett säte kostar lika mycket oavsett om det används, vilket betyder att det inte finns någonting att stämma av det mot.

Det är värt att säga rakt ut, för det har en följd de flesta beställare aldrig kommer fram till. Betalar en kund för tio säten och teamet i praktiken nyttjar fem finns två helt olika situationer som utifrån ser identiska ut:

• Leverantören har köpt tio. Fem står oanvända. Det är en verklig kostnad utan värde, på leverantörens sida, och de har all anledning att vilja rätta det.
• Leverantören har fakturerat tio och köpt fem. Differensen är intäkt utan motsvarande kostnad, på en rad som beskrevs som självkostnad.

Ingetdera behöver vara avsiktligt. Ett estimat som aldrig stäms av ser exakt ut som det andra fallet. Men de två går inte att skilja åt genom att fråga, bara genom att stämma av, och ett säte producerar ingenting att stämma av mot.

Vad en nyckel gör som ett säte inte kan

Läggs förbrukningen på kundstyrda API-nycklar i stället ändras tre saker samtidigt.

Nyttjandet blir synligt. En nyckel per person, separata nycklar för sådant som körs serverside. Förbrukning per nyckel, läsbar för kunden. Det är hela svaret på avstämningsproblemet: nu finns något att kontrollera.

Ett tak blir möjligt. Per nyckel: en gräns per vecka eller månad, och en begränsning av vilka modeller som får anropas. En generisk router som OpenRouter gör det inbyggt, kontot bär ett förbetalt saldo och varje nyckel har eget tak.

Modellvalet står öppet. En generisk router anropar vilken leverantörs modeller som helst. Boxas upplägget in hos en enda modelleverantör finns bara deras modeller att välja. Över ett projekt som ska leva i flera år är den optionen värd något, och det är den enda fördelen här som inte går att uppnå på annat sätt.

Taket besvarar en fråga som avtal inte klarar

Vem betalar när en automatiserad körning spårar ur?

Som avtalsklausul är det nära oförhandlingsbart. Ingen leverantör skriver villigt att de bär kostnaden för sina egna agenters felkörningar, och ingen kund får igenom den klausulen utan strid.

Som mekanism är den redan löst. Ett hårt tak begränsar skadan oavsett vem som är vållande. Det kräver ingen tolkning i efterhand och ingen motpart som medger något. Skadeområdet är ett tal båda parter kommit överens om i förväg.

Det är samma drag som en kreditgräns i stället för en ansvarsklausul, och det fungerar av samma skäl.

Två saker det inte löser

Nycklar ska inte ersätta leverantörens säten. Abonnemang är betydligt billigare per token än API-åtkomst, och det är därför leverantörer använder dem för interaktivt arbete. En kund som byter ut leverantörens säten mot egna nycklar köper kontroll till högre styckkostnad. Uppdelningen som håller: säten är leverantörens kostnad, eftersom de är leverantörens arbetsredskap, medan den löpande automatiserade förbrukningen flyttar till kundstyrda nycklar med tak.

Att äga kontona ger ingenting annat. Värt att säga eftersom det är dit samtalet brukar gå först. Det finns ingen åtkomlig historik i kontona, ingen ackumulerad effekt av typen "nu har vi tränat upp den på vår kodbas". Synlighet är den enda fördelen, och nycklar levererar synlighet utan att någon behöver ta över någons konton. Att låta leverantören behålla sina egna konton håller dessutom leverantören ansvarig för sina egna verktyg, vilket är en funktion.

Två saker att verifiera innan det föreslås

Vi skulle inte acceptera att en leverantör påstod detta utan att kontrollera, så vi ska inte göra det heller.

Verktygslicensiering. Flera av de agentiska kodverktygen är licensierade för interaktivt abonnemangsbruk och är inte självklart avsedda att köras på tredjepartsnycklar. Alla provider-nära funktioner överlever inte heller en router, och cachningsbeteende kan skilja. Kontrollera mot den specifika verktygskedjan i stället för att anta att det generaliserar.

Datavägen. En router blir ett biträde i kedjan, alltså ett personuppgiftsbiträdesavtal, multiplicerat med antalet jurisdiktioner kunden verkar i. Ungefär fem procents routingpåslag är billig försäkring mot en toppmånad, men ett nytt biträdesavtal över fem marknader är en annan sorts kostnad. Slå ihop det med annan biträdesgranskning som ändå är på gång.

Vad påslaget ska kallas

Inte överpris. De fem procenten köper synlighet på en rad som tidigare var omätbar, och ett tak på en rad som tidigare inte hade något. Väg det mot toppmånaden i stället för mot listpriset per token, och det slutar vara en diskussion.

Relaterat: Att offerera AI-native leverans och Att styra AI-kostnaden i skala. Beställarserien som reser den ansvarsfråga den här artikeln besvarar börjar i En jämn siffra över ett ojämnt arbete.