Queixas que programadores anglófonos publicaram entre 27 e 29 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. Os meus créditos de API mensais do ChatGPT Pro / Business expiram sem serem usados — e algumas regiões nem sequer os conseguem reclamar.
De que se queixam os programadores: depois de a OpenAI ter apresentado o preço do Pro como devolvido em crédito de API, quem desenvolve perguntou de imediato quanto desse pool morre no fim do ciclo. Algumas publicações notaram que os créditos não são utilização adicional dos produtos ChatGPT / Codex e que o saldo não utilizado expira (@jayzhoupro, @velcue_07, @_jayyy18_13k), perguntaram em voz alta quantos créditos ficam por usar (@mohamedsenator) e assinalaram utilizadores europeus do Pro que não conseguiam reclamar os créditos na faturação (@ZindanTech).
Como a PoYo responde: a PoYo funciona com créditos pré-pagos, não com um direito mensal que é reposto. A página inicial indica preços baseados em créditos, sem subscrições, e que os créditos nunca expiram. Pagas apenas as gerações bem-sucedidas; o llms.txt e a página inicial dizem ambos que as tarefas falhadas não são cobradas. Um só saldo cobre todo o catálogo — 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 (códigos de erro), e não uma janela de calendário do tipo “usa ou perde”. Os processos de reclamação por região de créditos promocionais de outro fornecedor ficam fora do produto da PoYo; recarrega no dashboard quando precisares de mais créditos.
Q2. Se o Chat, o Work e o Codex partilham um único pool de utilização, a quota de programação morre primeiro.
De que se queixam os programadores: a mesma notícia sobre créditos de API suscitou outro receio: será que o tráfego diário de Chat / Work vai gastar o mesmo balde que o Codex? Houve quem dissesse que ia usar menos o ChatGPT para não afetar o Codex (@setHacked), quem argumentasse que um único limite de utilização ao estilo da Anthropic acabaria com o Pro da OpenAI (@macintoch), quem perguntasse se o Chat normal se manteria separado do Work / Codex (@Paulkk144974), quem desejasse que um pool unido de chat+work deixasse o Codex em paz (@raiden_fine) e quem debatesse a ideia de “deixámos de cobrar duas vezes a quem desenvolve” no anúncio dos créditos (@Awais786Muhamd).
Como a PoYo responde: a PoYo não vende um pool de subscrição ChatGPT Pro / Codex, pelo que não existe nenhuma “quota de produto unificada” documentada que gaste em silêncio a margem de programação. A faturação é um único saldo de créditos para imagem, vídeo, música, 3D e chat (página inicial, llms.txt). Se queres isolamento, cria chaves de API separadas por carga de trabalho e define limites de utilização por hora / dia / totais em cada chave (Getting Started, página de chaves de API). Para quem chama em aplicações multi-tenant ou com vários agents na mesma chave, envia X-End-User-ID e bloqueia quem abusa com 403 end_user_blocked, sem rodar a chave de todos (Identificação do utilizador final). Acompanha o saldo partilhado com GET /api/user/balance (saldo do utilizador); com um 402, pára e recarrega (códigos de erro).
Q3. As barreiras do Codex / dos agents de programação estão de volta — o ritmo de consumo gastou a semana em horas.
De que se queixam os programadores: as timelines de agents de programação voltaram a encher-se de publicações sobre barreiras de utilização: planear a semana em torno de mais uma reposição do limite do Codex (@GaryVSAISlop), relatar que o Sol 6.1 através do Codex CLI gastou a quota cerca de 3× mais depressa em cerca de 15 horas (@AssistBDA) e não esperar qualquer alívio na reposição por causa da notícia dos créditos de API (@snowy_smile_).
Como a PoYo responde: o chat da PoYo tem preço em créditos por resultado bem-sucedido, e não uma janela de reposição rotativa ao estilo do Codex (llms.txt, página inicial). Os endpoints de chat estão documentados como compatíveis com a OpenAI, Claude Messages ou nativos da Gemini; escolhe um ID de modelo e lê o esquema atual desse modelo em https://poyo.ai/models/<id>/llms.txt. Limita um agent de programação descontrolado com limites por chave, por hora / dia / totais, na página de chaves de API (Getting Started). O débito de geração predefinido é de até 20 novos pedidos por 10 segundos por conta; o excedente devolve 429 e não entra na fila (Getting Started). Respeita o Retry-After num 429; não repitas às cegas submissões pagas até saberes se já existe um task_id (resolução de problemas). A documentação não descreve nenhum failover automático para outro laboratório quando uma ferramenta de programação a montante bate na sua própria barreira — cria-o no teu cliente, se precisares.
Q4. Apaguei a chave de API do repositório e fiz push — provavelmente continua pública no histórico do git.
De que se queixam os programadores: uma publicação curta foi direta à fuga clássica: a chave foi removida da árvore de trabalho e foi feito push, mas o segredo continua quase de certeza acessível no histórico do git (@patchnoteslabs).
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. Se uma chave PoYo possa ter ido parar ao histórico do git (ou a qualquer outro sítio público):
- Revoga / roda a chave na página de chaves de API — apagar a linha de código não chega.
- Ativa uma lista de IPs permitidos, para que uma chave copiada só funcione a partir de IPs de servidores aprovados.
- Define limites por chave, por hora / dia / totais, para que um segredo que persista tenha um teto.
- Prefere
X-End-User-IDna geração e no chat nativo, para poderes bloquear um autor de pedidos com 403end_user_blockedsem rodares todas as integrações (Identificação do utilizador final).
A 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 (Getting Started).
Q5. A ferramenta que guardava as minhas chaves de fornecedores foi violada — credenciais inativas financiaram a fatura de outra pessoa.
De que se queixam os programadores: uma publicação descrevia uma chave de API de uma conta inativa e uma falha nas definições de fornecedores do Opik AI que levou ao roubo de 29 chaves da OpenAI / Anthropic (@AgentFieldKit). O padrão é conhecido: credenciais dentro de uma interface de “definições de IA” de terceiros transformam-se na carteira de um atacante no momento em que esse anfitrião falha.
Como a PoYo responde: chaves guardadas nas definições de outro produto 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); com um 402, pára (códigos de erro).
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. Mantém as chaves da PoYo no teu servidor, e não num frontend nem num formulário de definições de terceiros que deixaste de vigiar (Getting Started).
Q6. O meu agent correu durante 30 horas — nada entre o código e a API tinha um número que não pudesse ser ultrapassado.
De que se queixam os programadores: um programador descreveu uma execução de agent de 30 horas em que nada fora do processo impunha um teto de gastos rígido — o limite rígido tem de ficar fora da tarefa (@asymmetricmind). Publicações próximas defendiam scorecards de governação de gastos para agents que entram em ciclo ou fazem pedidos em excesso (@hacker_no_ice).
Como a PoYo responde: alertas indicativos dentro do agent não são um orçamento. Na PoYo, põe o teto na credencial e no saldo:
- 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 em chaves só para servidor.
- Usa
X-End-User-ID+ bloqueio em aplicações multi-tenant ou com vários agents (Identificação do utilizador final). - Consulta
GET /api/user/balanceantes de batches grandes (saldo do utilizador); trata o 402 como uma paragem rígida, não como um sinal para repetir (códigos de erro). - Em tarefas assíncronas longas, prefere webhooks a consultas agressivas (webhooks); o Getting Started avisa que cada repetição de submissão pode ser novo trabalho pago — confirma o
task_idantes de voltares a submeter (resolução de problemas).
A documentação não apresenta nenhum “interruptor de emergência” fora do processo para além destes limites por chave, do saldo e dos códigos de erro — configura o teu orquestrador para parar perante um 402 / chaves no limite.
Q7. O mais difícil não é o modelo — são as contas, chaves de API e sistemas de faturação separados para cada API criativa.
De que se queixam os programadores: criadores e programadores disseram que a parte penosa é gerir contas de fornecedores, chaves e faturação separadas (@CyberFree365). Outros apresentaram as margens como um problema de fatura de API e olharam para modelos abertos através de agregadores como alavanca de custos (@RonaleK777), ou procuraram simplesmente uma API de LLM barata em grande escala (@brice_garnier_).
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 faturação é feita com créditos pré-pagos que nunca expiram, cobrados por resultado bem-sucedido (página inicial).
A documentação não afirma que a PoYo seja uma passagem direta da conta oficial de cada laboratório; o Getting Started nota também que a estabilidade geral pode ser ligeiramente inferior à dos fornecedores oficiais. Escolhe esta troca de forma consciente.
Mapa rápido
| Queixa | Onde a PoYo a documenta |
|---|---|
| Créditos de API mensais do Pro que expiram / lacunas na reclamação por região | Página inicial: créditos nunca expiram · API de saldo · Códigos de erro: 402 |
| Receio de que pools unidos de Chat/Work/Codex consumam a quota de programação | Um único saldo de créditos · Chaves separadas + limites · X-End-User-ID · API de saldo |
| Barreiras de utilização e ritmo de consumo do Codex / agents de programação | llms.txt chat · Limites por chave · 429 + Retry-After · sem failover automático documentado |
| Chave apagada que continua no histórico do git | Getting Started: nunca expor a chave · Rodar na página de chaves de API · Lista de IPs permitidos · limites |
| Ferramentas que guardam chaves de fornecedores são violadas | Chaves separadas + limites · Lista de IPs permitidos · X-End-User-ID · revogar as não utilizadas · sem SLA de reembolso |
| Agents sem limite de gastos rígido fora do processo | Limites por chave · Saldo + 402 · Webhooks · repetir pode ser novo trabalho pago |
| Dispersão de chaves de APIs criativas / faturação separada por fornecedor | Uma chave PoYo · catálogo llms.txt · llms.txt por modelo · créditos nunca expiram |