Queixas que programadores anglófonos publicaram entre 26 e 28 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 Claude Code bateu no limite de utilização a meio de uma refatoração — e continua a não haver uma forma limpa de “passar para a minha chave de API”.
De que se queixam os programadores: as timelines de 27 e 28 de outubro estavam cheias de capturas de ecrã lado a lado dos limites de utilização do Claude Code / Codex. Houve quem perguntasse se o Claude Code consegue passar para uma chave de API quando os limites da subscrição são atingidos (@irl_danB), quem brincasse que bater no limite a meio de uma refatoração é o novo “esqueci-me de guardar” (@automater_ai) e quem comparasse planos de 20 $ que parecem inúteis numa stack enquanto outra subscrição Plus nunca chega ao limite (@mozdca, @LeoZhang57).
Como a PoYo responde: a PoYo funciona com créditos pré-pagos, não com uma janela de subscrição de 5 horas / semanal. A página inicial descreve compras de créditos únicas, sem subscrições recorrentes, e créditos que nunca expiram. Pagas as gerações bem-sucedidas; o llms.txt indica que as tarefas falhadas não são cobradas. O chat e a multimédia partilham uma única chave de API e um único saldo — consulta GET /api/user/balance para obter o credits_amount em tempo real (saldo do utilizador).
Quando o saldo acaba, a PoYo devolve 402 insufficient_credits_error, e não uma janela de utilização rotativa disfarçada de limitação (códigos de erro). Não existe nenhuma funcionalidade documentada de failover “subscrição → chave de API”, porque a faturação já é baseada em créditos. Limita um agent descontrolado com os limites de utilização por chave, por hora / dia / totais, na página de chaves de API (Getting Started).
Q2. O “429” do Claude Code são três mensagens diferentes — esperar indefinidamente só ajuda numa delas.
De que se queixam os programadores: um tópico de resolução de problemas chamou a atenção para o facto de o Claude Code poder apresentar três falhas com forma de 429 — esperar por uma reposição, tentar de novo daqui a um momento ou verificar a chave de API — e cada uma exige uma solução diferente (@aiparabellum). Noutro ponto, houve quem perguntasse se os problemas de limites de pedidos nas ferramentas de agents da Anthropic já tinham sido corrigidos (@XavierDelon, @GeorgeMathew_).
Como a PoYo responde: os nossos códigos de erro mantêm a faturação e os limites de pedidos em números diferentes:
| Código | error.type | Significado / o que fazer |
|---|---|---|
| 401 | authentication_error | Chave inválida ou em falta. Corrige a credencial — não repitas com a mesma chave inválida (Getting Started). |
| 402 | insufficient_credits_error | O saldo acabou. Recarrega. Tentar de novo não ajuda. |
| 429 | rate_limit_error | Limite de pedidos. Espera ou põe em fila. |
| 500 / 502 / 503 | internal_error / upstream_error / service_error | Backoff exponencial. |
O débito de geração predefinido está documentado como até 20 novos pedidos por 10 segundos por conta; o excedente recebe HTTP 429 e não entra na fila (Getting Started). A resolução de problemas de integração diz também: respeita o Retry-After nos limites de pedidos e não repitas às cegas uma submissão paga até saberes se foi criado um task_id (resolução de problemas).
A documentação não descreve nenhum failover automático entre fornecedores a montante. Cria-o no teu cliente.
Q3. Qualquer chave de API que alguma vez colei no chat do agent continua nos registos do projeto.
De que se queixam os programadores: depois de um tópico sobre os registos de projetos do Claude, uma resposta foi direta ao risco: qualquer chave de API que tenhas colado no chat está também nesses registos — faz grep de sk- em ~/.claude/projects e roda tudo o que aparecer (@wazX_7). Publicações próximas insistiam na mesma higiene: trata as chaves de IA como credenciais de root (@RuntimeAI_io) e deixa de dar a cada agent uma chave partilhada sem interruptor de emergência (@RohanBhanotAI).
Como a PoYo responde: o Getting Started é frontal: nunca exponhas a tua chave de API em código frontend, aplicações móveis ou repositórios públicos, e trata-a como um segredo. Mantém as chaves no teu servidor. Depois de a colares ou de suspeitares de uma fuga:
- Revoga / roda a chave na página de chaves de API.
- Lista de IPs permitidos, para que uma chave copiada só funcione a partir de IPs de servidores aprovados.
- Limites por chave, por hora / dia / totais, para que uma fuga tenha um teto.
- Envia
X-End-User-IDna geração e no chat nativo; bloqueia quem abusa com HTTP 403end_user_blocked, sem rodar a chave inteira (Identificação do utilizador final).
A nossa documentação pública não promete reembolsos por utilização feita com uma chave divulgada. Contacta support@poyo.ai se acreditas que uma chave PoYo foi utilizada indevidamente.
Q4. A minha chave de agregador esquecida continua a ser uma carteira de agent — uma violação de um anfitrião transformou credenciais inativas numa tarefa de 500 passos.
De que se queixam os programadores: uma publicação avisava que uma chave esquecida do OpenRouter continua a ser uma carteira de agent: uma violação ao estilo do Railway pôs chaves inativas numa lista de alvos, e uma delas já tinha financiado uma tarefa de agent de 500 passos, enquanto os dashboards mostravam tráfego zero até então. A solução apontada: limites de gastos, chaves de curta duração e nenhum token de fornecedor em anfitriões que deixaste de vigiar (@neiro_go_neiro). Outra resposta associava o mesmo padrão a fornecedores que continuam a revogar chaves semanas depois das violações (@Kenz_1604).
Como a PoYo responde: chaves inativas em anfitriões abandonados são um problema de segredos do lado do cliente; os controlos documentados da PoYo limitam o raio de impacto quando um segredo já existe:
- Cria chaves separadas por ambiente / harness, cada uma com limites de utilização por hora, por dia e totais (página de chaves de API, Getting Started).
- Ativa uma lista de IPs permitidos nas chaves de produção.
- Prefere
X-End-User-ID, para poderes bloquear um autor de pedidos sem apagar a chave (Identificação do utilizador final). - Acompanha o saldo em tempo real com
GET /api/user/balance(saldo do utilizador) e o histórico de tarefas no dashboard (Getting Started).
Apaga as chaves que já não utilizas. A documentação não refere a expiração automática de chaves não utilizadas nem um SLA de reembolso para gastos resultantes de violações — diz-o e roda a chave.
Q5. Defini um limite rígido de gastos de IA — e depois alguém obteve a chave e ultrapassou-o durante a noite.
De que se queixam os programadores: um programador definiu um limite de fatura de IA de $25; alguém obteve a chave de API e levou-a a $55 numa só noite (@twentyonemilll). O tema coincide com tópicos mais antigos do OpenRouter, em que desativar não chegava e só apagar a chave por completo travou a sangria — mas a janela de 28 de outubro continua a produzir a mesma queixa: “o limite existia, a fuga doeu na mesma”.
Como a PoYo responde: os limites só ajudam se forem aplicados à credencial comprometida, e não apenas a um orçamento indicativo num dashboard. Na PoYo:
- Define limites de utilização por chave, por hora / dia / totais, em todas as chaves de produção (Getting Started, página de chaves de API).
- Combina com a lista de IPs permitidos, para que a chave falhe a partir da rede do atacante.
- Usa
X-End-User-ID+ bloqueio em aplicações multi-tenant (Identificação do utilizador final). - Com um 402, pára — significa que os créditos acabaram (códigos de erro). Consulta o saldo antes de batches grandes (saldo do utilizador).
Se uma chave puder estar exposta, apaga-a / revoga-a, não te limites a reduzir um alerta indicativo. A documentação pública não garante reembolsos de gastos feitos com uma chave divulgada.
Q6. Obter uma chave de API da Google é tão penoso que “usar só um agregador” passou a ser o padrão.
De que se queixam os programadores: um programador disse que só vai experimentar os modelos da Google se o processo de registo da chave de API for corrigido — até lá, é só OpenRouter (@sandipb). Publicações próximas continuavam a apresentar os agregadores como a carteira de pagamento / o seletor de modelos dos agents (@tomcritchlow), enquanto outros ainda andam a gerir uma dúzia de chaves de fornecedores só para testar (@sunwei57247249).
Como a PoYo responde: a PoYo foi concebida com uma única chave unificada para imagem, vídeo, música, 3D e chat (llms.txt, página inicial). Cria uma chave na página de chaves de API; a multimédia usa POST /api/generate/submit assíncrono + estado/webhook; o chat usa endpoints compatíveis com a OpenAI, Claude Messages ou nativos da Gemini, conforme documentado por modelo. Mudar de modelo é trocar uma string model (e a forma do endpoint correspondente, no caso do chat) — não é um novo processo de integração de fornecedor.
Os esquemas de entrada e os preços atuais estão em https://poyo.ai/models/<id>/llms.txt e no índice do catálogo (llms.txt). A documentação não afirma que a PoYo seja uma passagem direta da conta oficial de cada laboratório; diz também que a estabilidade geral pode ser ligeiramente inferior à dos fornecedores oficiais (Getting Started). Escolhe esta troca de forma consciente.
Q7. Uma subscrição de vídeo de $59 é a forma cara de entrar se só entregar alguns clipes — e as repetições podem inventar uma segunda fatura.
De que se queixam os programadores: criadores compararam planos mensais de ferramentas de vídeo com APIs de pagamento por clipe: se só fizeres alguns vídeos com IA por mês, um plano de $59 pode ser o caminho caro, enquanto uma API cobra por clipe e os agents de programação podem geri-la (@aliteqai). Uma dor relacionada nas APIs: transferências de vídeos concluídos condicionadas à liquidação da faturação (@MariaOnchainDev) e o receio constante de que repetições cegas criem uma segunda tarefa cobrada.
Como a PoYo responde: o vídeo na PoYo tem preço em créditos por resultado bem-sucedido, modelo a modelo — explora o catálogo de vídeo no llms.txt (Sora 2, Veo 3.1, Kling, Wan, Seedance, Hailuo e mais). O fluxo é o da API assíncrona unificada: submeter → consultar o estado ou definir callback_url (Getting Started, webhooks). A página inicial e o llms.txt indicam ambos que as tarefas falhadas não são cobradas.
Antes de insistires em repetir uma tarefa de vídeo lenta: o Getting Started avisa que cada repetição de submissão pode ser novo trabalho pago — confirma se o pedido original já criou um task_id. Prefere webhooks a consultas agressivas. Para 402 vs 429 vs 5xx, segue a tabela de códigos de erro; não trates uma paragem por créditos como um limite de pedidos.
Mapa rápido
| Queixa | Onde a PoYo a documenta |
|---|---|
| Limites de utilização / sem failover subscrição→API | Página inicial: créditos · API de saldo · Códigos de erro: 402 · Limites da chave de API |
| 429 com três falhas diferentes | Códigos de erro: 401 / 402 / 429 / 5xx · Getting Started: limites de pedidos · Resolução de problemas |
| Chaves coladas em registos de agents | Getting Started: nunca expor a chave · Página de chaves de API · X-End-User-ID |
| Chaves de agregadores inativas após violações de anfitriões | Limites da chave de API · Lista de IPs permitidos · Saldo + histórico de tarefas · revogar chaves não utilizadas |
| Limite de gastos ultrapassado por uma chave divulgada | Limites por chave · Lista de IPs permitidos · X-End-User-ID · tratamento do 402 |
| Integração penosa de chaves de fornecedores / dispersão de chaves | Uma chave PoYo · catálogo llms.txt · llms.txt por modelo |
| Subscrição de vídeo vs preço por clipe + faturação de repetições | Catálogo de vídeo · submissão/estado assíncronos · falhadas não são cobradas · repetir = novo trabalho pago |