2026-10-27: 7 queixas sobre APIs que ouvimos hoje

Queixas que programadores anglófonos publicaram entre 25 e 27 de outubro de 2026, resumidas abaixo por palavras nossas, com ligações para as publicações originais. Cada resposta usa apenas o que o site público e a documentação da PoYo dizem atualmente, e remete para a página de onde vem. Quando a documentação não cobre algo, dizemo-lo.

---

Q1. O novo modelo rápido é tão rápido que se dá 429 a si próprio — sobretudo com raciocínio máximo e sessões Codex em paralelo.

De que se queixam os programadores: o GPT-6.1 Terra foi lançado como um nível rápido e mais barato de utilização do computador (computer use) e, logo a seguir, quem desenvolve começou a receber HTTP 429 no Terra / modo rápido e com raciocínio máximo — enquanto o mesmo prompt no Sol não dava erro. Várias publicações notaram que um 429 consumiu zero tokens, o que significa que um limite de concorrência ou de pedidos disparou antes da contabilização. Sessões Codex em paralelo a consultar a mesma chave pioraram a situação.

Como a PoYo responde: a nossa página de códigos de erro dá ao 429 um único significado — rate_limit_error — e uma única ação recomendada: esperar antes de tentar de novo, ou pôr os pedidos em fila. O Getting Started publica o limite de geração predefinido: até 20 novos pedidos de geração por 10 segundos, por conta. Os pedidos acima desse limite recebem HTTP 429 e não entram na fila. Os modelos de chat e de multimédia partilham uma única chave PoYo e estão listados no llms.txt, pelo que mudar de modelo é só trocar a string model — não é preciso integrar um novo fornecedor. Se receberes 429 de forma recorrente, a documentação diz que podes contactar o suporte para pedir um limite mais alto; as aprovações são tratadas com cautela.

A documentação não descreve nenhum failover automático entre fornecedores. Cria o mecanismo de recurso no teu cliente. O Getting Started diz também que a “estabilidade geral da PoYo pode ser ligeiramente inferior à dos fornecedores oficiais”.

---

Q2. O meu “429” era afinal um limite de gastos — erros de faturação disfarçados de limite de pedidos.

De que se queixam os programadores: uma publicação resumiu-o bem: o HTTP 429 não é um único modo de falha. Na Anthropic pode significar um limite de pedidos, um limite de aceleração ou um teto de gastos — e um 429 de teto de gastos muitas vezes não traz Retry-After, por isso esperar indefinidamente não resolve nada. As equipas continuam a tratar uma paragem rígida de faturação como se fosse uma limitação de ritmo.

Como a PoYo responde: a PoYo separa claramente os dois casos na tabela de códigos de erro:

A faturação em si é feita com créditos pré-pagos: a página inicial fala em compras únicas, sem subscrições recorrentes, e em créditos que nunca expiram. Consulta GET /api/user/balance para obter credits_amount quando precisares de um valor em tempo real (saldo do utilizador). A dica na página de códigos de erro é explícita: monitoriza os créditos para evitar 402 durante trabalho crítico.

---

Q3. O meu agent SDK gasta a janela de limite ~1,7× mais depressa do que o chat — e N agents continuam a partilhar um único limite.

De que se queixam os programadores: a Anthropic reconheceu um erro no Agents SDK que estava a consumir os limites de 5 horas do Claude cerca de 1,7× mais depressa do que o esperado ao passar do chat para o modo agent. Noutro ponto, houve quem notasse que os worktrees resolvem os conflitos de ficheiros, mas dez agents continuam a partilhar uma base de dados e um limite de pedidos da API — pelo que os harnesses em paralelo chocam entre si na mesma chave.

Como a PoYo responde: a geração na PoYo foi concebida para ser assíncrona, pelo que as tarefas longas não ficam presas a um único timeout do gateway. O Getting Started e a visão geral da API dizem: submete uma tarefa, guarda o task_id e depois consulta o estado ou recebe um webhook. Para cargas de produção, a documentação prefere webhooks assinados a consultas frequentes. Perante um 429, espera ou põe em fila (códigos de erro); o limite de geração predefinido continua a ser 20 novos pedidos / 10 s por conta, com o excedente rejeitado e não colocado em fila.

Para evitar que um único agent descontrolado esgote a conta inteira, usa os controlos documentados na página de chaves de API e no Getting Started: limites de utilização por chave, por hora, por dia e totais. Imagem, vídeo, música, chat e 3D ficam todos atrás de uma única chave de API unificada (llms.txt, página inicial).

A documentação não descreve nenhum failover automático entre fornecedores. O teu cliente tem de tratar os 429 / 5xx e escolher o modelo seguinte ou o caminho de nova tentativa.

---

Q4. Outro SaaS ficou com as minhas chaves de IA — e o fornecedor disse que os gastos não autorizados não são reembolsáveis.

De que se queixam os programadores: um programador relatou uma chave da Anthropic comprometida que gerou $105.94 de utilização não autorizada; o suporte (através de um agente de IA) disse que a utilização consumida não é reembolsável e encerrou o caso. Na mesma janela de 48 horas voltaram a surgir violações ao estilo do OpenCode Console / Railway, em que as chaves da OpenAI, da Anthropic e da Google guardadas eram o prémio — primeiro roda a chave, depois define um teto de gastos rígido.

Como a PoYo responde: primeiro, roda a chave — um segredo divulgado continua a ser um segredo divulgado. Depois disso, a nossa documentação indica controlos que limitam o que uma chave PoYo roubada pode fazer:

• Lista de IPs permitidos. Permite apenas os IPs dos teus servidores aprovados numa chave, para que uma chave copiada de uma variável de ambiente não funcione a partir da máquina do atacante. Vê a página de chaves de API e o Getting Started.
• Limites de utilização por chave (por hora, por dia e totais), para que cada chave tenha um teto rígido antes de reparares.
• Bloqueio por utilizador final. Envia um cabeçalho X-End-User-ID e podes bloquear um autor de abusos numa chave sem a rodar. Um ID bloqueado devolve HTTP 403 com end_user_blocked. Vê Identificação do utilizador final.

A nossa documentação pública não promete reembolsos por utilização feita com uma chave divulgada. Se achas que uma chave PoYo foi utilizada indevidamente, revoga-a e contacta o suporte (support@poyo.ai).

---

Q5. Um cliente de IA devia saber quando não repetir — e repetir pedidos de vídeo pode duplicar a fatura sem darmos por isso.

De que se queixam os programadores: repetir ajuda em falhas temporárias, mas não serve para tudo. Quando um pedido está malformado, uma credencial é inválida ou um modelo não está disponível para a conta, repetir a mesma chamada só aumenta a pressão. Nas APIs de vídeo, o mesmo tema surge como “se carregares em repetir, podes criar uma segunda tarefa faturada”.

Como a PoYo responde: faz corresponder o erro à ação nos códigos de erro:

• 402 insufficient_credits_error → recarrega. Não repitas.
• 429 rate_limit_error → espera ou põe em fila.
• 500 / 502 / 503 → backoff exponencial.
• 401 → corrige a chave; repetir a mesma credencial inválida não ajuda (Getting Started).

O Getting Started avisa ainda: trata cada nova tentativa de submissão como potencial novo trabalho pago; confirma se o pedido original criou uma tarefa antes de voltares a submeter. Para multimédia, o llms.txt e a página inicial indicam que as tarefas falhadas não são cobradas e que a faturação é por resultado bem-sucedido, com preço por modelo. Prefere callback_url / webhooks a consultas agressivas do estado, para não multiplicares a carga enquanto esperas (visão geral da API).

---

Q6. Os preços da API continuam a parecer caríssimos ao lado da subscrição — e não consigo ver o saldo em tempo real antes de o agent o gastar.

De que se queixam os programadores: uma resposta disse-o sem rodeios: as subscrições parecem subsidiadas, mas os preços da API da OpenAI e da Anthropic são “caríssimos”. Outras publicações da mesma janela perguntavam se as pessoas sequer sabem quanto custa um único prompt multi-agent aos preços da API, e lembravam que os contadores das subscrições do ChatGPT / Codex e os contadores da API não comunicam entre si.

Como a PoYo responde: três elementos documentados respondem a esta queixa:

1. Créditos pré-pagos, sem contador de subscrição. A página inicial descreve preços baseados em créditos, com compras únicas, sem subscrições recorrentes e com créditos que nunca expiram. Pagas as gerações bem-sucedidas; as tarefas falhadas não são cobradas (llms.txt).
2. Uma chave, um saldo. O chat e a multimédia partilham uma única conta PoYo. Consulta GET /api/user/balance para obter credits_amount (saldo do utilizador).
3. Preços publicados por modelo. Os preços atuais estão em cada página de modelo / https://poyo.ai/models/<id>/llms.txt e no índice do catálogo (llms.txt) — consulta-os antes de submeteres trabalho pago; não deduzas valores em dólares de memória. O histórico de tarefas (descrito no Getting Started) permite verificar a posteriori o modelo, as entradas e o estado.

---

Q7. A minha “server function” / o meu bot do Telegram pode ser chamado por qualquer pessoa — e a chave está onde o curl a encontra.

De que se queixam os programadores: continuaram a surgir publicações práticas sobre segurança: restringe as chaves de API e define uma quota diária; não coles chaves de fornecedores em interfaces de chat nem em agentes do Telegram; uma chave numa server function acessível sem limite por utilizador nem teto de gastos é um cartão de crédito para quem encontrar o URL.

Como a PoYo responde: o Getting Started é explícito: nunca exponhas a tua chave de API em código frontend (browser, aplicações móveis, repositórios públicos). Trata a chave como um segredo, mantém-na no teu servidor e usa os controlos já documentados para chaves de produção:

• Lista de IPs permitidos e limites por chave, por hora / dia / totais na página de chaves de API.
• Exige X-End-User-ID e depois bloqueia quem abusa com HTTP 403 end_user_blocked, sem rodar a chave inteira (Identificação do utilizador final).
• Trata explicitamente 401, 402 e 429 antes de ires para produção (Getting Started, códigos de erro).

---

Mapa rápido