Klachten die Engelstalige ontwikkelaars tussen 27 en 29 okt. 2026 openbaar plaatsten, hieronder in eigen woorden samengevat, met links naar de oorspronkelijke berichten. Elk antwoord gebruikt alleen wat de openbare website en documentatie van PoYo nu zeggen en verwijst naar de pagina waar het vandaan komt. Waar de documentatie iets niet behandelt, zeggen we dat.
Q1. Mijn maandelijkse API-credits van ChatGPT Pro / Business vervallen ongebruikt, en in sommige regio's kun je ze helemaal niet claimen.
Waar ontwikkelaars over klagen: Nadat OpenAI de prijs van Pro had voorgesteld als iets wat terugkomt als API-tegoed, vroegen bouwers meteen hoeveel van die pot aan het eind van de cyclus verloren gaat. In berichten stond dat de credits geen extra gebruik van ChatGPT / Codex zijn en dat ongebruikt saldo vervalt (@jayzhoupro, @velcue_07, @_jayyy18_13k), men vroeg zich hardop af hoeveel credits er ongebruikt blijven (@mohamedsenator), en er werd gewezen op Pro-gebruikers in Europa die de credits in de facturering niet konden claimen (@ZindanTech).
Zo antwoordt PoYo: PoYo werkt met vooruitbetaalde credits, niet met een maandelijks recht dat opnieuw begint. De homepage vermeldt prijzen op basis van credits, geen abonnementen en dat credits nooit verlopen. Je betaalt alleen voor geslaagde generaties; llms.txt en de homepage zeggen allebei dat mislukte taken niet worden berekend. Eén saldo dekt de hele catalogus: poll GET /api/user/balance voor het actuele credits_amount (gebruikerssaldo). Als het saldo op is, geeft PoYo 402 insufficient_credits_error terug (foutcodes), geen "gebruiken of verliezen"-kalendervenster. Claimprocedures per regio voor de promotiecredits van een andere leverancier vallen buiten het product van PoYo; waardeer op in het dashboard als je meer credits nodig hebt.
Q2. Als Chat, Work en Codex één gebruikspot delen, is het codeerquotum als eerste op.
Waar ontwikkelaars over klagen: Hetzelfde nieuws over API-credits bracht een andere angst naar boven: gaat het gewone Chat- / Work-verkeer uit dezelfde bak putten als Codex? Bouwers zeiden ChatGPT minder te gaan gebruiken om Codex niet te raken (@setHacked), stelden dat één gebruikslimiet in Anthropic-stijl Pro voor OpenAI zou doden (@macintoch), vroegen of gewone Chat los zou blijven van Work / Codex (@Paulkk144974), hoopten dat een samengevoegde chat+work-pot Codex met rust zou laten (@raiden_fine) en bediscussieerden de formulering "bouwers niet meer twee keer laten betalen" in de aankondiging over de credits (@Awais786Muhamd).
Zo antwoordt PoYo: PoYo verkoopt geen pot voor een ChatGPT Pro- / Codex-abonnement, dus er is geen gedocumenteerd "samengevoegd productquotum" dat ongemerkt je codeerruimte opeet. De facturering loopt via één creditsaldo voor afbeeldingen, video, muziek, 3D en chat (homepage, llms.txt). Wil je isolatie, maak dan aparte API-sleutels per workload en zet gebruikslimieten per uur / dag / in totaal op elke sleutel (Getting Started, API-sleutelpagina). Voor aanroepers met meerdere tenants of meerdere agents op één sleutel stuur je X-End-User-ID mee en blokkeer je één misbruikende aanroeper met 403 end_user_blocked, zonder iedereen te roteren (Identificatie van eindgebruikers). Houd het gedeelde saldo in de gaten met GET /api/user/balance (gebruikerssaldo); stop bij een 402 en waardeer op (foutcodes).
Q3. De muren van Codex en codeeragents zijn terug: het verbruik maakte de week in een paar uur op.
Waar ontwikkelaars over klagen: De tijdlijnen van codeeragents stonden weer vol met berichten over gebruiksmuren: de week plannen rond alweer een reset van de Codex-limiet (@GaryVSAISlop), melden dat Sol 6.1 via de Codex CLI in ongeveer 15 uur ~3× sneller door het quotum ging (@AssistBDA), en geen verlichting van de reset verwachten door het nieuws over API-credits (@snowy_smile_).
Zo antwoordt PoYo: Chat bij PoYo wordt per geslaagde uitvoer in credits berekend, niet via een doorlopend resetvenster in Codex-stijl (llms.txt, homepage). De chat-endpoints zijn gedocumenteerd als OpenAI-compatibel, Claude Messages of Gemini-native; kies een model-ID en lees het actuele schema van dat model op https://poyo.ai/models/<id>/llms.txt. Houd een op hol geslagen codeeragent in toom met limieten per sleutel per uur / dag / in totaal op de API-sleutelpagina (Getting Started). De standaarddoorvoer voor generaties is maximaal 20 nieuwe verzoeken per 10 seconden per account; verzoeken daarboven krijgen 429 en komen niet in de wachtrij (Getting Started). Houd je bij een 429 aan Retry-After; probeer betaalde indieningen niet blindelings opnieuw voordat je weet of er al een task_id bestaat (troubleshooting). De documentatie beschrijft geen automatische failover naar een ander lab als een upstream-codeertool tegen zijn eigen muur aanloopt; bouw dat zelf in je client als je het nodig hebt.
Q4. Ik heb de API-sleutel uit de repo verwijderd en gepusht, maar hij staat waarschijnlijk nog openbaar in de git-geschiedenis.
Waar ontwikkelaars over klagen: Een kort bericht ging recht op het klassieke lek af: de sleutel was uit de werkmap verwijderd en gepusht, maar het geheim is vrijwel zeker nog bereikbaar in de git-geschiedenis (@patchnoteslabs).
Zo antwoordt PoYo: Getting Started is ondubbelzinnig: zet je API-sleutel nooit in frontendcode, mobiele apps of openbare repositories en behandel hem als een geheim. Als een PoYo-sleutel in de git-geschiedenis (of ergens anders openbaar) terecht kan zijn gekomen:
- Trek hem in of roteer hem op de API-sleutelpagina; de regel code verwijderen is niet genoeg.
- Zet een IP-whitelist aan, zodat een gekopieerde sleutel alleen werkt vanaf goedgekeurde server-IP's.
- Stel limieten per sleutel per uur / dag / in totaal in, zodat een rondzwervend geheim een plafond heeft.
- Gebruik bij voorkeur
X-End-User-IDbij generatie en native chat, zodat je één aanroeper met 403end_user_blockedkunt blokkeren zonder elke integratie te roteren (Identificatie van eindgebruikers).
De openbare documentatie belooft geen terugbetaling voor gebruik met een gelekte sleutel. Neem contact op met [email protected] als je denkt dat een PoYo-sleutel is misbruikt (Getting Started).
Q5. De tool waarin mijn aanbiedersleutels stonden is gehackt: inactieve inloggegevens financierden andermans rekening.
Waar ontwikkelaars over klagen: Een bericht beschreef een API-sleutel van een inactief account plus een fout in de aanbiedersinstellingen van Opik AI, waardoor 29 OpenAI- / Anthropic-sleutels werden buitgemaakt (@AgentFieldKit). Het patroon is bekend: inloggegevens die in de "AI-instellingen" van een externe tool staan, worden de portemonnee van een aanvaller zodra die host niet deugt.
Zo antwoordt PoYo: Sleutels die in de instellingen van een ander product staan, zijn een geheimenprobleem aan de clientzijde. De gedocumenteerde instellingen van PoYo beperken de schade zodra een geheim bestaat:
- Maak aparte sleutels per omgeving / harness, elk met gebruikslimieten per uur, per dag en in totaal (API-sleutelpagina, Getting Started).
- Schakel een IP-allowlist in voor productiesleutels.
- Gebruik bij voorkeur
X-End-User-ID, zodat je één aanroeper kunt blokkeren zonder de sleutel te verwijderen (Identificatie van eindgebruikers). - Houd het actuele saldo in de gaten met
GET /api/user/balance(gebruikerssaldo); stop bij een 402 (foutcodes).
Verwijder sleutels die je niet meer gebruikt. De documentatie beschrijft geen automatische verloopdatum voor ongebruikte sleutels en geen SLA voor terugbetaling van verbruik na een inbraak. Ga daar dus niet van uit en roteer. Bewaar PoYo-sleutels op jouw server, niet in een frontend of een instellingenformulier van een derde partij waar je geen oog meer op houdt (Getting Started).
Q6. Mijn agent draaide 30 uur: tussen de code en de API zat niets met een grens die niet te overschrijden was.
Waar ontwikkelaars over klagen: Een bouwer beschreef een agent die 30 uur draaide zonder dat iets buiten het proces een hard bestedingsplafond afdwong: de harde limiet moet buiten de taak liggen (@asymmetricmind). Berichten in de buurt pleitten voor scorecards voor bestedingsbeheer bij agents die in een lus lopen of te veel ophalen (@hacker_no_ice).
Zo antwoordt PoYo: Zachte waarschuwingen binnen de agent zijn geen budget. Leg bij PoYo het plafond op het inloggegeven en het saldo:
- Gebruikslimieten per sleutel per uur / dag / in totaal op elke productiesleutel (Getting Started, API-sleutelpagina).
- Combineer dat met een IP-whitelist voor sleutels die alleen op servers worden gebruikt.
- Gebruik
X-End-User-ID+ blokkeren voor apps met meerdere tenants of meerdere agents (Identificatie van eindgebruikers). - Poll
GET /api/user/balancevoordat je grote batches start (gebruikerssaldo); behandel 402 als een harde stop, niet als signaal om opnieuw te proberen (foutcodes). - Gebruik bij lange asynchrone taken liever webhooks dan agressief pollen (webhooks); Getting Started waarschuwt dat elke nieuwe poging nieuw betaald werk kan zijn. Controleer de
task_idvoordat je opnieuw indient (troubleshooting).
De documentatie claimt geen noodstopproduct buiten het proces, naast deze sleutellimieten, het saldo en de foutcodes. Laat je orchestrator dus zelf stoppen bij 402 of bij sleutels die hun limiet hebben bereikt.
Q7. Het lastigste is niet het model, maar de aparte accounts, API-sleutels en factureringssystemen voor elke creatieve API.
Waar ontwikkelaars over klagen: Makers en bouwers zeiden dat het pijnlijke deel het jongleren met aparte leveranciersaccounts, sleutels en facturering is (@CyberFree365). Anderen zagen de marges als een probleem van de API-rekening en keken naar open modellen via aggregators als hefboom voor de kosten (@RonaleK777), of zochten gewoon een goedkope LLM-API op schaal (@brice_garnier_).
Zo antwoordt PoYo: PoYo is gebouwd als één uniforme sleutel voor afbeeldingen, video, muziek, 3D en chat (llms.txt, homepage). Maak een sleutel aan op de API-sleutelpagina; media gebruikt de asynchrone POST /api/generate/submit + status/webhook; chat gebruikt OpenAI-compatibele, Claude Messages- of Gemini-native endpoints, zoals per model gedocumenteerd. Van model wisselen is een andere model-string (en bij chat de bijbehorende vorm van het endpoint), geen nieuw onboardingtraject bij een andere leverancier. De actuele invoerschema's en prijzen staan op https://poyo.ai/models/<id>/llms.txt en in de catalogusindex (llms.txt). De facturering werkt met vooruitbetaalde credits die nooit verlopen, berekend per geslaagde uitvoer (homepage).
De documentatie beweert niet dat PoYo een doorgeefluik is naar het officiële account van elk lab; Getting Started merkt ook op dat de algehele stabiliteit iets lager kan liggen dan bij de officiële aanbieders. Maak die afweging bewust.
Snel overzicht
| Klacht | Waar PoYo het documenteert |
|---|---|
| Maandelijkse Pro-API-credits die vervallen / regio's waar je ze niet kunt claimen | Homepage: credits verlopen nooit · Saldo-API · Foutcodes: 402 |
| Angst dat samengevoegde Chat/Work/Codex-potten het codeerquotum opeten | Eén creditsaldo · Aparte sleutels + limieten · X-End-User-ID · Saldo-API |
| Gebruiksmuren en verbruik bij Codex / codeeragents | llms.txt chat · Limieten per sleutel · 429 + Retry-After · geen gedocumenteerde automatische failover |
| Verwijderde sleutel staat nog in de git-geschiedenis | Getting Started: sleutel nooit blootstellen · Roteren op de API-sleutelpagina · IP-whitelist · limieten |
| Tools waarin aanbiedersleutels staan worden gehackt | Aparte sleutels + limieten · IP-whitelist · X-End-User-ID · ongebruikte intrekken · geen SLA voor terugbetaling |
| Agents zonder harde bestedingslimiet buiten het proces | Limieten per sleutel · Saldo + 402 · Webhooks · nieuwe poging kan nieuw betaald werk zijn |
| Wildgroei aan sleutels bij creatieve API's / aparte facturering per leverancier | Eén PoYo-sleutel · llms.txt-catalogus · llms.txt per model · credits verlopen nooit |