Dlaczego API powinny naliczać opłaty tylko za sukces — argumenty za rozliczaniem po HTTP 200
Większość API nalicza opłatę za każde płatne wywołanie. Agenty AI nieustannie ponawiają próby wobec niestabilnych usług upstream — co oznacza, że przestarzały model 'zawsze naliczaj' w praktyce opodatkowuje odporność. Oto argumenty za rozliczaniem tylko przy HTTP 200 i za tym, co zmienia to w sposobie projektowania agentów.
TL;DR
- •Agenty AI słusznie ponawiają próby przy błędach przejściowych (5xx, timeouty, limity zapytań). W modelu 'zawsze naliczaj' każda próba to realny koszt — zamieniając upstream o dostępności 99,5% podczas tych złych 0,5% w karę kosztową rzędu 5×.
- •'Naliczaj tylko przy HTTP 200' zestraja bodziec dostawcy z interesem klienta: dostawcy naprawiają niestabilność, klienci za nią nie płacą.
- •Odblokowuje to również wzorce projektowe — agresywne budżety ponawiania, optymistyczne prefetchowanie, redundantne wywołania — które model 'zawsze naliczaj' czyni zaporowo drogimi.
- •Większość dostawców tego nie robi, bo ich przestarzała infrastruktura wiąże pomiar zużycia z wywołaniem upstream, a nie z odpowiedzią. To ograniczenie systemu rozliczeniowego przebrane za politykę.
Zachowanie, które próbujemy wspierać
Agenty AI to nowy rodzaj klienta API. To nie te staranne integracje korporacyjne z 2015 roku, które łapały jeden błąd i wysyłały maila do dyżurnego inżyniera. To pętle, które gdy coś zawiedzie, śpią chwilę i próbują ponownie — czasem pięć albo dziesięć razy — i w ogóle nie pokazują wyniku człowiekowi. Cały sens tej pętli polega na tym, by błędy przejściowe były niewidoczne dla użytkownika końcowego.
To świetny wzorzec. Tworzy odporne produkty. Ukrywa przed użytkownikami chaotyczną rzeczywistość publicznego internetu. Kłopot w tym, że model rozliczeniowy API ustalono w erze, gdy ponawianie prób było rzadkie i na tyle kosztowne, by domyślnie je zniechęcać. I nadal tak działa. Każda próba to płatne wywołanie, niezależnie od tego, czy coś zwróciło.
Konkretnie: agent, który uderza w API o dostępności 99,5% i ponawia próby do pięciu razy przy błędach przejściowych, wygeneruje podczas tych złych 0,5% do 5× wywołań — i 5× rachunek. Agent postąpił słusznie. Klient płaci za niestabilność upstreamu.
Prostsza alternatywa
Naliczaj tylko przy HTTP 200. Konkretnie, tylko przy udanej odpowiedzi o udokumentowanym kształcie. Wszystko inne — 4xx za błędy wywołującego, 5xx za nasze błędy, timeouty, limity zapytań, odpowiedzi częściowe-ale-zniekształcone — jest darmowe.
Brzmi to jak drobna zmiana. Nie jest. Zmienia to, co jest ekonomicznie racjonalne po obu stronach:
- Dostawca ma teraz bezpośredni bodziec finansowy, by naprawiać niestabilność. Każde kapryśne 503 to utracona sprzedaż, a nie darmowy obiad. Przekonaliśmy się, że przejście na rozliczanie tylko przy sukcesie było pojedynczą siłą, która najmocniej wypchnęła naszą pracę nad niezawodnością na szczyt planu — nie ma sztuczki arkuszowej, która sprawi, że przestój wygląda dobrze, gdy rezygnujesz z przychodu z tych wywołań.
- Klient może agresywnie wymiarować budżety ponawiania. Pętla z 5 próbami i wykładniczym backoffem to oczywisty wybór, gdy najgorszym przypadkiem błędu przejściowego jest jedno płatne wywołanie (ostateczny sukces) zamiast sześciu (jedno płatne za każdą próbę).
- Rynek może porównywać API po dolarach-za-udane-wywołanie zamiast dolarach-za-próbę. To właściwa jednostka. Jeśli dwa API publikują '$0.001 za wywołanie', ale jedno ma dostępność 99,9%, a drugie 95%, widoczne dla użytkownika koszty różnią się o 5× w modelu 'zawsze naliczaj' i o dokładnie 0% w modelu 'tylko przy sukcesie'. Które powinien wybrać kupujący, jest oczywiste — a 'tylko przy sukcesie' czyni to widocznym.
Co zmienia się w sposobie budowania agentów
1. Budżety ponawiania stają się darmowe
W modelu 'zawsze naliczaj' właściwy budżet ponawiania dla obsługi błędów przejściowych to mniej więcej 1–2 próby — poza tym koszt powtarzających się niepowodzeń zaczyna mieć znaczenie. W modelu 'tylko przy sukcesie' budżet to 'tak długo, jak użytkownik może czekać'. Rutynowo widujemy pętle agentów ze wzorcami 5 prób, wykładniczego backoffu i jittera, które w przestarzałym modelu byłyby lekkomyślne.
2. Optymistyczne prefetchowanie staje się tanie
Wzorzec zaporowo drogi w modelu 'zawsze naliczaj': spekulacyjnie wystrzelić wywołanie wyszukiwania, gdy użytkownik jeszcze pisze, na wypadek gdyby przewidziane zapytanie było trafne. Jeśli predykcja chybi, wyrzucasz wynik. W modelu 'tylko przy sukcesie' jest to tanie, bo wywołania anulowane / nieużyte zwracają sukces, ale ty odrzucasz odpowiedź — więc płacisz niewielką premię za przewidywalność i latencję. W modelu 'zawsze naliczaj' każda błędna predykcja to płatne wywołanie, co czyni heurystykę zbyt drogą, by ją wdrożyć.
3. Redundantne wywołania stają się narzędziem niezawodności
Czasem najtańszą strategią niezawodności jest wystrzelić dwa żądania do dwóch różnych API, wziąć to, które wróci pierwsze, i odrzucić wolniejsze. W modelu 'zawsze naliczaj' podwaja to rachunek. W modelu 'tylko przy sukcesie' jest darmowe dla odrzuconego wywołania (nie użyłeś odpowiedzi, nie zapłaciłeś za nią). Nagle strategie hedgingowe, które były drogimi abstrakcjami, stają się praktyczne.
Co musi oznaczać 'sukces'
Model działa tylko wtedy, gdy 'sukces' jest jednoznaczny. Definiujemy go ściśle:
- HTTP 200 z udokumentowanym schematem odpowiedzi — płatne.
- HTTP 200 z błędem opakowanym w body odpowiedzi — niepłatne (to byłaby luka, która łamie cały model).
- HTTP 4xx — niepłatne. Obejmuje to 401 (auth), 402 (niewystarczające kredyty), 422 (walidacja), 404 (nie znaleziono w niektórych kontekstach).
- HTTP 5xx — niepłatne.
- HTTP 429 (limit zapytań) — niepłatne.
- Błędy sieci / timeouty przed naszym edge — niepłatne.
Dla endpointów wsadowych (np. URL Extract z 25 URL-ami w jednym wywołaniu) całe wywołanie to jeden HTTP 200, jeśli powiódł się choć jeden URL, naliczany według stawki per-URL. Pole status per-URL mówi wywołującemu, które URL-e zawiodły. Praca została wykonana; jest płatna.
Dlaczego większość dostawców tego nie robi
Trzy powody, w kolejności tego, jak bardzo każdy z nich się liczy:
- Infrastruktura rozliczeniowa. Standardowym wzorcem jest pomiar przy bramie API, zanim znana jest odpowiedź. Brama emituje płatne zdarzenie do Kafki, system rozliczeniowy je agreguje, rachunek zostaje wysłany. Przebudowa pomiaru tak, by wyzwalał się po tym, jak usługa upstream odpowiedziała kodem statusu, wymaga albo (a) sprzężenia bramy ze zdrowiem backendu (co tworzy nowe tryby awarii), albo (b) napisania potoku uzgadniającego, który z opóźnieniem kredytuje nieudane wywołania. Oba to realna praca inżynierska.
- Przyzwyczajenie. Wzorzec ustanowiły niezawodne backendy — Twilio, AWS, Stripe. Działa dobrze, gdy twój upstream ma dostępność 99,99%. API, które opakowują LLM-y, scrapują sieć albo wywołują wolnych partnerów danych, są znacznie mniej niezawodne, ale wzorzec rozliczeniowy odziedziczono z niezawodnej ery i nigdy nie zaktualizowano.
- Przychód. 'Zawsze naliczaj' to po prostu więcej pieniędzy. Większość dostawców nie musiała konkurować w tym wymiarze, bo większość ich klientów nie była ruchem agentów, a synchroniczni użytkownicy-ludzie znoszą sporadyczne błędy lepiej niż czytanie modelu rozliczeniowego.
Pierwszy to realna inżynieria. Drugi i trzeci to inercja. Oba ustąpią, gdy ruch agentów stanie się większością konsumpcji API — co według linii trendu dzieje się w ciągu 18 miesięcy dla większości publicznych API.
Na co zwracać uwagę jako kupujący
Jeśli oceniasz API danych pod obciążenie agentowe, trzy wyraźne pytania:
- 'Naliczacie tylko przy HTTP 200 czy za każdą płatną próbę?' — wymagana jest prosta odpowiedź. Nie akceptuj 'zwykle' ani 'zależnie od planu'.
- 'Jak rozliczany jest HTTP 207 / częściowy sukces?' — to wyciąga na wierzch odpowiedź o luce.
- 'Jaka jest wasza publikowana dostępność i jaki jest mechanizm zwrotu z SLA, jeśli jej nie dotrzymacie?' — 'tylko przy sukcesie' to silny sygnał, ale nie zastępuje prawdziwego SLA. Oba powinny być obecne.
Przesunięcie, na które to wskazuje
Agenty AI zmieniają ekonomikę jednostkową każdego API, którego dotkną. API zaprojektowane pod erę agentów wyglądają inaczej — prostsze kształty, przewidywalne schematy, przyjazne dla maszyn auth, przejrzysty cennik — a ich modele rozliczeniowe też wyglądają inaczej. 'Tylko przy sukcesie' to jedno z prostszych przesunięć. To trudne, które wciąż przed nami, to rozgryzienie, jak wieloetapowe przepływy agentów wyceniać między dostawcami, gdy żadna strona nie jest właścicielem całej ścieżki.
Na razie żądaj 'tylko przy sukcesie' od dostawców, od których możesz. Buduj agenty, które to wykorzystują. A gdy kupujesz API, policz to w dolarach-za-udane-wywołanie, a nie w dolarach-za-próbę.
Najczęściej zadawane pytania
Czy 'tylko przy sukcesie' nie zachęca dostawców do klasyfikowania sukcesów jako niepowodzeń?
W teorii tak, ale presja odwrotna jest silniejsza: deweloperzy porównują API po realnych dolarach-za-użyteczne-wywołanie, a to dokładnie mierzy 'tylko przy sukcesie'. Dostawca, który po cichu przekwalifikowywałby sukcesy na niepowodzenia, w ciągu kilku dni zderzyłby się z rozzłoszczoną kolejką wsparcia i publicznym śladem recenzji. Rynek jest na tyle mały, że sam się koryguje.
A jeśli moje wywołanie zakończy się częściowym sukcesem — na przykład wsadowy extract, w którym 2 z 25 URL-i zawiodą?
Dwa rozsądne modele. (a) Całe wywołanie to HTTP 200, jeśli powiódł się choć jeden URL; niepowodzenia poszczególnych URL-i są raportowane w statusie per-URL. Praca została wykonana, więc jest płatna. (b) HTTP 207 (multi-status) dla przypadku częściowego — każdy URL rozliczany jest osobno. Wybraliśmy (a), bo czyni to cennik przewidywalnym: agenty wiedzą, że udany HTTP 200 oznacza, że najgorszym przypadkiem jest zapowiedziany koszt kredytów. (b) jest 'sprawiedliwsze', ale trudniejsze do zaplanowania w budżecie.
Co liczy się jako niepowodzenie?
Nasza zasada: HTTP 4xx, który jest wyraźnie winą wywołującego (zniekształcone body, brak auth, niewystarczające kredyty), nie jest naliczany. HTTP 5xx nigdy nie jest naliczany — to nasz problem. Błędy sieci i timeouty po naszej stronie nigdy nie są naliczane. Limity zapytań (429) nigdy nie są naliczane. Jedyne, co jest naliczane, to HTTP 200 o zapowiedzianym kształcie odpowiedzi.
Dlaczego większość dostawców nalicza opłatę za każde wywołanie?
Trzy powody, głównie historyczne. (1) Przestarzałe systemy rozliczeniowe mierzą przy bramie API, zanim znana jest odpowiedź. Podłączenie rozliczeń tak, by wyzwalały się z opóźnieniem na podstawie statusu odpowiedzi, nie jest trywialne. (2) Wzorzec ustanowiły Twilio i AWS w erze niezawodnych backendów; API, które opakowują LLM-y lub scrapują sieć, są znacznie mniej niezawodne, więc założenie przestaje się utrzymywać. (3) To większy przychód. Dwa pierwsze to wymówki; trzeci to prawda.
Czy są przypadki, w których 'zawsze naliczaj' ma sens?
Gdy wywołanie faktycznie zużywa stały koszt przy każdym wywołaniu, niezależnie od wyniku — na przykład call-out sprzętowy (wysłany SMS), mutacja atomowa na granicy (aktualizacja DNS) lub usługa, której backend nie potrafi odróżnić 'spróbowaliśmy i zawiedliśmy' od 'zrobiliśmy to, a ty tego nie zauważyłeś'. Dla API danych typu odczytowego i API wyszukiwania ten model nie pasuje.
API użyte w tym artykule
Sarah Choy jest CEO API Pick. Pisze o budowaniu produkcyjnych API dla agentów AI i przepływów pracy z LLM.