2026-10-27: 7 API-Beschwerden, die wir heute gehört haben

Beschwerden, die englischsprachige Entwickler zwischen dem 25. und 27. 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. Das neue schnelle Modell ist so schnell, dass es sich selbst mit 429 beantwortet — besonders bei maximalem Reasoning und parallelen Codex-Sitzungen.

Was Entwickler beanstanden: GPT-6.1 Terra startete als schnellere, günstigere Computer-Use-Stufe. Danach trafen Entwickler sofort HTTP 429 auf Terra / fast-mode und unter maximalem Reasoning, während dieselbe Eingabe auf Sol das nicht tat. Mehrere Beiträge notierten null verbrauchte Tokens bei einem 429. Das heißt: ein Nebenläufigkeits- oder Rate-Gate hat vor der Messung ausgelöst. Parallele Codex-Sitzungen, die denselben Schlüssel abfragen, haben es verschärft.

Wie PoYo antwortet: Unsere Seite Fehlercodes gibt 429 eine Bedeutung — rate_limit_error — und eine empfohlene Aktion: vor einem erneuten Versuch warten oder Anfragen in die Warteschlange stellen. Erste Schritte veröffentlicht das Standardlimit für Generierung: bis zu 20 neue Generierungsanfragen pro 10 Sekunden, je Konto. Anfragen darüber erhalten HTTP 429 und kommen nicht in die Warteschlange. Chat- und Medienmodelle teilen einen PoYo-Schlüssel und stehen in llms.txt. Ein Modellwechsel ist eine Änderung der Zeichenkette model, kein neues Anbieter-Onboarding. Wenn Sie durchgehend 429 erhalten, dürfen Sie laut Dokumentation den Support nach einem höheren Limit fragen. Genehmigungen werden vorsichtig behandelt.

Die Dokumentation beschreibt kein automatisches Failover zwischen Anbietern. Bauen Sie den Fallback in Ihren Client. Erste Schritte sagt außerdem, die „Gesamtstabilität von PoYo kann etwas niedriger sein als bei den offiziellen Anbietern“.

---

Q2. Mein „429“ war eigentlich eine Ausgabengrenze — Abrechnungsfehler im Gewand eines Rate-Limits.

Was Entwickler beanstanden: Ein Beitrag fasste es so: HTTP 429 ist nicht ein Fehlermodus. Bei Anthropic kann er ein Rate-Limit, ein Beschleunigungslimit oder eine Ausgabengrenze bedeuten. Ein 429 aus einer Ausgabengrenze hat oft kein Retry-After, also bringt endloses Warten nichts. Teams behandeln einen harten Abrechnungsstopp weiter wie eine Drosselung.

Wie PoYo antwortet: PoYo trennt die beiden Fälle klar in der Tabelle der Fehlercodes:

Die Abrechnung selbst sind Prepaid-Credits. Die Startseite sagt: Einmalkäufe ohne wiederkehrende Abonnements, und Credits verfallen nie. Fragen Sie GET /api/user/balance nach credits_amount ab, wenn Sie eine aktuelle Zahl brauchen (Nutzerguthaben). Der Hinweis bei den Fehlercodes ist eindeutig: Überwachen Sie die Credits, damit bei kritischer Arbeit kein 402 entsteht.

---

Q3. Mein Agenten-SDK verbraucht das Rate-Limit-Fenster etwa 1,7× schneller als Chat — und N Agenten teilen weiter eine Obergrenze.

Was Entwickler beanstanden: Anthropic hat einen Fehler im Agents SDK eingeräumt. Beim Wechsel vom Chat in den Agentenmodus wurden die 5-Stunden-Rate-Limits von Claude ungefähr 1,7× schneller verbraucht als erwartet. Getrennt davon notierten Entwickler: Worktrees beheben Dateikonflikte, aber zehn Agenten teilen weiter eine Datenbank und ein API-Rate-Limit. Parallele Harnesses stolpern auf demselben Schlüssel übereinander.

Wie PoYo antwortet: Die Generierung bei PoYo ist asynchron angelegt, damit lange Aufträge nicht an einem einzelnen Gateway-Timeout hängen. Erste Schritte und der API-Überblick sagen: Aufgabe einreichen, die task_id speichern, dann den Status abfragen oder einen Webhook empfangen. Für Produktionslasten bevorzugt die Dokumentation signierte Webhooks gegenüber häufigem Abfragen. Bei 429 warten oder in die Warteschlange stellen (Fehlercodes). Das Standardlimit bleibt 20 neue Anfragen / 10 s je Konto. Darüber liegende Anfragen werden abgelehnt und nicht eingereiht.

Damit ein entlaufener Agent nicht das ganze Konto leert, nutzen Sie die Kontrollen auf der API-Schlüssel-Seite und in Erste Schritte: Nutzungsobergrenzen je Schlüssel, stündlich, täglich und insgesamt. Bild, Video, Musik, Chat und 3D liegen hinter einem einheitlichen API-Schlüssel (llms.txt, Startseite).

Die Dokumentation beschreibt kein automatisches Failover zwischen Anbietern. Ihr Client muss 429 / 5xx behandeln und das nächste Modell oder den Wiederholungspfad wählen.

---

Q4. Wieder ein SaaS hat meine KI-Schlüssel — und der Anbieter sagte, die unbefugte Ausgabe sei nicht erstattbar.

Was Entwickler beanstanden: Ein Entwickler meldete einen gehackten Anthropic-API-Schlüssel, der 105,94 $ unbefugte Nutzung verursacht hat. Der Support (über einen KI-Agenten) sagte, verbrauchte Nutzung sei nicht erstattbar, und schloss die Eskalation. Im selben 48-Stunden-Fenster tauchten erneut Vorfälle im Stil von OpenCode Console / Railway auf. Der Preis waren gespeicherte Schlüssel von OpenAI, Anthropic und Google. Zuerst rotieren, dann eine harte Ausgabendecke setzen.

Wie PoYo antwortet: Rotieren Sie zuerst. Ein geleaktes Geheimnis bleibt ein geleaktes Geheimnis. Danach nennt die Dokumentation Kontrollen, die begrenzen, was ein gestohlener PoYo-Schlüssel tun kann:

• IP-Whitelist. Erlauben Sie auf einem Schlüssel nur Ihre freigegebenen Server-IPs. Ein aus einer Umgebungsvariable kopierter Schlüssel funktioniert nicht auf der Maschine des Angreifers. Siehe die API-Schlüssel-Seite und Erste Schritte.
• Nutzungsobergrenzen je Schlüssel (stündlich, täglich und insgesamt), damit ein Schlüssel eine harte Decke hat, bevor Sie es bemerken.
• Sperre je Endnutzer. Senden Sie den Header X-End-User-ID, und Sie können einen missbräuchlichen Aufrufer auf einem Schlüssel sperren, ohne den Schlüssel zu rotieren. Eine gesperrte ID liefert HTTP 403 mit end_user_blocked. Siehe Endnutzer-Identifikation.

Unsere öffentliche Dokumentation verspricht keine Erstattung für Nutzung mit einem geleakten Schlüssel. Wenn Sie meinen, ein PoYo-Schlüssel sei missbraucht worden, widerrufen Sie ihn und kontaktieren Sie den Support ([email protected]).

---

Q5. Ein KI-Client sollte wissen, wann er nicht wiederholen soll — und Video-Wiederholungen können die Rechnung leise verdoppeln.

Was Entwickler beanstanden: Wiederholungen helfen bei vorübergehenden Fehlern, sind aber nicht allgemein. Ist eine Anfrage fehlerhaft, ein Nachweis ungültig oder ein Modell für das Konto nicht verfügbar, erhöht dieselbe Wiederholung nur den Druck. Bei Video-APIs zeigt sich dasselbe als: Wer auf Wiederholen drückt, kann einen zweiten berechneten Auftrag anlegen.

Wie PoYo antwortet: Ordnen Sie den Fehler der Aktion in den Fehlercodes zu:

• 402 insufficient_credits_error → aufladen. Nicht wiederholen.
• 429 rate_limit_error → warten oder in die Warteschlange stellen.
• 500 / 502 / 503 → exponentielles Backoff.
• 401 → den Schlüssel korrigieren. Dieselbe ungültige Anmeldung erneut zu senden hilft nicht (Erste Schritte).

Erste Schritte warnt außerdem: Behandeln Sie jeden erneuten Submit als möglicherweise neue bezahlte Arbeit. Prüfen Sie vor dem erneuten Senden, ob die ursprüngliche Anfrage einen Auftrag angelegt hat. Für Medien sagen llms.txt und die Startseite, dass fehlgeschlagene Aufgaben nicht berechnet werden und die Abrechnung je erfolgreicher Ausgabe und je Modell erfolgt. Bevorzugen Sie callback_url / Webhooks gegenüber aggressivem Status-Polling, damit die Last beim Warten nicht steigt (API-Überblick).

---

Q6. API-Preise wirken neben dem Abonnement weiter unhaltbar teuer — und ich sehe das aktuelle Guthaben nicht, bevor der Agent es verbraucht.

Was Entwickler beanstanden: Eine Antwort sagte es direkt: Abonnements wirken subventioniert, die API-Preise von OpenAI und Anthropic seien „unhaltbar teuer“. Andere Beiträge im selben Fenster fragten, ob jemand überhaupt weiß, was ein einzelner Multi-Agenten-Prompt zu API-Sätzen kostet, und erinnerten daran, dass die Zähler von ChatGPT / Codex-Abonnement und die API-Zähler nicht miteinander sprechen.

Wie PoYo antwortet: Drei dokumentierte Punkte passen zu dieser Beschwerde:

1. Prepaid-Credits, kein Abonnement-Zähler. Die Startseite beschreibt Preise auf Credit-Basis: Einmalkäufe, keine wiederkehrenden Abonnements, Credits verfallen nie. Sie zahlen für erfolgreiche Generierungen. Fehlgeschlagene Aufgaben werden nicht berechnet (llms.txt).
2. Ein Schlüssel, ein Guthaben. Chat und Medien teilen ein PoYo-Konto. Fragen Sie GET /api/user/balance nach credits_amount ab (Nutzerguthaben).
3. Veröffentlichte Preise je Modell. Aktuelle Preise stehen auf jeder Modellseite / https://poyo.ai/models/<id>/llms.txt und im Katalogindex (llms.txt). Prüfen Sie das, bevor Sie bezahlte Arbeit einreichen. Leiten Sie Dollarbeträge nicht aus dem Gedächtnis ab. Die Auftragshistorie (beschrieben in Erste Schritte) lässt Modell, Eingaben und Status danach einsehen.

---

Q7. Meine „Server-Funktion“ / mein Telegram-Bot ist für jeden aufrufbar — und der Schlüssel liegt dort, wo curl ihn findet.

Was Entwickler beanstanden: Praktische Sicherheitsbeiträge kamen weiter: API-Schlüssel einschränken und ein Tageskontingent setzen. Anbieterschlüssel nicht in Chat-Oberflächen oder Telegram-Agenten einfügen. Ein Schlüssel in einer aufrufbaren Server-Funktion ohne Rate-Limit je Nutzer und ohne Ausgabendecke ist eine Kreditkarte für jeden, der die URL findet.

Wie PoYo antwortet: Erste Schritte ist eindeutig: Legen Sie Ihren API-Schlüssel nie in Frontend-Code offen (Browser, mobile Apps, öffentliche Repositories). Behandeln Sie den Schlüssel als Geheimnis, halten Sie ihn auf Ihrem Server und nutzen Sie die bereits dokumentierten Kontrollen für Produktionsschlüssel:

• IP-Whitelist und Obergrenzen je Schlüssel, stündlich / täglich / insgesamt, auf der API-Schlüssel-Seite.
• Verlangen Sie X-End-User-ID und sperren Sie einen missbräuchlichen Aufrufer mit HTTP 403 end_user_blocked, ohne den ganzen Schlüssel zu rotieren (Endnutzer-Identifikation).
• Behandeln Sie 401, 402 und 429 ausdrücklich, bevor Sie in Produktion gehen (Erste Schritte, Fehlercodes).

---

Kurzüberblick