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

Klager, som engelsksprogede udviklere postede offentligt mellem 27. og 29. okt. 2026, gengivet med egne ord nedenfor og med links til de oprindelige opslag. Hvert svar bruger kun det, PoYos offentlige hjemmeside og dokumentation siger i dag, og linker til den side, det stammer fra. Hvor dokumentationen ikke dækker noget, siger vi det.

---

Q1. Mine månedlige API-kreditter fra ChatGPT Pro / Business udløber ubrugte – og nogle regioner kan slet ikke indløse dem.

Det klager udviklerne over: Efter at OpenAI præsenterede Pro-prisen som noget, der kommer tilbage som API-kredit, spurgte udviklere straks, hvor stor en del af puljen der dør ved periodens udgang. Opslag bemærkede, at kreditterne ikke er ekstra brug af ChatGPT / Codex som produkt, og at ubrugt saldo udløber (@jayzhoupro, @velcue_07, @_jayyy18_13k), undrede sig højt over, hvor mange kreditter der går ubrugt hen (@mohamedsenator), og pegede på Pro-brugere i Europa, der ikke kunne indløse kreditterne under fakturering (@ZindanTech).

Sådan svarer PoYo: PoYo er forudbetalte kreditter, ikke en månedlig ret, der nulstilles. Forsiden angiver kreditbaseret prissætning, ingen abonnementer, og at kreditter aldrig udløber. Du betaler kun for vellykkede genereringer; både llms.txt og forsiden oplyser, at mislykkede opgaver ikke afregnes. Én saldo dækker hele kataloget – poll GET /api/user/balance for aktuelle credits_amount (brugersaldo). Når saldoen er brugt op, returnerer PoYo 402 insufficient_credits_error (fejlkoder) – ikke et "brug det, ellers mist det"-kalendervindue. Regionsbegrænsede indløsningsflows for en anden leverandørs kampagnekreditter ligger uden for PoYos produkt; fyld op i dashboardet, når du har brug for flere kreditter.

---

Q2. Hvis Chat, Work og Codex deler én forbrugspulje, dør kodekvoten først.

Det klager udviklerne over: Den samme nyhed om API-kreditter vakte en anden frygt: vil almindelig Chat- / Work-trafik æde af den samme spand som Codex? Udviklere sagde, at de ville bruge ChatGPT mindre, så det ikke gik ud over Codex (@setHacked), mente, at en enkelt forbrugsgrænse i Anthropic-stil ville slå Pro ihjel for OpenAI (@macintoch), spurgte, om almindelig Chat ville forblive adskilt fra Work / Codex (@Paulkk144974), ønskede, at en sammenlagt chat+work-pulje ville lade Codex være i fred (@raiden_fine), og diskuterede formuleringen "holdt op med at tage betalt to gange af udviklere" i annonceringen af kreditterne (@Awais786Muhamd).

Sådan svarer PoYo: PoYo sælger ikke en ChatGPT Pro- / Codex-abonnementspulje, så der findes ingen dokumenteret "sammenlagt produktkvote", der i det skjulte æder kodekapaciteten. Fakturering sker med én kreditsaldo på tværs af billeder, video, musik, 3D og chat (forsiden, llms.txt). Hvis du vil have isolation, så opret separate API-nøgler pr. arbejdsbelastning og sæt timegrænser, døgngrænser og samlede forbrugsgrænser på hver nøgle (Kom i gang, siden med API-nøgler). For multi-tenant- eller multiagent-kaldere på én nøgle skal du sende X-End-User-ID og blokere én misbrugende kalder med 403 end_user_blocked uden at rotere for alle (identifikation af slutbrugere). Hold øje med den delte saldo med GET /api/user/balance (brugersaldo); ved 402 skal du stoppe og fylde op (fejlkoder).

---

Q3. Væggene i Codex og kodeagenter er tilbage – forbrugstempoet åd ugen på få timer.

Det klager udviklerne over: Tidslinjerne for kodeagenter blev igen fyldt med opslag om forbrugsvægge: man planlagde ugen omkring endnu en nulstilling af Codex-grænsen (@GaryVSAISlop), meldte, at Sol 6.1 via Codex CLI brændte kvoten af ca. 3 gange hurtigere på omkring 15 timer (@AssistBDA), og regnede ikke med nogen lettelse i nulstillingen på grund af nyheden om API-kreditter (@snowy_smile_).

Sådan svarer PoYo: PoYo-chat er prissat i kreditter pr. vellykket resultat, ikke et glidende nulstillingsvindue i Codex-stil (llms.txt, forsiden). Chat-endpoints er dokumenteret som OpenAI-kompatible, Claude Messages eller Gemini-native; vælg et model-ID, og læs modellens aktuelle skema på https://poyo.ai/models/<id>/llms.txt. Sæt et loft på en løbsk kodeagent med timegrænser, døgngrænser og samlede grænser pr. nøgle på siden med API-nøgler (Kom i gang). Standardgennemstrømningen for generering er op til 20 nye anmodninger pr. 10 sekunder pr. konto; overskydende anmodninger returnerer 429 og kommer ikke i køen (Kom i gang). Respektér Retry-After ved 429; prøv ikke blindt igen med betalte indsendelser, før du ved, om der allerede findes en task_id (fejlfinding). Dokumentationen beskriver ingen automatisk failover til et andet lab, når et upstream-kodeværktøj rammer sin egen væg – byg det ind i din klient, hvis du har brug for det.

---

Q4. Jeg slettede API-nøglen fra repoet og pushede – den ligger sikkert stadig offentligt i git-historikken.

Det klager udviklerne over: Et kort opslag pegede på den klassiske lækage: nøglen var fjernet fra arbejdskopien og pushet, men hemmeligheden kan næsten helt sikkert stadig nås i git-historikken (@patchnoteslabs).

Sådan svarer PoYo: Kom i gang er ligefrem: eksponér aldrig din API-nøgle i frontend-kode, mobilapps eller offentlige repositories, og behandl den som en hemmelighed. Hvis en PoYo-nøgle kan være havnet i git-historikken (eller et andet offentligt sted):

1. Tilbagekald / roter den på siden med API-nøgler – det er ikke nok at slette kodelinjen.
2. Slå en IP-hvidliste til, så en kopieret nøgle kun virker fra godkendte server-IP'er.
3. Sæt timegrænser / døgngrænser / samlede grænser pr. nøgle, så en hemmelighed, der bliver liggende, har et loft.
4. Foretræk X-End-User-ID ved generering og native chat, så du kan blokere én kalder med 403 end_user_blocked uden at rotere alle integrationer (identifikation af slutbrugere).

Den offentlige dokumentation lover ikke refundering for forbrug med en lækket nøgle. Kontakt [email protected], hvis du mener, at en PoYo-nøgle er blevet misbrugt (Kom i gang).

---

Q5. Værktøjet, der opbevarede mine udbydernøgler, blev brudt – inaktive legitimationer finansierede en andens regning.

Det klager udviklerne over: Et opslag beskrev en API-nøgle til en inaktiv konto plus en fejl i Opik AI's udbyderindstillinger, der førte til, at 29 OpenAI- / Anthropic-nøgler blev taget (@AgentFieldKit). Mønstret er velkendt: legitimationer, der ligger i en tredjeparts "AI-indstillinger"-brugerflade, bliver en angribers pung i det øjeblik, hosten er forkert.

Sådan svarer PoYo: Nøgler, der opbevares i et andet produkts indstillinger, er et hemmelighedsproblem hos klienten. PoYos dokumenterede kontroller begrænser skadens omfang, når en hemmelighed først er ude:

• Opret separate nøgler pr. miljø / harness, hver med timegrænser, døgngrænser og samlede forbrugsgrænser (siden med API-nøgler, Kom i gang).
• Aktivér en IP-tilladelsesliste for produktionsnøgler.
• Foretræk X-End-User-ID, så du kan blokere én kalder uden at slette nøglen (identifikation af slutbrugere).
• Hold øje med den aktuelle saldo med GET /api/user/balance (brugersaldo); ved 402 skal du stoppe (fejlkoder).

Slet nøgler, du ikke bruger længere. Dokumentationen beskriver hverken automatisk udløb af ubrugte nøgler eller en SLA for refundering af forbrug efter brud – sig det, som det er, og roter. Hold PoYo-nøgler på din server, ikke i en frontend eller en tredjepartsformular med indstillinger, du er holdt op med at holde øje med (Kom i gang).

---

Q6. Min agent kørte i 30 timer – intet mellem koden og API'en havde et tal, den ikke ville krydse.

Det klager udviklerne over: En udvikler beskrev en agentkørsel på 30 timer, hvor intet uden for processen håndhævede et hårdt forbrugsloft – den hårde grænse skal sidde uden for jobbet (@asymmetricmind). Nærliggende opslag pegede på scorecards til styring af forbrug for agenter, der kører i løkker eller henter for meget (@hacker_no_ice).

Sådan svarer PoYo: Bløde advarsler inde i agenten er ikke et budget. Hos PoYo skal du lægge loftet på legitimationen og saldoen:

• Forbrugsgrænser pr. nøgle (pr. time, pr. døgn og samlet) på hver produktionsnøgle (Kom i gang, siden med API-nøgler).
• Kombinér med IP-hvidliste til nøgler, der kun bruges på servere.
• Brug X-End-User-ID + blokering til multi-tenant- eller multiagent-apps (identifikation af slutbrugere).
• Poll GET /api/user/balance før store batches (brugersaldo); behandl 402 som et hårdt stop, ikke et signal om at prøve igen (fejlkoder).
• Til lange asynkrone jobs foretrækkes webhooks frem for aggressiv polling (webhooks); Kom i gang advarer om, at hvert genforsøg med indsendelse kan være nyt betalt arbejde – bekræft task_id, før du sender igen (fejlfinding).

Dokumentationen påstår ikke, at der findes et "kill switch"-produkt uden for processen ud over disse nøglegrænser, saldoen og fejlkoderne – få din orkestrator til at stoppe ved 402 / nøgler, der har ramt loftet.

---

Q7. Det sværeste er ikke modellen – det er separate konti, API-nøgler og faktureringssystemer til hver eneste kreative API.

Det klager udviklerne over: Skabere og udviklere sagde, at det smertefulde er at jonglere med separate udbyderkonti, nøgler og fakturering (@CyberFree365). Andre beskrev avancerne som et API-regningsproblem og så på åbne modeller via aggregatorer som en løftestang for omkostningerne (@RonaleK777) eller ledte simpelthen efter en billig LLM-API i stor skala (@brice_garnier_).

Sådan svarer PoYo: PoYo er bygget som én samlet nøgle på tværs af billeder, video, musik, 3D og chat (llms.txt, forsiden). Opret en nøgle på siden med API-nøgler; medier bruger asynkron POST /api/generate/submit + status/webhook; chat bruger OpenAI-kompatible endpoints, Claude Messages eller Gemini-native endpoints som dokumenteret pr. model. Et modelskifte er en model-streng (og den tilhørende endpoint-form til chat) – ikke en ny oprettelse hos en ny leverandør. Aktuelle inputskemaer og priser findes på https://poyo.ai/models/<id>/llms.txt og i katalogindekset (llms.txt). Fakturering sker med forudbetalte kreditter, der aldrig udløber, og der afregnes pr. vellykket resultat (forsiden).

Dokumentationen påstår ikke, at PoYo blot videresender hvert labs officielle konto; Kom i gang bemærker også, at den samlede stabilitet kan være en smule lavere end hos de officielle udbydere. Vælg afvejningen bevidst.

---

Hurtigt overblik