2026-10-27: 7 API complaints we heard today

Complaints that English-speaking developers posted publicly between Oct 25 and Oct 27, 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. The new fast model is so fast it 429s itself — especially under max reasoning and parallel Codex sessions.

What developers are complaining about: GPT-6.1 Terra launched as a fast, cheaper computer-use tier, then builders immediately hit HTTP 429 on Terra / fast-mode and under max reasoning — while the same prompt on Sol did not. Several posts noted zero tokens used on a 429, which means a concurrency or rate gate fired before metering. Parallel Codex sessions polling the same key made it worse.

How PoYo answers: Our error codes page gives 429 one meaning — rate_limit_error — and one recommended action: wait before retrying, or queue requests. Getting Started publishes the default generation limit: up to 20 new generation requests per 10 seconds, per account. Requests over that limit get HTTP 429 and do not enter the queue. Chat and media models share one PoYo key and are listed in llms.txt, so switching models is a model string change — not a new vendor onboarding. If you consistently hit 429s, the docs say you may contact support for a higher limit; approvals are handled cautiously.

The docs describe no automatic failover between providers. Build fallback into your client. Getting Started also says PoYo's "overall stability may be slightly lower than official providers."

---

Q2. My "429" was actually a spend limit — billing errors wearing rate-limit clothes.

What developers are complaining about: One post summed it up: HTTP 429 is not one failure mode. On Anthropic it can mean a rate limit, an acceleration limit, or a spend cap — and a spend-cap 429 often has no Retry-After, so waiting forever does nothing. Teams keep treating a hard billing stop like a throttle.

How PoYo answers: PoYo separates the two cases clearly in the error codes table:

Billing itself is prepaid credits: the homepage says one-time purchases with no recurring subscriptions, and credits never expire. Poll GET /api/user/balance for credits_amount when you need a live number (user balance). The error-codes tip is explicit: monitor credits to avoid 402s during critical work.

---

Q3. My agent SDK is burning the rate-limit window ~1.7× faster than chat — and N agents still share one cap.

What developers are complaining about: Anthropic acknowledged a bug in the Agents SDK that was consuming Claude 5-hour rate limits roughly 1.7× faster than expected when switching from chat to agent mode. Separately, builders noted that worktrees fix file clashes, but ten agents still share one database and one API rate limit — so parallel harnesses trip over each other on the same key.

How PoYo answers: Generation on PoYo is designed to be asynchronous, so long jobs are not tied to a single gateway timeout. Getting Started and the API overview say: submit a task, save the task_id, then poll status or receive a webhook. For production workloads, the docs prefer signed webhooks over frequent polling. On 429, wait or queue (error codes); the default gen limit remains 20 new requests / 10s per account, with overage rejected and not queued.

To keep one runaway agent from draining the whole account, use the controls documented on the API key page and Getting Started: per-key hourly, daily, and total usage caps. Image, video, music, chat, and 3D sit behind one unified API key (llms.txt, homepage).

The docs describe no automatic failover between providers. Your client must handle 429 / 5xx and choose the next model or retry path.

---

Q4. Another SaaS got my AI keys — and the vendor said the unauthorized spend is non-refundable.

What developers are complaining about: One developer reported a hacked Anthropic API key that ran up $105.94 in unauthorized usage; support (via an AI agent) said consumed usage is non-refundable and closed the escalation. The same 48-hour window kept resurfacing OpenCode Console / Railway-style breaches where stored OpenAI, Anthropic, and Google keys were the prize — rotate first, then set a hard spend ceiling.

How PoYo answers: Rotate first — a leaked secret is still a leaked secret. After that, our docs list controls that limit what a stolen PoYo key can do:

• IP whitelist. Allow only your approved server IPs on a key, so a key copied out of an env var does not work from the attacker's machine. See the API key page and Getting Started.
• Per-key usage caps (hourly, daily, and total), so one key has a hard ceiling before you notice.
• Per-end-user blocking. Send an X-End-User-ID header and you can block one abusive caller on a key without rotating it. A blocked ID returns HTTP 403 with end_user_blocked. See End-user identification.

Our public docs don't promise refunds for usage made with a leaked key. If you think a PoYo key was misused, revoke it and contact support ([email protected]).

---

Q5. An AI client should know when not to retry — and video retries can quietly double the bill.

What developers are complaining about: Retries help for temporary failures, but they are not universal. When a request is malformed, a credential is invalid, or a model is unavailable to the account, repeating the same call only adds pressure. On video APIs, the same theme shows up as "hit retry and you may create a second billed task."

How PoYo answers: Match the error to the action in error codes:

• 402 insufficient_credits_error → top up. Do not retry.
• 429 rate_limit_error → wait or queue.
• 500 / 502 / 503 → exponential backoff.
• 401 → fix the key; retrying the same bad credential will not help (Getting Started).

Getting Started also warns: treat every submission retry as potentially new paid work; confirm whether the original request created a task before resubmitting. For media, llms.txt and the homepage state that failed tasks are not charged, and billing is per successful output, priced per model. Prefer callback_url / webhooks over aggressive status polling so you don't multiply load while waiting (API overview).

---

Q6. API pricing still feels insanely expensive next to the subscription — and I can't see the live balance before the agent burns it.

What developers are complaining about: One reply put it plainly: subscriptions feel subsidized, but API pricing for OpenAI and Anthropic is "insanely expensive." Other posts in the same window asked whether people even know what a single multi-agent prompt costs at API rates, and reminded builders that ChatGPT / Codex subscription meters and API meters don't talk to each other.

How PoYo answers: Three documented pieces fit this complaint:

1. Prepaid credits, no subscription meter. The homepage describes credit-based pricing with one-time purchases, no recurring subscriptions, and credits that never expire. You pay for successful generations; failed tasks are not charged (llms.txt).
2. One key, one balance. Chat and media share one PoYo account. Poll GET /api/user/balance for credits_amount (user balance).
3. Published per-model prices. Current prices live on each model page / https://poyo.ai/models/<id>/llms.txt and in the catalog index (llms.txt) — check those before you submit paid work; don't infer dollar amounts from memory. Task history (described in Getting Started) lets you inspect model, inputs, and status after the fact.

---

Q7. My "server function" / Telegram bot is callable by anyone — and the key lives where curl can find it.

What developers are complaining about: Practical security posts kept landing: restrict API keys and set a daily quota; don't paste provider keys into chat UIs or Telegram agents; a key in a callable server function without a per-user rate limit and spend ceiling is a credit card for whoever finds the URL.

How PoYo answers: Getting Started is explicit: never expose your API key in frontend code (browser, mobile apps, public repositories). Treat the key as a secret, keep it on your server, and use the controls already documented for production keys:

• IP whitelist and per-key hourly / daily / total caps on the API key page.
• Require X-End-User-ID, then block an abusive caller with HTTP 403 end_user_blocked without rotating the whole key (End-user identification).
• Handle 401, 402, and 429 explicitly before going to production (Getting Started, error codes).

---

Quick map