Erros e tentativas

Todas as falhas nas rotas compatíveis com OpenAI usam um envelope único e legível por máquina, inclusive em /v1/completions:

{
  "error": {
    "message": "This project is archived. Unarchive it in project settings to serve requests.",
    "type": "invalid_request_error",
    "code": "project_archived",
    "param": null
  }
}

Não existe um campo FastAPI detail no nível superior dessa superfície. Use error.code, não o texto da mensagem, para decidir o comportamento.

Códigos estáveis

Código	HTTP	Retry-After	Significado
model_warming	503	sim	Capacidade fria ou temporariamente sobrecarregada. Tente após o atraso informado, com limite no cliente.
overloaded	503	sim	Código reservado de sobrecarga do provider; a sobrecarga atual de pré-admissão é normalizada para model_warming.
ambiguous_transport	502	não	O dispatch pode ter chegado ao modelo. Não repita às cegas.
upstream_error	502	não	O endpoint de serving falhou após a admissão.
model_not_supported	400	não	O modelo base nunca esteve no catálogo deste deployment.
model_deprecated	410	não	A base usada pela requisição ou pelo fine-tune foi aposentada. Treine novamente na base atual.
model_not_found	404	não	Um alias ou job bem formado não pode ser resolvido para este chamador.
invalid_request	400, 413 ou 422	não	A requisição é inválida, não informa um modelo ou excede o contexto.
insufficient_credits	402	não	A conta não pode pagar ou não tem direito ao modelo.
authentication_error	401	não	O bearer foi verificado, mas não há conta ReOpenly associada.
project_archived	404	não	O projeto é reversível, mas somente leitura até ser restaurado pelo proprietário.
internal_error	500	não	Falha inesperada do servidor. Ao contatar o suporte, informe o trace se existir.

model_deprecated é permanente para aquela base: após o corte para 9B, a produção aposentou as entradas 0.8B, 2B e 4B. Artefatos antigos continuam disponíveis para download, mas serving e publicação de aliases dessa base são bloqueados.

Política de retry

Só repita automaticamente quando a resposta trouxer explicitamente Retry-After. Hoje isso corresponde ao caminho model_warming. Use um número limitado de tentativas e preserve a identidade da requisição original. O playground v2 da primeira parte faz no máximo três novas tentativas automáticas após a requisição original e depois mantém disponível a ação manual Tentar novamente. Ele nunca repete um erro durante o streaming.

Nunca repita automaticamente:

• ambiguous_transport, pois o modelo pode já ter respondido e a cobrança pode já ter sido registrada;
• upstream_error, pois a admissão já ocorreu;
• insufficient_credits, model_deprecated e project_archived, pois é preciso alterar o estado da conta ou do projeto;
• falhas determinísticas invalid_request.

Falhas durante streaming

Antes do primeiro frame SSE, os erros usam o status HTTP e o corpo JSON normais. Depois que o stream começa, uma falha é enviada como:

data: {"error":{"message":"…","type":"api_error","code":"upstream_error","param":null}}

O servidor fecha o stream sem enviar data: [DONE]. A ausência de [DONE] significa saída incompleta, não uma resposta vazia bem-sucedida.