2026-10-27: 7 API-klager vi hørte i dag

Klager som engelskspråklige utviklere la ut offentlig mellom 25. og 27. okt. 2026, gjengitt med egne ord nedenfor og med lenker til de opprinnelige innleggene. Hvert svar bruker bare det PoYos offentlige nettsted og dokumentasjon sier i dag, og lenker til siden det kommer fra. Der dokumentasjonen ikke dekker noe, sier vi det.

---

Q1. Den nye, raske modellen er så rask at den gir seg selv 429 – særlig med maksimal resonnering og parallelle Codex-økter.

Dette klager utviklerne på: GPT-6.1 Terra ble lansert som et raskt og billigere nivå for datamaskinbruk, men utviklere fikk straks HTTP 429 på Terra / hurtigmodus og med maksimal resonnering – mens den samme prompten på Sol gikk fint. Flere innlegg påpekte at 429-feilene kom med null brukte tokens, noe som betyr at en samtidighets- eller hastighetssperre slo til før målingen startet. Parallelle Codex-økter som pollet med samme nøkkel, gjorde det verre.

Slik svarer PoYo: Siden med feilkoder gir 429 én betydning – rate_limit_error – og én anbefalt handling: vent før du prøver igjen, eller sett forespørsler i kø. Kom i gang oppgir standardgrensen for generering: opptil 20 nye genereringsforespørsler per 10 sekunder, per konto. Forespørsler over grensen får HTTP 429 og kommer ikke inn i køen. Chat- og mediemodeller deler én PoYo-nøkkel og står oppført i llms.txt, så å bytte modell er å endre en model-streng – ikke å ta i bruk en ny leverandør. Hvis du stadig får 429, sier dokumentasjonen at du kan kontakte kundestøtte for en høyere grense; godkjenning gis med forsiktighet.

Dokumentasjonen beskriver ingen automatisk failover mellom leverandører. Bygg reserveløsningen inn i klienten. Kom i gang sier også at PoYos «samlede stabilitet kan være litt lavere enn hos de offisielle leverandørene».

---

Q2. «429»-feilen min var egentlig en forbruksgrense – faktureringsfeil forkledd som hastighetsgrenser.

Dette klager utviklerne på: Ett innlegg oppsummerte det slik: HTTP 429 er ikke én enkelt feiltype. Hos Anthropic kan den bety en hastighetsgrense, en akselerasjonsgrense eller et forbrukstak – og en 429 på grunn av forbrukstak har ofte ingen Retry-After, så det hjelper ikke å vente i det uendelige. Team fortsetter å behandle en hard faktureringsstopp som struping.

Slik svarer PoYo: PoYo skiller tydelig mellom tilfellene i tabellen over feilkoder:

Selve faktureringen er forhåndsbetalte kreditter: Forsiden sier engangskjøp uten gjentakende abonnementer, og at kredittene aldri utløper. Poll GET /api/user/balance for credits_amount når du trenger et tall i sanntid (brukersaldo). Tipset på siden med feilkoder er tydelig: Følg med på kredittene for å unngå 402 under kritisk arbeid.

---

Q3. Agent-SDK-et mitt brenner hastighetsvinduet ~1,7× raskere enn chat – og N agenter deler fortsatt ett tak.

Dette klager utviklerne på: Anthropic bekreftet en feil i Agents SDK som brukte opp Claudes 5-timers hastighetsgrenser rundt 1,7× raskere enn ventet når man byttet fra chat til agentmodus. I tillegg påpekte utviklere at worktrees løser filkonflikter, men at ti agenter fortsatt deler én database og én hastighetsgrense i API-et – så parallelle oppsett snubler i hverandre på samme nøkkel.

Slik svarer PoYo: Generering på PoYo er laget for å være asynkron, slik at lange jobber ikke er bundet til ett enkelt tidsavbrudd i gatewayen. Kom i gang og API-oversikten sier: Send inn en oppgave, lagre task_id, og poll deretter status eller ta imot en webhook. For produksjonslaster foretrekker dokumentasjonen signerte webhooks fremfor hyppig polling. Ved 429 venter du eller setter i kø (feilkoder); standardgrensen for generering er fortsatt 20 nye forespørsler / 10 s per konto, og overskytende forespørsler avvises og settes ikke i kø.

For å hindre at én løpsk agent tømmer hele kontoen, bruker du kontrollene som er dokumentert på API-nøkkelsiden og i Kom i gang: bruksgrenser per time, per dag og totalt for hver nøkkel. Bilde, video, musikk, chat og 3D ligger bak én samlet API-nøkkel (llms.txt, forside).

Dokumentasjonen beskriver ingen automatisk failover mellom leverandører. Klienten din må håndtere 429 / 5xx og velge neste modell eller ny forsøksvei.

---

Q4. Enda en SaaS-tjeneste fikk tak i AI-nøklene mine – og leverandøren sa at det uautoriserte forbruket ikke refunderes.

Dette klager utviklerne på: Én utvikler meldte om en hacket Anthropic-API-nøkkel som ga $105.94 i uautorisert bruk. Kundestøtte (via en AI-agent) svarte at forbruk som er brukt, ikke refunderes, og lukket saken. I det samme 48-timersvinduet dukket innbrudd i stil med OpenCode Console / Railway stadig opp igjen, der lagrede nøkler til OpenAI, Anthropic og Google var byttet – roter først, og sett deretter et absolutt forbrukstak.

Slik svarer PoYo: Roter først – en lekket hemmelighet er fortsatt en lekket hemmelighet. Deretter beskriver dokumentasjonen vår kontroller som begrenser hva en stjålet PoYo-nøkkel kan gjøre:

• IP-hviteliste. Tillat bare godkjente server-IP-er på en nøkkel, slik at en nøkkel som er kopiert ut av en miljøvariabel, ikke virker fra angriperens maskin. Se API-nøkkelsiden og Kom i gang.
• Bruksgrenser per nøkkel (per time, per dag og totalt), slik at én nøkkel har et absolutt tak før du oppdager noe.
• Blokkering per sluttbruker. Send en X-End-User-ID-header, så kan du blokkere én misbrukende bruker på en nøkkel uten å rotere den. En blokkert ID returnerer HTTP 403 med end_user_blocked. Se Identifisering av sluttbrukere.

Den offentlige dokumentasjonen vår lover ikke refusjon for bruk med en lekket nøkkel. Hvis du tror en PoYo-nøkkel er misbrukt, tilbakekaller du den og kontakter kundestøtte ([email protected]).

---

Q5. En AI-klient bør vite når den ikke skal prøve igjen – og nye forsøk på video kan i det stille doble regningen.

Dette klager utviklerne på: Nye forsøk hjelper ved midlertidige feil, men de er ingen universalløsning. Når en forespørsel er feilformatert, legitimasjonen er ugyldig eller en modell ikke er tilgjengelig for kontoen, gir gjentatte kall bare mer press. For video-API-er dukker det samme temaet opp som «trykk på prøv igjen, og du kan opprette en ny fakturert oppgave».

Slik svarer PoYo: Koble feilen til riktig handling i feilkoder:

• 402 insufficient_credits_error → fyll på. Ikke prøv igjen.
• 429 rate_limit_error → vent eller sett i kø.
• 500 / 502 / 503 → eksponentiell backoff.
• 401 → rett opp nøkkelen; å prøve igjen med den samme ugyldige legitimasjonen hjelper ikke (Kom i gang).

Kom i gang advarer også: Behandle hvert nye innsendingsforsøk som potensielt nytt betalt arbeid, og bekreft om den opprinnelige forespørselen opprettet en oppgave før du sender inn på nytt. For medier sier llms.txt og forsiden at mislykkede oppgaver ikke belastes, og at fakturering skjer per vellykket resultat, priset per modell. Bruk heller callback_url / webhooks enn aggressiv statuspolling, så du ikke mangedobler belastningen mens du venter (API-oversikt).

---

Q6. API-prisene føles fortsatt vanvittig dyre sammenlignet med abonnementet – og jeg ser ikke saldoen i sanntid før agenten bruker den opp.

Dette klager utviklerne på: Ett svar sa det rett ut: Abonnementer føles subsidierte, men API-prisene hos OpenAI og Anthropic er «vanvittig dyre». Andre innlegg i samme periode spurte om folk i det hele tatt vet hva én enkelt prompt med flere agenter koster med API-priser, og minnet utviklere på at abonnementsmålerne i ChatGPT / Codex og API-målerne ikke snakker sammen.

Slik svarer PoYo: Tre dokumenterte elementer passer til denne klagen:

1. Forhåndsbetalte kreditter, ingen abonnementsmåler. Forsiden beskriver kredittbaserte priser med engangskjøp, ingen gjentakende abonnementer og kreditter som aldri utløper. Du betaler for vellykkede genereringer; mislykkede oppgaver belastes ikke (llms.txt).
2. Én nøkkel, én saldo. Chat og medier deler én PoYo-konto. Poll GET /api/user/balance for credits_amount (brukersaldo).
3. Publiserte priser per modell. Gjeldende priser står på hver modellside / https://poyo.ai/models/<id>/llms.txt og i katalogindeksen (llms.txt) – sjekk dem før du sender inn betalt arbeid, og ikke gjett dollarbeløp ut fra hukommelsen. Oppgavehistorikken (beskrevet i Kom i gang) lar deg se modell, input og status i etterkant.

---

Q7. «Serverfunksjonen» / Telegram-boten min kan kalles av hvem som helst – og nøkkelen ligger der curl finner den.

Dette klager utviklerne på: Praktiske sikkerhetsinnlegg fortsatte å komme: Begrens API-nøklene og sett en daglig kvote; ikke lim inn leverandørnøkler i chatgrensesnitt eller Telegram-agenter; en nøkkel i en serverfunksjon som kan kalles uten hastighetsgrense per bruker og forbrukstak, er et kredittkort for den som finner URL-en.

Slik svarer PoYo: Kom i gang er tydelig: Eksponer aldri API-nøkkelen i frontend-kode (nettleser, mobilapper, offentlige repoer). Behandle nøkkelen som en hemmelighet, hold den på serveren, og bruk kontrollene som allerede er dokumentert for nøkler i produksjon:

• IP-hviteliste og tak per time / dag / totalt for hver nøkkel på API-nøkkelsiden.
• Gjør X-End-User-ID obligatorisk, og blokker deretter en misbrukende bruker med HTTP 403 end_user_blocked uten å rotere hele nøkkelen (Identifisering av sluttbrukere).
• Håndter 401, 402 og 429 eksplisitt før du går i produksjon (Kom i gang, feilkoder).

---

Rask oversikt