Klachten die Engelstalige ontwikkelaars tussen 26 en 28 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. Claude Code liep midden in een refactor tegen de gebruikslimiet aan, en er is nog steeds geen nette route om terug te vallen op mijn API-sleutel.
Waar ontwikkelaars over klagen: De tijdlijnen van 27–28 okt. stonden vol met screenshots van gebruikslimieten van Claude Code en Codex naast elkaar. Bouwers vroegen of Claude Code kan terugvallen op een API-sleutel zodra de limieten van het abonnement zijn bereikt (@irl_danB), grapten dat een limiet midden in een refactor het nieuwe "vergeten op te slaan" is (@automater_ai), en vergeleken abonnementen van $20 die op de ene stack nutteloos aanvoelen terwijl een ander Plus-abonnement nooit een grens raakt (@mozdca, @LeoZhang57).
Zo antwoordt PoYo: PoYo werkt met vooruitbetaalde credits, niet met een abonnementsvenster van 5 uur of een week. De homepage beschrijft eenmalige aankopen van credits, geen terugkerende abonnementen en credits die nooit verlopen. Je betaalt voor geslaagde generaties; llms.txt vermeldt dat mislukte taken niet worden berekend. Chat en media delen één API-sleutel en één saldo: poll GET /api/user/balance voor het actuele credits_amount (gebruikerssaldo).
Als het saldo op is, geeft PoYo 402 insufficient_credits_error terug, geen doorlopend gebruiksvenster dat zich als vertraging voordoet (foutcodes). Er is geen gedocumenteerde productfunctie voor failover van abonnement naar API-sleutel, omdat de facturering al op credits is gebaseerd. Houd een op hol geslagen agent in toom met de gebruikslimieten per sleutel (per uur, per dag en in totaal) op de API-sleutelpagina (Getting Started).
Q2. De "429" van Claude Code zijn drie verschillende meldingen, en eindeloos wachten helpt maar bij één ervan.
Waar ontwikkelaars over klagen: In een troubleshooting-thread werd erop gewezen dat Claude Code drie verschillende fouten in de vorm van een 429 kan tonen (wacht op een reset, probeer het zo opnieuw, of controleer de API-sleutel) en dat elk een andere oplossing vraagt (@aiparabellum). Los daarvan vroegen bouwers of de rate-limitproblemen in de agent-tooling van Anthropic al waren opgelost (@XavierDelon, @GeorgeMathew_).
Zo antwoordt PoYo: Onze foutcodes houden facturering en rate limits op verschillende nummers:
| Code | error.type | Betekenis / wat je moet doen |
|---|---|---|
| 401 | authentication_error | Ongeldige of ontbrekende sleutel. Herstel het inloggegeven; probeer niet opnieuw met dezelfde foute sleutel (Getting Started). |
| 402 | insufficient_credits_error | Je saldo is op. Waardeer op. Opnieuw proberen helpt niet. |
| 429 | rate_limit_error | Rate limit. Wacht of zet in de wachtrij. |
| 500 / 502 / 503 | internal_error / upstream_error / service_error | Exponentiële backoff. |
De standaarddoorvoer voor generaties is gedocumenteerd als maximaal 20 nieuwe verzoeken per 10 seconden per account; verzoeken daarboven krijgen HTTP 429 en komen niet in de wachtrij (Getting Started). De troubleshooting voor integraties zegt ook: houd je aan Retry-After bij rate limits en probeer een betaalde indiening niet blindelings opnieuw voordat je weet of er een task_id is aangemaakt (troubleshooting).
De documentatie beschrijft geen automatische failover tussen upstream-aanbieders. Bouw die zelf in je client.
Q3. Elke API-sleutel die ik ooit in de agentchat heb geplakt, staat nog steeds in de projectlogs.
Waar ontwikkelaars over klagen: Na een thread over de projectlogs van Claude legde één reactie het risico bloot: elke API-sleutel die je ooit in de chat hebt geplakt, staat ook in die logs. Zoek in ~/.claude/projects naar sk- en roteer alles wat je vindt (@wazX_7). Berichten in de buurt bleven dezelfde hygiëne bepleiten: behandel AI-sleutels als root-inloggegevens (@RuntimeAI_io) en geef niet elke agent dezelfde gedeelde sleutel zonder noodstop (@RohanBhanotAI).
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. Bewaar sleutels op je server. Na het plakken of bij een vermoeden van een lek:
- Trek de sleutel in of roteer hem op de API-sleutelpagina.
- IP-whitelist, zodat een gekopieerde sleutel alleen werkt vanaf goedgekeurde server-IP's.
- Limieten per sleutel per uur / dag / in totaal, zodat een lek een plafond heeft.
- Stuur
X-End-User-IDmee bij generatie en native chat; blokkeer één misbruikende aanroeper met HTTP 403end_user_blockedzonder de hele sleutel te roteren (Identificatie van eindgebruikers).
Onze 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.
Q4. Mijn vergeten aggregator-sleutel is nog steeds een agentportemonnee: een hostinbraak maakte van ongebruikte inloggegevens een taak van 500 stappen.
Waar ontwikkelaars over klagen: Een bericht waarschuwde dat een vergeten OpenRouter-sleutel nog steeds een agentportemonnee is: bij een inbraak in de stijl van Railway belandden ongebruikte sleutels op een afschietlijst, en één sleutel had al een agenttaak van 500 stappen gefinancierd terwijl de dashboards tot dat moment geen verkeer lieten zien. De genoemde oplossing: bestedingslimieten, kortlevende sleutels en geen aanbiedertokens op hosts waar je geen oog meer op houdt (@neiro_go_neiro). Een andere reactie koppelde hetzelfde patroon aan aanbieders die sleutels weken na inbraken nog steeds intrekken (@Kenz_1604).
Zo antwoordt PoYo: Ongebruikte sleutels op verlaten hosts 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).
- Zet een IP-allowlist aan 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) en de takengeschiedenis in het dashboard (Getting Started).
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.
Q5. Ik stelde een harde AI-bestedingslimiet in, en toen kwam iemand aan de sleutel en overschreed die in één nacht.
Waar ontwikkelaars over klagen: Eén bouwer stelde een AI-rekening van maximaal $25 in; iemand kreeg de API-sleutel in handen en liet de rekening in één nacht oplopen tot $55 (@twentyonemilll). Het thema past bij oudere OpenRouter-threads waarin uitschakelen niet genoeg was en alleen het volledig verwijderen van de sleutel het lek dichtte, maar ook in de periode rond 28 okt. blijft dezelfde klacht verschijnen: "het plafond bestond, het lek deed toch pijn".
Zo antwoordt PoYo: Limieten helpen alleen als ze worden afgedwongen op het gecompromitteerde inloggegeven, niet alleen op een zacht budget in een dashboard. Bij PoYo:
- Zet per sleutel gebruikslimieten per uur / dag / in totaal op elke productiesleutel (Getting Started, API-sleutelpagina).
- Combineer dat met een IP-whitelist, zodat de sleutel vanaf het netwerk van de aanvaller niet werkt.
- Gebruik
X-End-User-ID+ blokkeren voor apps met meerdere tenants (Identificatie van eindgebruikers). - Stop bij een 402: dan zijn je credits op (foutcodes). Poll het saldo voordat je grote batches start (gebruikerssaldo).
Als een sleutel mogelijk is uitgelekt, verwijder of trek hem dan in; verlaag niet alleen een zachte waarschuwing. De openbare documentatie claimt geen terugbetaling voor verbruik met een gelekte sleutel.
Q6. Een Google API-sleutel krijgen is zo lastig dat "gebruik gewoon een aggregator" de standaard werd.
Waar ontwikkelaars over klagen: Een ontwikkelaar zei Google-modellen alleen te willen proberen als het aanmeldproces voor de API-sleutel wordt verbeterd; tot die tijd is het alleen OpenRouter (@sandipb). Berichten in de buurt zagen aggregators steeds als de betaalportemonnee en modelschakelaar voor agents (@tomcritchlow), terwijl anderen nog steeds een dozijn sleutels van verschillende leveranciers moeten beheren om iets te testen (@sunwei57247249).
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 documentatie beweert niet dat PoYo een doorgeefluik is naar het officiële account van elk lab; ze zegt ook dat de algehele stabiliteit iets lager kan liggen dan bij de officiële aanbieders (Getting Started). Maak die afweging bewust.
Q7. Een videoabonnement van $59 is de dure weg als ik maar een paar clips lever, en nieuwe pogingen kunnen een tweede rekening veroorzaken.
Waar ontwikkelaars over klagen: Makers vergeleken maandelijkse abonnementen van videotools met API's waarbij je per clip betaalt: wie maar een paar AI-video's per maand maakt, is met een abonnement van $59 duur uit, terwijl een API per clip factureert en codeeragents hem kunnen aansturen (@aliteqai). Gerelateerde API-ergernis: downloads van voltooide video's die pas beschikbaar komen na afronding van de facturering (@MariaOnchainDev), en de blijvende angst dat blinde nieuwe pogingen een tweede betaalde taak aanmaken.
Zo antwoordt PoYo: Video wordt bij PoYo per geslaagde uitvoer in credits berekend, model voor model. Bekijk de videocatalogus in llms.txt (Sora 2, Veo 3.1, Kling, Wan, Seedance, Hailuo en meer). De werkwijze is de uniforme asynchrone API: indienen → de status pollen of een callback_url instellen (Getting Started, webhooks). Zowel de homepage als llms.txt vermelden dat mislukte taken niet worden berekend.
Voordat je op opnieuw probeert hamert bij een trage videotaak: Getting Started waarschuwt dat elke nieuwe poging nieuw betaald werk kan zijn. Controleer of het oorspronkelijke verzoek al een task_id heeft aangemaakt. Gebruik liever webhooks dan agressief pollen. Volg bij 402, 429 en 5xx de tabel met foutcodes; behandel een creditstop niet als een rate limit.
Snel overzicht
| Klacht | Waar PoYo het documenteert |
|---|---|
| Muren van gebruikslimieten / geen failover van abonnement naar API | Homepage: credits · Saldo-API · Foutcodes: 402 · Limieten per API-sleutel |
| 429 met drie verschillende betekenissen | Foutcodes: 401 / 402 / 429 / 5xx · Getting Started: rate limits · Troubleshooting |
| Sleutels geplakt in agentlogs | Getting Started: sleutel nooit blootstellen · API-sleutelpagina · X-End-User-ID |
| Ongebruikte aggregator-sleutels na hostinbraken | Limieten per API-sleutel · IP-whitelist · Saldo + takengeschiedenis · ongebruikte sleutels intrekken |
| Bestedingslimiet omzeild met een gelekte sleutel | Limieten per sleutel · IP-whitelist · X-End-User-ID · afhandeling van 402 |
| Lastige onboarding van aanbiedersleutels / wildgroei aan sleutels | Eén PoYo-sleutel · llms.txt-catalogus · llms.txt per model |
| Videoabonnement versus per clip + facturering bij nieuwe pogingen | Videocatalogus · asynchroon indienen/status · mislukt wordt niet berekend · nieuwe poging = nieuw betaald werk |