Complaints that English-speaking developers posted publicly between Oct 27 and Oct 29, 2026, paraphrased below with links to the original posts. Each answer uses only what PoYo's public site and docs say today, and links to the page it comes from. Where the docs don't cover something, we say so.
Q1. My monthly ChatGPT Pro / Business API credits expire unused — and some regions can't claim them at all.
What developers are complaining about: After OpenAI framed Pro price as returning as API credit, builders immediately asked how much of that pool dies at cycle end. Posts noted that the credits are not extra ChatGPT / Codex product usage and that unused balance expires (@jayzhoupro, @velcue_07, @_jayyy18_13k), wondered aloud how many credits go unused (@mohamedsenator), and flagged Europe Pro users who couldn't claim the credits in billing (@ZindanTech).
How PoYo answers: PoYo is prepaid credits, not a monthly entitlement that resets. The homepage states credit-based pricing, no subscriptions, and that credits never expire. You pay only for successful generations; llms.txt and the homepage both say failed tasks are not charged. One balance covers the catalog — poll GET /api/user/balance for live credits_amount (user balance). When the balance is gone, PoYo returns 402 insufficient_credits_error (error codes), not a "use it or lose it" calendar window. Region-gated claim flows for another vendor's promo credits are outside PoYo's product; top up on the dashboard when you need more credits.
Q2. If Chat, Work, and Codex share one usage pool, coding quota dies first.
What developers are complaining about: The same API-credits news raised a different fear: will everyday Chat / Work traffic burn the same bucket as Codex? Builders said they would use ChatGPT less so it wouldn't affect Codex (@setHacked), argued a single Anthropic-style usage limit would kill Pro for OpenAI (@macintoch), asked whether regular Chat would stay separate from Work / Codex (@Paulkk144974), wished a merged chat+work pool would leave Codex alone (@raiden_fine), and debated the "stopped charging builders twice" framing of the credits announcement (@Awais786Muhamd).
How PoYo answers: PoYo does not sell a ChatGPT Pro / Codex subscription pool, so there is no documented "merged product quota" that silently eats coding headroom. Billing is one credit balance across image, video, music, 3D, and chat (homepage, llms.txt). If you want isolation, create separate API keys per workload and put hourly / daily / total usage caps on each key (Getting Started, API key page). For multi-tenant or multi-agent callers on one key, send X-End-User-ID and block one abusive caller with 403 end_user_blocked without rotating everyone (End-user identification). Watch the shared balance with GET /api/user/balance (user balance); on 402, stop and top up (error codes).
Q3. Codex / coding-agent walls are back — burn rate ate the week in hours.
What developers are complaining about: Coding-agent timelines again filled with usage-wall posts: planning the week around another Codex limit reset (@GaryVSAISlop), reporting Sol 6.1 via Codex CLI burned through quota ~3× faster in about 15 hours (@AssistBDA), and expecting no reset relief because of the API-credits news (@snowy_smile_).
How PoYo answers: PoYo chat is credit-priced per successful output, not a rolling Codex-style reset window (llms.txt, homepage). Chat endpoints are documented as OpenAI-compatible, Claude Messages, or Gemini-native; pick a model ID and read that model's live schema at https://poyo.ai/models/<id>/llms.txt. Cap a runaway coding agent with per-key hourly / daily / total limits on the API key page (Getting Started). Default generation throughput is up to 20 new requests per 10 seconds per account; overage returns 429 and does not enter the queue (Getting Started). Honor Retry-After on 429; do not blindly retry paid submissions until you know whether a task_id already exists (troubleshooting). The docs describe no automatic failover to another lab when an upstream coding tool hits its own wall — build that in your client if you need it.
Q4. I deleted the API key from the repo and pushed — it's probably still public in git history.
What developers are complaining about: A short post cut to the classic leak: the key was removed from the working tree and pushed, but the secret is almost certainly still reachable in git history (@patchnoteslabs).
How PoYo answers: Getting Started is blunt: never expose your API key in frontend code, mobile apps, or public repositories, and treat it as a secret. If a PoYo key may have landed in git history (or anywhere else public):
- Revoke / rotate it on the API key page — deleting the line of code is not enough.
- Turn on an IP whitelist so a copied key only works from approved server IPs.
- Set per-key hourly / daily / total caps so a lingering secret has a ceiling.
- Prefer
X-End-User-IDon generation and native chat so you can block one caller with 403end_user_blockedwithout rotating every integration (End-user identification).
Public docs do not promise refunds for usage made with a leaked key. Contact [email protected] if you believe a PoYo key was misused (Getting Started).
Q5. The tool that stored my provider keys got breached — inactive credentials funded someone else's bill.
What developers are complaining about: A post described an inactive-account API key plus an Opik AI provider-settings flaw that led to 29 OpenAI / Anthropic keys being taken (@AgentFieldKit). The pattern is familiar: credentials sitting inside a third-party "AI settings" UI become an attacker's wallet the moment that host is wrong.
How PoYo answers: Keys stored in another product's settings are a client-side secret problem. PoYo's documented controls limit blast radius once a secret exists:
- Create separate keys per environment / harness, each with hourly, daily, and total usage caps (API key page, Getting Started).
- Enable an IP allowlist for production keys.
- Prefer
X-End-User-IDso you can block one caller without deleting the key (End-user identification). - Watch live balance with
GET /api/user/balance(user balance); on 402, stop (error codes).
Delete keys you no longer use. The docs do not document auto-expiry of unused keys or a refund SLA for breach-driven spend — say so and rotate. Keep PoYo keys on your server, not in a frontend or a third-party settings form you stopped watching (Getting Started).
Q6. My agent ran for 30 hours — nothing between the code and the API had a number it wouldn't cross.
What developers are complaining about: One builder described a 30-hour agent run where nothing outside the process enforced a hard spend ceiling — the hard limit has to sit outside the job (@asymmetricmind). Nearby posts pushed spend-governance scorecards for agents that loop or over-fetch (@hacker_no_ice).
How PoYo answers: Soft alerts inside the agent are not a budget. On PoYo, put the ceiling on the credential and the balance:
- Per-key hourly / daily / total usage caps on every production key (Getting Started, API key page).
- Combine with IP whitelist for server-only keys.
- Use
X-End-User-ID+ block for multi-tenant or multi-agent apps (End-user identification). - Poll
GET /api/user/balancebefore large batches (user balance); treat 402 as a hard stop, not a retry signal (error codes). - For long async jobs, prefer webhooks over aggressive polling (webhooks); Getting Started warns that every submission retry may be new paid work — confirm
task_idbefore resubmit (troubleshooting).
The docs do not claim an out-of-process "kill switch" product beyond these key caps, balance, and error codes — wire your orchestrator to stop on 402 / capped keys.
Q7. The hardest part isn't the model — it's separate accounts, API keys, and billing systems for every creative API.
What developers are complaining about: Creators and builders said the painful part is juggling separate vendor accounts, keys, and billing (@CyberFree365). Others framed margins as an API-bill problem and looked at open models via aggregators as a cost lever (@RonaleK777), or simply hunted for a cheap LLM API at scale (@brice_garnier_).
How PoYo answers: PoYo is built as one unified key across image, video, music, 3D, and chat (llms.txt, homepage). Create a key at the API key page; media uses async POST /api/generate/submit + status/webhook; chat uses OpenAI-compatible, Claude Messages, or Gemini-native endpoints as documented per model. Switching models is a model string (and the matching endpoint shape for chat) — not a new vendor onboarding flow. Current input schemas and prices live at https://poyo.ai/models/<id>/llms.txt and in the catalog index (llms.txt). Billing is prepaid credits that never expire, charged per successful output (homepage).
The docs do not claim PoYo is a passthrough of each lab's official account; Getting Started also notes overall stability may be slightly lower than official providers. Pick the trade-off consciously.
Quick map
| Complaint | Where PoYo documents it |
|---|---|
| Monthly Pro API credits that expire / region claim gaps | Homepage: credits never expire · Balance API · Error codes: 402 |
| Fear that merged Chat/Work/Codex pools eat coding quota | One credit balance · Separate keys + caps · X-End-User-ID · Balance API |
| Codex / coding-agent usage walls & burn rate | llms.txt chat · Per-key caps · 429 + Retry-After · no documented auto-failover |
| Deleted key still in git history | Getting Started: never expose key · Rotate on API key page · IP whitelist · caps |
| Tools that store provider keys get breached | Separate keys + caps · IP whitelist · X-End-User-ID · revoke unused · no refund SLA |
| Agents with no hard spend limit outside the process | Per-key caps · Balance + 402 · Webhooks · retry may be new paid work |
| Creative-API key sprawl / separate vendor billing | One PoYo key · llms.txt catalog · per-model llms.txt · credits never expire |