Het artikel pleit voor de brede invoering van 'harde budgetlimieten' (hard budget caps) bij clouddiensten en API's met betaling per gebruik. Waar 'zachte limieten' enkel waarschuwen, stoppen harde limieten de dienstverlening volledig zodra een budgetplafond is bereikt. Dit is cruciaal om enorme, onverwachte rekeningen te voorkomen, zeker nu coding agents het makkelijker maken om code te implementeren die onbedoeld hoge kosten kan genereren.
De auteur benadrukt dat:
- Gebruikers foutmeldingen prefereren boven financiële verrassingen.
- AWS en Google Cloud onlangs functies hebben gelanceerd om uitgaven te limiteren.
- AI-agents in de toekomst gebruikers zouden moeten adviseren om providers te kiezen die deze harde limieten standaard aanbieden.
We gaan standaard harde budgetlimieten nodig hebben voor bijna alles
Er is een productfunctie die de wereld de komende maanden en jaren veel vaker nodig zal hebben: standaard harde budgetlimieten (hard budget caps). Ik heb het over de functie bij diensten en API's met betaling per gebruik, waarmee je kunt aangeven: "na $X per maand, zet dit stop en geef foutmeldingen terug". Dit moeten harde limieten zijn. Zachte limieten (soft caps), zoals "stuur me een waarschuwingsmail na $X per maand", zijn niet voldoende.
Coding agents en persoonlijke agents (coding agents verpakt in een minder intimiderende gebruikersinterface) verminderen de drempel aanzienlijk om code op te starten die nuttige dingen kan doen. Soms kosten die dingen geld — denk aan aanroepen van betaalde API's, gehoste webapplicaties of systemen die extra opslag en rekenkracht in rekening brengen.
Niemand wil wakker worden van een e-mail die om middernacht is verzonden om te waarschuwen voor een budgetlimiet, om er vervolgens achter te komen dat een eigenwijze service tijdens de slaap nog enkele honderden (of duizenden) dollars aan verbruik heeft gegenereerd.
Een argument hiertegen is dat bedrijven er niet willen dat hun gehoste applicaties foutmeldingen gaan geven omdat een budget is overschreden. Ik verwacht dat de meeste bedrijven en individuen de voorkeur geven aan foutmeldingen boven een verrassingsrekening van $10.000 of meer.
Ik denk dat harde budgetlimieten de standaard moeten zijn. Als iemand graag risico's neemt, moet dat mogelijk zijn, maar dat moet via een opt-in basis. Er zou een duidelijk selectievakje op een prominente plek moeten staan:
"Verwijder de budgetlimiet. Mijn applicatie zal niet worden stopgezet als ik de geconfigureerde budgetlimiet overschrijd, en ik ben verantwoordelijk voor de daaropvolgende kosten."
De dienst waarvan ik dit het liefst zou zien, is AWS. Ik heb veel verhalen gehoord van mensen die weigeren AWS te gebruiken voor persoonlijke projecten uit (terechte) angst dat een weglopende service hen bankroet zou kunnen maken. Ik heb ook verhalen gehoord van mensen die dit niet hadden voorzien en ernstig de dupe zijn geworden.
En het blijkt dat AWS een paar weken geleden eindelijk uitgavenlimieten heeft gelanceerd! Uit hun aankondiging New AWS experience helps builders get started and ship faster van 16 september:
"Wanneer je klaar bent om te upgraden naar een betaald plan, kun je een maandelijks uitgavenlimiet voor je project instellen op basis van je gebruikspatronen, zodat je binnen je budget blijft. Als het verbruik van een project de uitgavenlimiet bereikt, wordt je project voor die maand gepauzeerd."
Zie ook Create a spend limit in AWS Settings, hoewel die pagina waarschuwt dat "we onze nieuwe ervaring momenteel uitrollen naar een beperkt aantal klanten". Laten we hopen dat dit snel algemeen beschikbaar is voor bestaande accounts.
Google Cloud lanceerde in juli een vergelijkbare functie, genaamd Spend Caps, waarmee je "een maandelijks financieel maximum kunt instellen voor specifieke diensten binnen een project". Het lijkt erop dat dit een trend wordt!
In een ideale wereld zouden onze agents kunnen helpen bij dit proces. Het zou geweldig zijn als agents een voorkeur zouden ontwikkelen voor het aanbevelen van providers met harde budgetlimieten, en nieuwe en onervaren bouwers zouden waarschuwen tegen het implementeren van applicaties via diensten zonder limieten die hen in de problemen zouden kunnen brengen.
We gaan standaard harde budgetlimieten nodig hebben voor bijna alles
Er is een productfunctie die de wereld de komende maanden en jaren veel vaker nodig zal hebben: standaard harde budgetlimieten (hard budget caps). Ik heb het over de functie bij diensten en API's met betaling per gebruik, waarmee je kunt aangeven: "na $X per maand, zet dit stop en geef foutmeldingen terug". Dit moeten harde limieten zijn. Zachte limieten (soft caps), zoals "stuur me een waarschuwingsmail na $X per maand", zijn niet voldoende.
Coding agents en persoonlijke agents (coding agents verpakt in een minder intimiderende gebruikersinterface) verminderen de drempel aanzienlijk om code op te starten die nuttige dingen kan doen. Soms kosten die dingen geld — denk aan aanroepen van betaalde API's, gehoste webapplicaties of systemen die extra opslag en rekenkracht in rekening brengen.
Niemand wil wakker worden van een e-mail die om middernacht is verzonden om te waarschuwen voor een budgetlimiet, om er vervolgens achter te komen dat een eigenwijze service tijdens de slaap nog enkele honderden (of duizenden) dollars aan verbruik heeft gegenereerd.
Een argument hiertegen is dat bedrijven er niet willen dat hun gehoste applicaties foutmeldingen gaan geven omdat een budget is overschreden. Ik verwacht dat de meeste bedrijven en individuen de voorkeur geven aan foutmeldingen boven een verrassingsrekening van $10.000 of meer.
Ik denk dat harde budgetlimieten de standaard moeten zijn. Als iemand graag risico's neemt, moet dat mogelijk zijn, maar dat moet via een opt-in basis. Er zou een duidelijk selectievakje op een prominente plek moeten staan:
"Verwijder de budgetlimiet. Mijn applicatie zal niet worden stopgezet als ik de geconfigureerde budgetlimiet overschrijd, en ik ben verantwoordelijk voor de daaropvolgende kosten."
De dienst waarvan ik dit het liefst zou zien, is AWS. Ik heb veel verhalen gehoord van mensen die weigeren AWS te gebruiken voor persoonlijke projecten uit (terechte) angst dat een weglopende service hen bankroet zou kunnen maken. Ik heb ook verhalen gehoord van mensen die dit niet hadden voorzien en ernstig de dupe zijn geworden.
En het blijkt dat AWS een paar weken geleden eindelijk uitgavenlimieten heeft gelanceerd! Uit hun aankondiging New AWS experience helps builders get started and ship faster van 16 september:
"Wanneer je klaar bent om te upgraden naar een betaald plan, kun je een maandelijks uitgavenlimiet voor je project instellen op basis van je gebruikspatronen, zodat je binnen je budget blijft. Als het verbruik van een project de uitgavenlimiet bereikt, wordt je project voor die maand gepauzeerd."
Zie ook Create a spend limit in AWS Settings, hoewel die pagina waarschuwt dat "we onze nieuwe ervaring momenteel uitrollen naar een beperkt aantal klanten". Laten we hopen dat dit snel algemeen beschikbaar is voor bestaande accounts.
Google Cloud lanceerde in juli een vergelijkbare functie, genaamd Spend Caps, waarmee je "een maandelijks financieel maximum kunt instellen voor specifieke diensten binnen een project". Het lijkt erop dat dit een trend wordt!
In een ideale wereld zouden onze agents kunnen helpen bij dit proces. Het zou geweldig zijn als agents een voorkeur zouden ontwikkelen voor het aanbevelen van providers met harde budgetlimieten, en nieuwe en onervaren bouwers zouden waarschuwen tegen het implementeren van applicaties via diensten zonder limieten die hen in de problemen zouden kunnen brengen.
Groetjes,