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

Klager som engelskspråklige utviklere la ut offentlig mellom 27. og 29. 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. De månedlige API-kredittene i ChatGPT Pro / Business utløper ubrukt – og i noen regioner kan de ikke hentes ut i det hele tatt.

Dette klager utviklerne på: Etter at OpenAI presenterte det som at Pro-prisen kommer tilbake som API-kreditt, spurte utviklere straks hvor mye av potten som dør ved periodens slutt. Innlegg påpekte at kredittene ikke er ekstra bruk av ChatGPT- / Codex-produktene, og at ubrukt saldo utløper (@jayzhoupro, @velcue_07, @_jayyy18_13k), undret seg over hvor mange kreditter som aldri blir brukt (@mohamedsenator), og meldte om Pro-brukere i Europa som ikke fikk hentet ut kredittene under fakturering (@ZindanTech).

Slik svarer PoYo: PoYo bruker forhåndsbetalte kreditter, ikke en månedlig rettighet som nullstilles. Forsiden oppgir kredittbaserte priser, ingen abonnementer og at kredittene aldri utløper. Du betaler bare for vellykkede genereringer; både llms.txt og forsiden sier at mislykkede oppgaver ikke belastes. Én saldo dekker hele katalogen – poll GET /api/user/balance for credits_amount i sanntid (brukersaldo). Når saldoen er tom, returnerer PoYo 402 insufficient_credits_error (feilkoder), ikke et «bruk dem eller mist dem»-vindu i kalenderen. Regionbegrensede prosesser for å hente ut kampanjekreditter hos en annen leverandør ligger utenfor PoYos produkt; fyll på i dashbordet når du trenger flere kreditter.

---

Q2. Hvis Chat, Work og Codex deler én bruks-pott, er det kodekvoten som dør først.

Dette klager utviklerne på: Den samme nyheten om API-kreditter vekket en annen frykt: Vil vanlig Chat- / Work-trafikk tømme den samme potten som Codex? Utviklere sa at de ville bruke ChatGPT mindre så det ikke gikk ut over Codex (@setHacked), hevdet at én felles bruksgrense i Anthropic-stil ville drepe Pro hos OpenAI (@macintoch), spurte om vanlig Chat ville holdes adskilt fra Work / Codex (@Paulkk144974), håpet at en sammenslått chat+work-pott ville la Codex være i fred (@raiden_fine), og diskuterte formuleringen «sluttet å ta betalt to ganger fra utviklere» i kunngjøringen om kredittene (@Awais786Muhamd).

Slik svarer PoYo: PoYo selger ingen abonnementspott for ChatGPT Pro / Codex, så det finnes ingen dokumentert «sammenslått produktkvote» som i det stille spiser av kodekapasiteten. Faktureringen er én kredittsaldo for bilde, video, musikk, 3D og chat (forside, llms.txt). Vil du ha isolasjon, oppretter du egne API-nøkler per arbeidslast og setter bruksgrenser per time / dag / totalt på hver nøkkel (Kom i gang, API-nøkkelside). For flere kunder eller flere agenter på én nøkkel sender du X-End-User-ID og blokkerer én misbrukende bruker med 403 end_user_blocked uten å rotere for alle (Identifisering av sluttbrukere). Følg med på den felles saldoen med GET /api/user/balance (brukersaldo); ved 402 stopper du og fyller på (feilkoder).

---

Q3. Veggene i Codex og kodeagenter er tilbake – forbruket spiste opp uken på noen timer.

Dette klager utviklerne på: Tidslinjene for kodeagenter fyltes igjen med innlegg om bruksvegger: å planlegge uken rundt enda en nullstilling av Codex-grensen (@GaryVSAISlop), meldinger om at Sol 6.1 via Codex CLI brant gjennom kvoten ~3× raskere på rundt 15 timer (@AssistBDA), og forventninger om at nyheten om API-kreditter ikke ville gi noen lettelse ved nullstilling (@snowy_smile_).

Slik svarer PoYo: Chat hos PoYo prises i kreditter per vellykket resultat, ikke med et rullerende nullstillingsvindu i Codex-stil (llms.txt, forside). Chatendepunktene er dokumentert som OpenAI-kompatible, Claude Messages eller Geminis egne; velg en modell-ID og les modellens gjeldende skjema på https://poyo.ai/models/<id>/llms.txt. Begrens en løpsk kodeagent med grenser per time / dag / totalt for hver nøkkel på API-nøkkelsiden (Kom i gang). Standard gjennomstrømning for generering er opptil 20 nye forespørsler per 10 sekunder per konto; overskytende forespørsler returnerer 429 og kommer ikke inn i køen (Kom i gang). Respekter Retry-After ved 429, og ikke prøv betalte innsendinger på nytt i blinde før du vet om det allerede finnes en task_id (feilsøking). Dokumentasjonen beskriver ingen automatisk failover til et annet laboratorium når et kodeverktøy oppstrøms treffer sin egen vegg – bygg det inn i klienten hvis du trenger det.

---

Q4. Jeg slettet API-nøkkelen fra repoet og pushet – den er nok fortsatt offentlig i git-historikken.

Dette klager utviklerne på: Et kort innlegg gikk rett på den klassiske lekkasjen: Nøkkelen ble fjernet fra arbeidskopien og pushet, men hemmeligheten er nesten helt sikkert fortsatt tilgjengelig i git-historikken (@patchnoteslabs).

Slik svarer PoYo: Kom i gang er kontant: Eksponer aldri API-nøkkelen i frontend-kode, mobilapper eller offentlige repoer, og behandle den som en hemmelighet. Hvis en PoYo-nøkkel kan ha havnet i git-historikken (eller noe annet offentlig sted):

1. Tilbakekall / roter den på API-nøkkelsiden – det holder ikke å slette kodelinjen.
2. Slå på en IP-hviteliste, slik at en kopiert nøkkel bare virker fra godkjente server-IP-er.
3. Sett tak per time / dag / totalt for hver nøkkel, slik at en gjenglemt hemmelighet har et tak.
4. Bruk helst X-End-User-ID ved generering og innebygd chat, slik at du kan blokkere én bruker med 403 end_user_blocked uten å rotere alle integrasjoner (Identifisering av sluttbrukere).

Den offentlige dokumentasjonen lover ikke refusjon for bruk med en lekket nøkkel. Kontakt [email protected] hvis du tror en PoYo-nøkkel er misbrukt (Kom i gang).

---

Q5. Verktøyet som lagret leverandørnøklene mine, ble hacket – ubrukt legitimasjon finansierte noen andres regning.

Dette klager utviklerne på: Et innlegg beskrev en API-nøkkel på en inaktiv konto pluss en svakhet i leverandørinnstillingene i Opik AI som førte til at 29 nøkler til OpenAI / Anthropic ble tatt (@AgentFieldKit). Mønsteret er kjent: Legitimasjon som ligger i et «AI-innstillinger»-grensesnitt hos en tredjepart, blir angriperens lommebok i det øyeblikket verten har en svakhet.

Slik svarer PoYo: Nøkler lagret i et annet produkts innstillinger er et problem med hemmeligheter på klientsiden. PoYos dokumenterte kontroller begrenser skadeomfanget når hemmeligheten først finnes:

• Opprett egne nøkler per miljø / oppsett, hver med bruksgrenser per time, per dag og totalt (API-nøkkelside, Kom i gang).
• Slå på en IP-tillatelsesliste for nøkler i produksjon.
• Bruk helst X-End-User-ID, slik at du kan blokkere én bruker uten å slette nøkkelen (Identifisering av sluttbrukere).
• Følg med på saldoen i sanntid med GET /api/user/balance (brukersaldo); ved 402 stopper du (feilkoder).

Slett nøkler du ikke lenger bruker. Dokumentasjonen beskriver verken automatisk utløp av ubrukte nøkler eller en refusjonsgaranti for forbruk etter innbrudd – det sier vi rett ut, og vi anbefaler rotering. Hold PoYo-nøklene på din egen server, ikke i en frontend eller et innstillingsskjema hos en tredjepart du har sluttet å følge med på (Kom i gang).

---

Q6. Agenten min kjørte i 30 timer – ingenting mellom koden og API-et hadde en grense den ikke ville krysse.

Dette klager utviklerne på: Én utvikler beskrev en agentkjøring på 30 timer der ingenting utenfor prosessen håndhevet et hardt forbrukstak – den harde grensen må ligge utenfor jobben (@asymmetricmind). Innlegg i samme periode argumenterte for resultatkort for forbruksstyring av agenter som går i løkke eller henter for mye (@hacker_no_ice).

Slik svarer PoYo: Myke varsler inne i agenten er ikke et budsjett. Hos PoYo legger du taket på legitimasjonen og saldoen:

• Bruksgrenser per nøkkel per time / dag / totalt på alle nøkler i produksjon (Kom i gang, API-nøkkelside).
• Kombiner med IP-hviteliste for nøkler som bare skal brukes fra server.
• Bruk X-End-User-ID + blokkering i apper med flere kunder eller flere agenter (Identifisering av sluttbrukere).
• Poll GET /api/user/balance før store batcher (brukersaldo); behandle 402 som en hard stopp, ikke et signal om å prøve igjen (feilkoder).
• For lange asynkrone jobber bør du bruke webhooks fremfor aggressiv polling (webhooks); Kom i gang advarer om at hvert nye innsendingsforsøk kan være nytt betalt arbeid – bekreft task_id før du sender inn på nytt (feilsøking).

Dokumentasjonen beskriver ingen «nødbryter» utenfor prosessen ut over disse nøkkeltakene, saldoen og feilkodene – koble orkestreringen din slik at den stopper ved 402 / nøkler som har nådd taket.

---

Q7. Det vanskeligste er ikke modellen – det er egne kontoer, API-nøkler og faktureringssystemer for hvert kreative API.

Dette klager utviklerne på: Skapere og utviklere sa at det smertefulle er å sjonglere egne kontoer, nøkler og fakturering hos hver leverandør (@CyberFree365). Andre beskrev marginene som et problem med API-regningen og så på åpne modeller via aggregatorer som en kostnadsspak (@RonaleK777), eller lette rett og slett etter et billig LLM-API i stor skala (@brice_garnier_).

Slik svarer PoYo: PoYo er bygd som én samlet nøkkel for bilde, video, musikk, 3D og chat (llms.txt, forside). Opprett en nøkkel på API-nøkkelsiden; medier bruker asynkron POST /api/generate/submit + status/webhook, og chat bruker OpenAI-kompatible endepunkter, Claude Messages eller Geminis egne endepunkter slik det er dokumentert per modell. Å bytte modell er en model-streng (og tilhørende endepunktformat for chat) – ikke en ny registreringsprosess hos en leverandør. Gjeldende inputskjemaer og priser ligger på https://poyo.ai/models/<id>/llms.txt og i katalogindeksen (llms.txt). Faktureringen skjer med forhåndsbetalte kreditter som aldri utløper, belastet per vellykket resultat (forside).

Dokumentasjonen hevder ikke at PoYo videreformidler hvert laboratoriums offisielle konto direkte; Kom i gang påpeker også at den samlede stabiliteten kan være litt lavere enn hos de offisielle leverandørene. Velg avveiningen bevisst.

---

Rask oversikt