2026-10-28: 7 skarg na API, które usłyszeliśmy dziś

Skargi, które anglojęzyczni programiści opublikowali między 26 a 28 października 2026, streszczone poniżej własnymi słowami, z linkami do oryginalnych wpisów. Każda odpowiedź opiera się wyłącznie na tym, co dziś mówią publiczna strona i dokumentacja PoYo, i prowadzi do strony, z której pochodzi. Tam, gdzie dokumentacja czegoś nie obejmuje, mówimy o tym wprost.

---

Q1. Claude Code uderzył w limit użycia w środku refaktoryzacji, a nadal nie ma czystej ścieżki „przełącz się na mój klucz API”.

Na co skarżą się programiści: Osie czasu z 27–28 października były pełne zestawień zrzutów ekranu z limitami użycia Claude Code i Codex. Twórcy pytali, czy Claude Code potrafi przełączyć się na klucz API po wyczerpaniu limitów subskrypcji (@irl_danB), żartowali, że wyczerpanie limitu w trakcie refaktoryzacji to nowe „zapomniałem zapisać” (@automater_ai), i porównywali plany za $20, które na jednym stosie wydają się bezużyteczne, podczas gdy inna subskrypcja Plus nigdy nie dochodzi do limitu (@mozdca, @LeoZhang57).

Jak odpowiada PoYo: PoYo to kredyty opłacane z góry, a nie 5-godzinne czy tygodniowe okno subskrypcji. Strona główna opisuje jednorazowe zakupy kredytów, brak cyklicznych subskrypcji i kredyty, które nigdy nie wygasają. Płacisz za udane generowania; llms.txt podaje, że nieudane zadania nie są naliczane. Czat i media korzystają z jednego klucza API i jednego salda — odpytaj GET /api/user/balance o aktualne credits_amount (saldo użytkownika).

Gdy saldo się wyczerpie, PoYo zwraca 402 insufficient_credits_error, a nie kroczące okno użycia przebrane za ograniczenie przepustowości (kody błędów). Nie ma udokumentowanej funkcji produktu „subskrypcja → failover na klucz API”, bo rozliczenia już opierają się na kredytach. Rozbieganego agenta ograniczysz godzinnymi / dziennymi / łącznymi limitami użycia dla każdego klucza na stronie kluczy API (Getting Started).

---

Q2. „429” w Claude Code to trzy różne komunikaty — wieczne czekanie pomaga tylko przy jednym z nich.

Na co skarżą się programiści: W jednym wątku o rozwiązywaniu problemów zwrócono uwagę, że Claude Code może pokazywać trzy różne awarie w kształcie 429 — poczekaj na reset, spróbuj za chwilę albo sprawdź klucz API — i każda wymaga innego rozwiązania (@aiparabellum). Osobno twórcy pytali, czy problemy z limitami żądań w narzędziach agentowych Anthropic zostały już naprawione (@XavierDelon, @GeorgeMathew_).

Jak odpowiada PoYo: Nasze kody błędów trzymają rozliczenia i limity żądań pod różnymi numerami:

Domyślna przepustowość generowania jest udokumentowana jako do 20 nowych żądań na 10 sekund na konto; nadwyżka dostaje HTTP 429 i nie trafia do kolejki (Getting Started). Rozwiązywanie problemów z integracjami mówi też: respektuj Retry-After przy limitach żądań i nie ponawiaj na ślepo płatnego zgłoszenia, dopóki nie wiesz, czy powstał task_id (rozwiązywanie problemów).

W dokumentacji nie ma mowy o automatycznym failover między dostawcami upstream. Zaimplementuj go po stronie klienta.

---

Q3. Każdy klucz API wklejony kiedyś do czatu z agentem wciąż leży w logach projektu.

Na co skarżą się programiści: Po wątku o logach projektów Claude jedna odpowiedź trafiła w sedno ryzyka: każdy klucz API wklejony kiedykolwiek do czatu też jest w tych logach — przeszukaj ~/.claude/projects pod kątem sk- i wymień wszystko, co się znajdzie (@wazX_7). Pobliskie wpisy powtarzały tę samą higienę: traktuj klucze AI jak poświadczenia roota (@RuntimeAI_io) i przestań dawać każdemu agentowi jeden wspólny klucz bez wyłącznika awaryjnego (@RohanBhanotAI).

Jak odpowiada PoYo: Getting Started mówi bez owijania w bawełnę: nigdy nie ujawniaj klucza API w kodzie frontendu, aplikacjach mobilnych ani publicznych repozytoriach i traktuj go jak sekret. Trzymaj klucze na serwerze. Po wklejeniu klucza lub podejrzeniu wycieku:

1. Unieważnij / wymień klucz na stronie kluczy API.
2. Lista dozwolonych adresów IP, żeby skopiowany klucz działał tylko z zatwierdzonych adresów IP serwerów.
3. Godzinne / dzienne / łączne limity dla każdego klucza, żeby wyciek miał swój pułap.
4. Wysyłaj X-End-User-ID przy generowaniu i w natywnym czacie; jednego nadużywającego wywołującego zablokujesz przez HTTP 403 end_user_blocked, bez wymiany całego klucza (identyfikacja użytkownika końcowego).

Nasza publiczna dokumentacja nie obiecuje zwrotów za użycie wykonane wyciekłym kluczem. Jeśli uważasz, że klucz PoYo został użyty niewłaściwie, napisz na support@poyo.ai.

---

Q4. Mój zapomniany klucz agregatora to wciąż portfel agenta — włamanie do hosta zamieniło nieużywane poświadczenia w zadanie na 500 kroków.

Na co skarżą się programiści: Jeden wpis ostrzegał, że zapomniany klucz OpenRouter nadal jest portfelem agenta: włamanie w stylu Railway sprawiło, że nieużywane klucze trafiły na listę do przejęcia, a jeden z nich sfinansował już 500-krokowe zadanie agenta, podczas gdy dashboardy do tego momentu pokazywały zerowy ruch. Wskazane rozwiązanie: limity wydatków, krótkotrwałe klucze i żadnych tokenów dostawców na hostach, których już nie pilnujesz (@neiro_go_neiro). Inna odpowiedź powiązała ten sam wzorzec z dostawcami, którzy unieważniają klucze dopiero tygodnie po włamaniach (@Kenz_1604).

Jak odpowiada PoYo: Nieużywane klucze na porzuconych hostach to problem sekretów po stronie klienta; udokumentowane mechanizmy PoYo ograniczają zasięg szkód, gdy sekret już istnieje:

• Twórz osobne klucze dla każdego środowiska / środowiska uruchomieniowego, każdy z godzinnymi, dziennymi i łącznymi limitami użycia (strona kluczy API, Getting Started).
• Włącz listę dozwolonych adresów IP dla kluczy produkcyjnych.
• Używaj X-End-User-ID, żeby móc zablokować jednego wywołującego bez usuwania klucza (identyfikacja użytkownika końcowego).
• Obserwuj saldo na żywo przez GET /api/user/balance (saldo użytkownika) oraz historię zadań w dashboardzie (Getting Started).

Usuwaj klucze, których już nie używasz. Dokumentacja nie opisuje automatycznego wygasania nieużywanych kluczy ani SLA na zwrot za wydatki wynikające z włamania — mówimy o tym wprost: wymień klucze.

---

Q5. Mój twardy limit wydatków na AI nie pomógł — ktoś zdobył klucz i przekroczył go w jedną noc.

Na co skarżą się programiści: Jeden twórca ustawił limit rachunku za AI na $25; ktoś zdobył klucz API i w jedną noc doprowadził rachunek do $55 (@twentyonemilll). Motyw pasuje do starszych wątków o OpenRouter, w których samo wyłączenie klucza nie wystarczało i dopiero jego całkowite usunięcie zatrzymało drenaż — ale okno z 28 października wciąż przynosi tę samą skargę: „limit istniał, a wyciek i tak zabolał”.

Jak odpowiada PoYo: Limity pomagają tylko wtedy, gdy są egzekwowane na przejętym poświadczeniu, a nie wyłącznie jako miękki budżet w dashboardzie. W PoYo:

• Ustaw limity dla każdego klucza (godzinne / dzienne / łączne) na każdym kluczu produkcyjnym (Getting Started, strona kluczy API).
• Połącz je z listą dozwolonych adresów IP, żeby klucz przestawał działać z sieci atakującego.
• Używaj X-End-User-ID i blokowania w aplikacjach wielodostępnych (identyfikacja użytkownika końcowego).
• Przy 402 przestań — to znaczy, że kredyty się skończyły (kody błędów). Sprawdzaj saldo przed dużymi batchami (saldo użytkownika).

Jeśli klucz mógł wyciec, usuń go lub unieważnij, a nie tylko obniżaj miękki alert. Publiczna dokumentacja nie zapewnia zwrotów za wydatki z wyciekłego klucza.

---

Q6. Zdobycie klucza API Google jest tak uciążliwe, że „po prostu użyj agregatora” stało się domyślnym wyborem.

Na co skarżą się programiści: Jeden programista napisał, że wypróbuje modele Google dopiero wtedy, gdy proces rejestracji klucza API zostanie naprawiony — do tego czasu tylko OpenRouter (@sandipb). Pobliskie wpisy wciąż przedstawiały agregatory jako portfel płatności / przełącznik modeli dla agentów (@tomcritchlow), podczas gdy inni nadal żonglują tuzinem kluczy dostawców, żeby cokolwiek przetestować (@sunwei57247249).

Jak odpowiada PoYo: PoYo jest zbudowane wokół jednego jednolitego klucza dla obrazów, wideo, muzyki, 3D i czatu (llms.txt, strona główna). Klucz utworzysz na stronie kluczy API; media korzystają z asynchronicznego POST /api/generate/submit oraz statusu / webhooka; czat używa endpointów zgodnych z OpenAI, Claude Messages lub natywnych dla Gemini, zgodnie z dokumentacją każdego modelu. Zmiana modelu to inna wartość w polu model (i odpowiedni kształt endpointu dla czatu), a nie nowy proces wdrażania u kolejnego dostawcy.

Aktualne schematy wejścia i ceny znajdziesz pod https://poyo.ai/models/<id>/llms.txt oraz w indeksie katalogu (llms.txt). Dokumentacja nie twierdzi, że PoYo jest przekaźnikiem do oficjalnego konta każdego laboratorium; mówi też, że ogólna stabilność może być nieco niższa niż u oficjalnych dostawców (Getting Started). Wybierz ten kompromis świadomie.

---

Q7. Subskrypcja wideo za $59 to drogi sposób, jeśli tworzę tylko kilka klipów — a ponowienia mogą wygenerować drugi rachunek.

Na co skarżą się programiści: Twórcy porównywali miesięczne plany narzędzi wideo z API rozliczanymi za klip: jeśli robisz tylko kilka wideo AI miesięcznie, plan za $59 może okazać się drogim wyjściem, a API rozlicza za klip i można je obsługiwać agentami kodującymi (@aliteqai). Powiązany ból związany z API: pobieranie ukończonych wideo zablokowane do czasu rozliczenia płatności (@MariaOnchainDev) oraz stały lęk, że ślepe ponowienia tworzą drugie płatne zadanie.

Jak odpowiada PoYo: Wideo w PoYo jest wyceniane w kredytach za każdy udany wynik, model po modelu — przeglądaj katalog wideo w llms.txt (Sora 2, Veo 3.1, Kling, Wan, Seedance, Hailuo i inne). Schemat działania to jednolite asynchroniczne API: wyślij → odpytuj o status albo ustaw callback_url (Getting Started, webhooki). Strona główna i llms.txt podają, że nieudane zadania nie są naliczane.

Zanim zaczniesz wciskać „ponów” przy wolnym zadaniu wideo: Getting Started ostrzega, że każde ponowne wysłanie może być nową płatną pracą — sprawdź, czy oryginalne żądanie nie utworzyło już task_id. Wybieraj webhooki zamiast agresywnego odpytywania. Przy 402, 429 i 5xx kieruj się tabelą kodów błędów; nie traktuj zatrzymania z powodu kredytów jak limitu żądań.

---

Krótka mapa