Beschwerden, die englischsprachige Entwickler zwischen dem 27. und 29. Oktober 2026 öffentlich gepostet haben, hier zusammengefasst mit Links zu den Originalbeiträgen. Jede Antwort verwendet nur das, was die öffentliche Website und die Dokumentation von PoYo heute sagen, und verlinkt die jeweilige Seite. Wo die Dokumentation etwas nicht abdeckt, sagen wir das.
Q1. Meine monatlichen ChatGPT-Pro- / Business-API-Credits verfallen ungenutzt — und manche Regionen können sie gar nicht einlösen.
Was Entwickler beanstanden: Nachdem OpenAI den Pro-Preis als Rückfluss in API-Credits beschrieben hatte, fragten Entwickler sofort, wie viel von diesem Pool am Zyklusende verfällt. Beiträge hielten fest, dass die Credits keine zusätzliche Produktnutzung von ChatGPT / Codex sind und dass ungenutztes Guthaben verfällt (@jayzhoupro, @velcue_07, @_jayyy18_13k), fragten laut, wie viele Credits ungenutzt bleiben (@mohamedsenator), und wiesen auf Pro-Nutzer in Europa hin, die die Credits in der Abrechnung nicht einlösen konnten (@ZindanTech).
Wie PoYo antwortet: PoYo sind Prepaid-Credits, kein monatlicher Anspruch, der sich zurücksetzt. Die Startseite nennt creditbasierte Preise, keine Abonnements und dass Credits nie verfallen. Sie zahlen nur für erfolgreiche Generierungen. llms.txt und die Startseite sagen beide, fehlgeschlagene Aufgaben werden nicht berechnet. Ein Guthaben deckt den Katalog ab. Für ein aktuelles credits_amount fragen Sie GET /api/user/balance ab (Nutzerguthaben). Ist das Guthaben aufgebraucht, gibt PoYo 402 insufficient_credits_error zurück (Fehlercodes), kein Kalenderfenster nach dem Motto „nutzen oder verlieren“. Regionale Einlöseabläufe für Aktionscredits eines anderen Anbieters liegen außerhalb des Produkts von PoYo. Laden Sie im Dashboard auf, wenn Sie mehr Credits brauchen.
Q2. Teilen sich Chat, Work und Codex einen Nutzungspool, stirbt das Coding-Kontingent zuerst.
Was Entwickler beanstanden: Dieselbe Nachricht zu API-Credits weckte eine andere Furcht: Verbrennt alltäglicher Chat- / Work-Verkehr denselben Topf wie Codex? Entwickler sagten, sie würden ChatGPT weniger nutzen, damit es Codex nicht berührt (@setHacked), argumentierten, ein einziges Nutzungslimit im Stil von Anthropic würde Pro für OpenAI beenden (@macintoch), fragten, ob normaler Chat von Work / Codex getrennt bleibt (@Paulkk144974), wünschten, ein zusammengelegter chat+work-Pool ließe Codex in Ruhe (@raiden_fine), und debattierten die Formulierung der Credit-Ankündigung, man habe aufgehört, Entwickler doppelt zu berechnen (@Awais786Muhamd).
Wie PoYo antwortet: PoYo verkauft keinen Abonnementpool für ChatGPT Pro / Codex. Eine dokumentierte „zusammengelegte Produktquote“, die still den Spielraum fürs Coding frisst, gibt es deshalb nicht. Die Abrechnung ist ein Credit-Guthaben über Bild, Video, Musik, 3D und Chat (Startseite, llms.txt). Wer Isolation will, legt getrennte API-Schlüssel je Workload an und setzt auf jeden Schlüssel stündliche / tägliche / gesamte Nutzungslimits (Erste Schritte, API-Schlüssel-Seite). Bei Mehrmandanten- oder Multi-Agenten-Aufrufern auf einem Schlüssel senden Sie X-End-User-ID und sperren einen missbräuchlichen Aufrufer mit 403 end_user_blocked, ohne alle zu rotieren (Endnutzer-Identifikation). Das gemeinsame Guthaben sehen Sie mit GET /api/user/balance (Nutzerguthaben). Bei 402 anhalten und aufladen (Fehlercodes).
Q3. Die Wände von Codex und Coding-Agenten sind zurück — die Burn-Rate hat die Woche in Stunden aufgebraucht.
Was Entwickler beanstanden: Die Timelines der Coding-Agenten füllten sich wieder mit Posts zur Nutzungswand: die Woche um den nächsten Reset des Codex-Limits planen (@GaryVSAISlop), berichten, Sol 6.1 über die Codex CLI habe das Kontingent in etwa 15 Stunden rund dreimal so schnell verbrannt (@AssistBDA), und wegen der API-Credit-Nachricht keine Entlastung durch den Reset erwarten (@snowy_smile_).
Wie PoYo antwortet: Chat bei PoYo ist je erfolgreicher Ausgabe in Credits bepreist, kein rollendes Reset-Fenster im Stil von Codex (llms.txt, Startseite). Chat-Endpunkte sind als OpenAI-kompatibel, Claude Messages oder Gemini-nativ dokumentiert. Wählen Sie eine Modell-ID und lesen Sie das aktuelle Schema dieses Modells unter https://poyo.ai/models/<id>/llms.txt. Begrenzen Sie einen aus dem Ruder gelaufenen Coding-Agenten mit stündlichen / täglichen / gesamten Limits je Schlüssel auf der API-Schlüssel-Seite (Erste Schritte). Der dokumentierte Standarddurchsatz liegt bei bis zu 20 neuen Anfragen je 10 Sekunden und Konto. Darüber gibt es 429, und die Anfrage kommt nicht in die Warteschlange (Erste Schritte). Halten Sie bei 429 Retry-After ein. Wiederholen Sie bezahlte Einreichungen nicht blind, solange Sie nicht wissen, ob bereits eine task_id existiert (Fehlerbehebung). Die Dokumentation beschreibt kein automatisches Failover zu einem anderen Labor, wenn ein vorgelagertes Coding-Werkzeug an seine eigene Wand stößt. Bauen Sie das in Ihren Client, wenn Sie es brauchen.
Q4. Ich habe den API-Schlüssel aus dem Repo gelöscht und gepusht — in der Git-Historie ist er wahrscheinlich weiter öffentlich.
Was Entwickler beanstanden: Ein kurzer Beitrag kam gleich zum klassischen Leak: Der Schlüssel wurde aus dem Arbeitsbaum entfernt und gepusht, das Geheimnis ist in der Git-Historie aber fast sicher weiter erreichbar (@patchnoteslabs).
Wie PoYo antwortet: Erste Schritte sind deutlich: Legen Sie Ihren API-Schlüssel nie in Frontend-Code, mobilen Apps oder öffentlichen Repositories offen, und behandeln Sie ihn als Geheimnis. Wenn ein PoYo-Schlüssel in der Git-Historie (oder anderswo öffentlich) gelandet sein kann:
- Widerrufen / rotieren Sie ihn auf der API-Schlüssel-Seite. Die Codezeile zu löschen reicht nicht.
- Schalten Sie eine IP-Whitelist ein, damit ein kopierter Schlüssel nur von freigegebenen Server-IPs aus funktioniert.
- Setzen Sie stündliche / tägliche / gesamte Grenzen je Schlüssel, damit ein liegen gebliebenes Geheimnis eine Decke hat.
- Bevorzugen Sie
X-End-User-IDbei Generierung und nativem Chat, damit Sie einen Aufrufer mit 403end_user_blockedsperren können, ohne jede Integration zu rotieren (Endnutzer-Identifikation).
Die öffentliche Dokumentation verspricht keine Erstattungen für Nutzung mit einem geleakten Schlüssel. Schreiben Sie an [email protected], wenn Sie glauben, ein PoYo-Schlüssel sei missbraucht worden (Erste Schritte).
Q5. Das Werkzeug, das meine Anbieterschlüssel gespeichert hat, wurde gehackt — inaktive Zugangsdaten haben die Rechnung eines anderen bezahlt.
Was Entwickler beanstanden: Ein Beitrag beschrieb einen API-Schlüssel eines inaktiven Kontos plus einen Fehler in den Anbieter-Einstellungen von Opik AI, durch den 29 Schlüssel von OpenAI / Anthropic abhandenkamen (@AgentFieldKit). Das Muster ist bekannt: Zugangsdaten in der „AI settings“-Oberfläche eines Dritten werden zur Geldbörse des Angreifers, sobald dieser Host falsch liegt.
Wie PoYo antwortet: Schlüssel in den Einstellungen eines anderen Produkts sind ein Geheimnisproblem auf der Client-Seite. Die dokumentierten Kontrollen von PoYo begrenzen den Schadensradius, sobald ein Geheimnis existiert:
- Legen Sie getrennte Schlüssel je Umgebung / Harness an, jeden mit stündlichen, täglichen und gesamten Nutzungslimits (API-Schlüssel-Seite, Erste Schritte).
- Schalten Sie für Produktionsschlüssel eine IP-Allowlist ein.
- Bevorzugen Sie
X-End-User-ID, damit Sie einen Aufrufer sperren können, ohne den Schlüssel zu löschen (Endnutzer-Identifikation). - Sehen Sie das aktuelle Guthaben mit
GET /api/user/balance(Nutzerguthaben). Bei 402 anhalten (Fehlercodes).
Löschen Sie Schlüssel, die Sie nicht mehr nutzen. Die Dokumentation beschreibt weder ein automatisches Ablaufen ungenutzter Schlüssel noch ein Erstattungs-SLA für Ausgaben nach einem Einbruch. Sagen Sie das, und rotieren Sie. Halten Sie PoYo-Schlüssel auf Ihrem Server, nicht im Frontend und nicht in einem Einstellungsformular eines Dritten, das Sie nicht mehr beobachten (Erste Schritte).
Q6. Mein Agent lief 30 Stunden — zwischen dem Code und der API stand keine Zahl, die er nicht überschritten hätte.
Was Entwickler beanstanden: Ein Entwickler beschrieb einen 30-Stunden-Lauf eines Agenten, bei dem außerhalb des Prozesses nichts eine harte Ausgabendecke erzwang. Das harte Limit muss außerhalb des Auftrags sitzen (@asymmetricmind). Benachbarte Beiträge drängten auf Scorecards zur Ausgabengovernance für Agenten, die schleifen oder zu viel abrufen (@hacker_no_ice).
Wie PoYo antwortet: Weiche Hinweise im Agenten sind kein Budget. Bei PoYo setzen Sie die Decke auf die Zugangsdaten und das Guthaben:
- Je Schlüssel stündliche / tägliche / gesamte Nutzungslimits auf jedem Produktionsschlüssel (Erste Schritte, API-Schlüssel-Seite).
- Kombinieren Sie das mit einer IP-Whitelist für Schlüssel, die nur vom Server aus gelten.
- Nutzen Sie
X-End-User-IDplus Sperre für Mehrmandanten- oder Multi-Agenten-Apps (Endnutzer-Identifikation). - Fragen Sie
GET /api/user/balancevor großen Stapeln ab (Nutzerguthaben). Behandeln Sie 402 als harten Stopp, nicht als Signal zum Wiederholen (Fehlercodes). - Bei langen asynchronen Aufträgen bevorzugen Sie Webhooks gegenüber aggressivem Abfragen (Webhooks). Erste Schritte warnt, jede erneute Einreichung könne neue bezahlte Arbeit sein. Bestätigen Sie die
task_id, bevor Sie erneut einreichen (Fehlerbehebung).
Die Dokumentation beansprucht kein Produkt „Kill-Switch“ außerhalb des Prozesses über diese Schlüsselgrenzen, das Guthaben und die Fehlercodes hinaus. Verdrahten Sie Ihren Orchestrator so, dass er bei 402 und bei gedeckelten Schlüsseln anhält.
Q7. Der schwierige Teil ist nicht das Modell — es sind getrennte Konten, API-Schlüssel und Abrechnungssysteme für jede Creative-API.
Was Entwickler beanstanden: Ersteller und Entwickler sagten, der schmerzhafte Teil sei das Jonglieren mit getrennten Anbieterkonten, Schlüsseln und Abrechnungen (@CyberFree365). Andere fassten Margen als API-Rechnungsproblem und sahen offene Modelle über Aggregatoren als Kostenhebel (@RonaleK777) oder suchten schlicht eine günstige LLM-API in der Fläche (@brice_garnier_).
Wie PoYo antwortet: PoYo ist als ein einheitlicher Schlüssel über Bild, Video, Musik, 3D und Chat gebaut (llms.txt, Startseite). Legen Sie einen Schlüssel auf der API-Schlüssel-Seite an. Medien nutzen asynchrones POST /api/generate/submit plus Status oder Webhook. Chat nutzt OpenAI-kompatible, Claude-Messages- oder Gemini-native Endpunkte, wie je Modell dokumentiert. Der Modellwechsel ist eine model-Zeichenkette (und bei Chat die passende Endpunktform), kein neues Anbieter-Onboarding. Aktuelle Eingabeschemas und Preise stehen unter https://poyo.ai/models/<id>/llms.txt und im Katalogindex (llms.txt). Die Abrechnung sind Prepaid-Credits, die nie verfallen und je erfolgreicher Ausgabe berechnet werden (Startseite).
Die Dokumentation behauptet nicht, PoYo sei ein Durchreichen des offiziellen Kontos jedes Labors. Erste Schritte merken auch an, die Gesamtstabilität könne etwas unter der offizieller Anbieter liegen. Wählen Sie den Kompromiss bewusst.
Kurzüberblick
| Beschwerde | Wo PoYo es dokumentiert |
|---|---|
| Monatliche Pro-API-Credits, die verfallen / regionale Einlöselücken | Startseite: Credits verfallen nie · Guthaben-API · Fehlercodes: 402 |
| Furcht, zusammengelegte Chat/Work/Codex-Pools fräßen das Coding-Kontingent | Ein Credit-Guthaben · Getrennte Schlüssel plus Grenzen · X-End-User-ID · Guthaben-API |
| Nutzungswände und Burn-Rate von Codex / Coding-Agenten | llms.txt-Chat · Grenzen je Schlüssel · 429 + Retry-After · kein dokumentiertes Auto-Failover |
| Gelöschter Schlüssel bleibt in der Git-Historie | Erste Schritte: Schlüssel nicht offenlegen · Auf der API-Schlüssel-Seite rotieren · IP-Whitelist · Grenzen |
| Werkzeuge, die Anbieterschlüssel speichern, werden gehackt | Getrennte Schlüssel plus Grenzen · IP-Whitelist · X-End-User-ID · ungenutzte widerrufen · kein Erstattungs-SLA |
| Agenten ohne hartes Ausgabenlimit außerhalb des Prozesses | Grenzen je Schlüssel · Guthaben + 402 · Webhooks · Wiederholung kann neue bezahlte Arbeit sein |
| Wildwuchs bei Creative-API-Schlüsseln / getrennte Anbieterabrechnung | Ein PoYo-Schlüssel · llms.txt-Katalog · llms.txt je Modell · Credits verfallen nie |