Quando o limite de imagens do Grok reinicia? Cota, limite de requisições e design de API

Separe cota diária, janela móvel, limite por minuto, plano da conta e recusa por política antes de desenhar uma rota alternativa.

Conclusão principalNão tente adivinhar um horário fixo de reinício: identifique primeiro o tipo de limite e decida o próximo passo pelos cabeçalhos da resposta, pelo estado da conta e por códigos de erro estáveis.

Resposta rápida

Não existe um horário de reinício válido para todas as contas. Identifique primeiro qual limite você atingiu. Uma cota diária reinicia em um horário fixo no fuso da conta. Uma janela móvel se recupera aos poucos, 24 horas depois da requisição mais antiga. Um limite por minuto normalmente libera em dezenas de segundos e informa a espera no Retry-After. O teto do plano só muda quando o plano ou o período de cobrança muda. E uma recusa por política de conteúdo não vira permissão só porque você esperou. Confie na interface da sua conta e nos cabeçalhos da resposta, não em um horário fixo citado em um artigo.

Comece pela pergunta por trás da busca

A pergunta “quando reseta?” mistura cinco estados: cota diária, janela móvel, limite por minuto, teto do plano e recusa por política. De fora todos parecem iguais, mas o tempo de espera, se vale tentar de novo e se dá para trocar de modelo mudam em cada caso. Além disso, as regras da plataforma mudam, então nenhum artigo estático substitui a mensagem que aparece na sua conta.

Escolha pela tarefa

Cinco estados que parecem “agora não dá para gerar”, com esperas e respostas corretas bem diferentes.

Estado	Sinal típico	Quando volta	Tratamento correto
Limite por minuto	429 com Retry-After	Em dezenas de segundos	Enfileire e tente de novo conforme o Retry-After, com teto de tentativas
Cota diária	A conta mostra as gerações restantes	Um horário fixo no fuso da conta	Mostre a informação da conta em vez de tentar de novo
Janela móvel	As gerações voltam aos poucos	24 horas após a requisição mais antiga	Não prometa uma meia-noite específica
Teto do plano	O erro menciona o plano ou a assinatura	Ao mudar de plano ou iniciar novo período	Leve o usuário à cobrança, não a um estado de erro
Recusa por política	moderated ou uma categoria de política	Esperar nunca resolve	Use uma rota de produto separada; veja por que o Grok marca uma imagem como moderated

Como avaliar além de uma demo

Verifique o status HTTP, o Retry-After, o código de erro do fornecedor e o plano da conta em vez de analisar apenas o texto da mensagem.
Um 429 costuma ser limite de requisições, mas concorrência momentânea, janela por minuto e cotas mais longas exigem tratamentos diferentes.
Uma recusa por política não vira permissão à meia-noite: ela precisa de uma rota de produto própria.
Se a interface mostrar quando será possível tentar de novo, informe a origem desse dado; se não souber, diga que não sabe.

Opções do ModelRush para esse trabalho

No ModelRush, o Grok 4.6 é um modelo de texto: os limites dele não são os de um produto de imagem.
Se um trabalho de imagem permitido precisa de capacidade independente, escolha explicitamente o Z-Image Spicy ou o Wan 2.7 Image Pro.
Não troque de modelo em silêncio: a mudança de estilo, de preço e de rota de dados precisa aparecer no registro do trabalho.

Um fluxo de produção reproduzível

Traduza as respostas do fornecedor para quota_exhausted, rate_limited, policy_rejected, provider_unavailable e invalid_request. Enfileire automaticamente apenas os trabalhos rate_limited seguindo o Retry-After; para cota esgotada, mostre a informação da conta; e use a rota alternativa autorizada pelo usuário somente quando o serviço estiver indisponível. Guarde attempt, provider, region, custo e estado final, com uma chave de idempotência que evite enviar o mesmo trabalho duas vezes quando a fila se recuperar.

Perguntas frequentes

O limite de imagens do Grok reinicia à meia-noite?

Não presuma isso. Uma conta pode usar cota diária ou janela móvel; siga a mensagem da conta e a resposta da API.

Vale tentar de novo imediatamente depois de um 429?

Não. Siga o Retry-After ou um backoff exponencial, com teto de tentativas e prazo final.

O aplicativo pode trocar automaticamente para o ModelRush?

A rota alternativa faz sentido quando o usuário consentiu, a requisição é permitida e a mudança de modelo e de preço é explícita. Nunca para contornar uma recusa por política.

Use o rastreio de requisições do ModelRush para manter o tipo de limite, as tentativas e a rota alternativa sob um mesmo request_id.