Beschwerden, die englischsprachige Entwickler zwischen dem 26. und 28. 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. Claude Code ist mitten im Refactor an die Nutzungswand gestoßen — und es gibt weiter keinen sauberen Pfad „zurück auf meinen API-Schlüssel“.
Was Entwickler beanstanden: Die Timelines vom 27. und 28. Oktober waren voll mit Screenshots, die Nutzungslimits von Claude Code und Codex nebeneinander zeigten. Entwickler fragten, ob Claude Code auf einen API-Schlüssel zurückfallen kann, sobald Abonnementlimits erreicht sind (@irl_danB), scherzten, ein Limit mitten im Refactor sei das neue „Speichern vergessen“ (@automater_ai), und verglichen 20-Dollar-Stufen, die auf einem Stack nutzlos wirken, während ein anderes Plus-Abonnement nie auslöst (@mozdca, @LeoZhang57).
Wie PoYo antwortet: PoYo sind Prepaid-Credits, kein Abonnementfenster von 5 Stunden oder einer Woche. Die Startseite beschreibt einmalige Credit-Käufe, keine wiederkehrenden Abonnements und Credits, die nie verfallen. Sie zahlen für erfolgreiche Generierungen. llms.txt sagt, fehlgeschlagene Aufgaben werden nicht berechnet. Chat und Medien teilen einen API-Schlüssel und ein Guthaben. 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, kein rollendes Nutzungsfenster im Gewand einer Drosselung (Fehlercodes). Eine Produktfunktion „Abonnement → API-Schlüssel“ als Failover ist nicht dokumentiert, weil die Abrechnung bereits creditbasiert ist. Begrenzen Sie einen aus dem Ruder gelaufenen Agenten mit den stündlichen, täglichen und gesamten Nutzungslimits je Schlüssel auf der API-Schlüssel-Seite (Erste Schritte).
Q2. Das „429“ von Claude Code sind drei verschiedene Meldungen — endloses Warten hilft nur bei einer davon.
Was Entwickler beanstanden: Ein Thread zur Fehlersuche stellte fest, dass Claude Code drei verschiedene Fehler in der Form eines 429 zeigen kann: auf einen Reset warten, gleich noch einmal versuchen oder den API-Schlüssel prüfen. Jeder braucht eine andere Korrektur (@aiparabellum). Getrennt davon fragten Entwickler, ob Rate-Limit-Probleme im Agenten-Tooling von Anthropic schon behoben seien (@XavierDelon, @GeorgeMathew_).
Wie PoYo antwortet: Unsere Fehlercodes halten Abrechnung und Rate-Limits auf verschiedenen Nummern:
| Code | error.type | Bedeutung / was zu tun ist |
|---|---|---|
| 401 | authentication_error | Schlüssel ungültig oder fehlt. Korrigieren Sie den Nachweis. Wiederholen Sie nicht denselben schlechten Schlüssel (Erste Schritte). |
| 402 | insufficient_credits_error | Das Guthaben ist aufgebraucht. Laden Sie auf. Ein erneuter Versuch hilft nicht. |
| 429 | rate_limit_error | Rate-Limit. Warten Sie oder stellen Sie in die Warteschlange. |
| 500 / 502 / 503 | internal_error / upstream_error / service_error | Exponentielles Backoff. |
Der dokumentierte Standarddurchsatz für Generierung ist bis zu 20 neue Anfragen pro 10 Sekunden je Konto. Darüber gibt es HTTP 429, und die Anfrage kommt nicht in die Warteschlange (Erste Schritte). Die Fehlerbehebung für Integrationen sagt außerdem: Halten Sie Retry-After bei Rate-Limits ein, und wiederholen Sie eine bezahlte Einreichung nicht blind, bevor Sie wissen, ob eine task_id entstanden ist (Fehlerbehebung).
Die Dokumentation beschreibt kein automatisches Failover zwischen Upstream-Anbietern. Bauen Sie das in Ihren Client.
Q3. Jeder API-Schlüssel, den ich je in den Agenten-Chat eingefügt habe, liegt noch in den Projektprotokollen.
Was Entwickler beanstanden: Nach einem Thread über Claude-Projektprotokolle kam eine Antwort direkt zum Risiko: Jeder API-Schlüssel, den Sie je in den Chat eingefügt haben, steht auch in diesen Protokollen. Suchen Sie in ~/.claude/projects nach sk- und rotieren Sie, was auftaucht (@wazX_7). Nahe Beiträge drängten auf dieselbe Hygiene: Behandeln Sie KI-Schlüssel wie Root-Nachweise (@RuntimeAI_io), und geben Sie nicht jedem Agenten einen gemeinsamen Schlüssel ohne Abschaltmöglichkeit (@RohanBhanotAI).
Wie PoYo antwortet: Erste Schritte ist deutlich: Legen Sie Ihren API-Schlüssel nie in Frontend-Code, mobilen Apps oder öffentlichen Repositories offen, und behandeln Sie ihn als Geheimnis. Halten Sie Schlüssel auf Ihrem Server. Nach einem Einfügen oder einem vermuteten Leak:
- Widerrufen / rotieren Sie den Schlüssel auf der API-Schlüssel-Seite.
- IP-Whitelist, damit ein kopierter Schlüssel nur von freigegebenen Server-IPs aus funktioniert.
- Obergrenzen je Schlüssel, stündlich / täglich / insgesamt, damit ein Leak eine Decke hat.
- Senden Sie
X-End-User-IDbei Generierung und nativem Chat. Sperren Sie einen missbräuchlichen Aufrufer mit HTTP 403end_user_blocked, ohne den ganzen Schlüssel zu rotieren (Endnutzer-Identifikation).
Unsere öffentlichen Dokumente versprechen keine Erstattung für Nutzung mit einem geleakten Schlüssel. Kontaktieren Sie [email protected], wenn Sie glauben, ein PoYo-Schlüssel sei missbraucht worden.
Q4. Mein vergessener Aggregator-Schlüssel ist weiter eine Agenten-Geldbörse — ein Host-Vorfall machte ungenutzte Nachweise zu einem Auftrag mit 500 Schritten.
Was Entwickler beanstanden: Ein Beitrag warnte, ein vergessener OpenRouter-Schlüssel sei weiter eine Agenten-Geldbörse: Ein Vorfall im Stil von Railway setzte ungenutzte Schlüssel auf eine Liste zum Entwerten, und einer hatte bereits einen Agentenauftrag mit 500 Schritten finanziert, während die Dashboards bis dahin null Traffic zeigten. Genannt wurden: Ausgabengrenzen, kurzlebige Schlüssel und keine Anbieter-Token auf Hosts, die Sie nicht mehr beobachten (@neiro_go_neiro). Eine andere Antwort verband dasselbe Muster mit Anbietern, die Wochen nach Vorfällen weiter Schlüssel widerrufen (@Kenz_1604).
Wie PoYo antwortet: Ungenutzte Schlüssel auf verlassenen Hosts sind ein Geheimnisproblem auf der Client-Seite. Die dokumentierten Kontrollen von PoYo begrenzen den Wirkungsradius, sobald ein Geheimnis existiert:
- Legen Sie je Umgebung / Harness eigene Schlüssel an, jeweils mit stündlichen, täglichen und gesamten Nutzungslimits (API-Schlüssel-Seite, Erste Schritte).
- Schalten Sie für Produktionsschlüssel eine IP-Freigabeliste ein.
- Bevorzugen Sie
X-End-User-ID, damit Sie einen Aufrufer sperren können, ohne den Schlüssel zu löschen (Endnutzer-Identifikation). - Beobachten Sie das aktuelle Guthaben mit
GET /api/user/balance(Nutzerguthaben) und die Auftragshistorie im Dashboard (Erste Schritte).
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 Vorfall. Sagen Sie das, und rotieren Sie.
Q5. Ich habe ein hartes KI-Ausgabenlimit gesetzt — dann bekam jemand den Schlüssel und ist über Nacht darüber hinausgelaufen.
Was Entwickler beanstanden: Ein Entwickler setzte ein KI-Rechnungslimit von 25 Dollar. Jemand bekam den API-Schlüssel und ließ ihn in einer Nacht auf 55 Dollar laufen (@twentyonemilll). Das Thema deckt sich mit älteren OpenRouter-Threads: Deaktivieren reichte nicht, nur das vollständige Löschen des Schlüssels stoppte den Abfluss. Das Fenster vom 28. Oktober erzeugt weiter dieselbe Beschwerde: Das Limit existierte, der Leak tat trotzdem weh.
Wie PoYo antwortet: Obergrenzen helfen nur, wenn sie auf dem kompromittierten Nachweis erzwungen werden, nicht nur auf einem weichen Budget im Dashboard. Bei PoYo:
- Setzen Sie auf jeden Produktionsschlüssel je Schlüssel stündliche / tägliche / gesamte Nutzungslimits (Erste Schritte, API-Schlüssel-Seite).
- Kombinieren Sie das mit einer IP-Whitelist, damit der Schlüssel aus dem Netz des Angreifers fehlschlägt.
- Nutzen Sie
X-End-User-IDplus Sperre für Mehrmandanten-Apps (Endnutzer-Identifikation). - Bei 402 anhalten. Das heißt, die Credits sind aufgebraucht (Fehlercodes). Fragen Sie das Guthaben vor großen Stapeln ab (Nutzerguthaben).
Wenn ein Schlüssel draußen sein könnte, löschen oder widerrufen Sie ihn. Senken Sie nicht nur einen weichen Alarm. Die öffentlichen Dokumente beanspruchen keine Erstattung für Ausgaben mit einem geleakten Schlüssel.
Q6. Einen Google-API-Schlüssel zu bekommen ist so mühsam, dass „einfach einen Aggregator nutzen“ zum Standard wurde.
Was Entwickler beanstanden: Ein Entwickler sagte, Google-Modelle erst zu versuchen, wenn der Anmeldeprozess für den API-Schlüssel repariert ist. Bis dahin nur OpenRouter (@sandipb). Nahe Beiträge beschrieben Aggregatoren weiter als Zahlungsbörse und Modellwechsel für Agenten (@tomcritchlow), während andere nur zum Testen ein Dutzend Anbieterschlüssel jonglieren (@sunwei57247249).
Wie PoYo antwortet: PoYo ist als ein einheitlicher Schlüssel für Bild, Video, Musik, 3D und Chat gebaut (llms.txt, Startseite). Legen Sie einen Schlüssel auf der API-Schlüssel-Seite an. Medien nutzen asynchron POST /api/generate/submit plus Status oder Webhook. Chat nutzt je Modell die dokumentierten Endpunkte: OpenAI-kompatibel, Claude Messages oder Gemini-nativ. Ein Modellwechsel ist eine Änderung der Zeichenkette model (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 Dokumentation behauptet nicht, PoYo sei ein Durchreichen des offiziellen Kontos jedes Labors. Sie sagt auch, die Gesamtstabilität könne etwas niedriger sein als bei den offiziellen Anbietern (Erste Schritte). Wählen Sie diesen Kompromiss bewusst.
Q7. Ein Video-Abonnement für 59 Dollar ist der teure Einstieg, wenn ich nur wenige Clips ausliefere — und Wiederholungen können eine zweite Rechnung erzeugen.
Was Entwickler beanstanden: Ersteller verglichen monatliche Video-Tool-Pläne mit APIs, die pro Clip abrechnen. Wer nur wenige KI-Videos im Monat macht, kann mit einem 59-Dollar-Plan den teuren Weg gehen, während eine API pro Clip berechnet und Coding-Agenten sie ansteuern können (@aliteqai). Verwandter API-Schmerz: fertige Video-Downloads, die erst nach der Abrechnungsfreigabe offen sind (@MariaOnchainDev), und die stehende Sorge, blinde Wiederholungen erzeugten einen zweiten berechneten Auftrag.
Wie PoYo antwortet: Video bei PoYo ist je erfolgreicher Ausgabe in Credits bepreist, Modell für Modell. Den Videokatalog finden Sie in llms.txt (Sora 2, Veo 3.1, Kling, Wan, Seedance, Hailuo und weitere). Der Ablauf ist die einheitliche asynchrone API: einreichen, dann den Status abfragen oder callback_url setzen (Erste Schritte, Webhooks). Startseite und llms.txt sagen beide: Fehlgeschlagene Aufgaben werden nicht berechnet.
Bevor Sie bei einem langsamen Videoauftrag auf Wiederholen hämmern: Erste Schritte warnt, jede erneute Einreichung könne neue bezahlte Arbeit sein. Prüfen Sie, ob die ursprüngliche Anfrage bereits eine task_id erzeugt hat. Bevorzugen Sie Webhooks gegenüber aggressivem Abfragen. Bei 402, 429 und 5xx folgen Sie der Tabelle der Fehlercodes. Behandeln Sie einen Credit-Stopp nicht wie ein Rate-Limit.
Kurzüberblick
| Beschwerde | Wo PoYo es dokumentiert |
|---|---|
| Nutzungslimit-Wände / kein Failover von Abonnement zu API | Startseite: Credits · Guthaben-API · Fehlercodes: 402 · API-Schlüsselgrenzen |
| 429 mit drei verschiedenen Fehlern | Fehlercodes: 401 / 402 / 429 / 5xx · Erste Schritte: Rate-Limits · Fehlerbehebung |
| Schlüssel in Agentenprotokolle eingefügt | Erste Schritte: Schlüssel nicht offenlegen · API-Schlüssel-Seite · X-End-User-ID |
| Ungenutzte Aggregator-Schlüssel nach Host-Vorfällen | API-Schlüsselgrenzen · IP-Whitelist · Guthaben und Auftragshistorie · ungenutzte Schlüssel widerrufen |
| Ausgabengrenze von einem geleakten Schlüssel durchbrochen | Grenzen je Schlüssel · IP-Whitelist · X-End-User-ID · Umgang mit 402 |
| Schmerzhaftes Onboarding von Anbieterschlüsseln / Schlüsselwildwuchs | Ein PoYo-Schlüssel · llms.txt-Katalog · llms.txt je Modell |
| Video-Abonnement gegen Preis pro Clip plus Wiederholungsabrechnung | Videokatalog · asynchrones Einreichen/Status · Fehler werden nicht berechnet · Wiederholung = neue bezahlte Arbeit |