Coloque uma solicitação de volta nos trilhos.

Verifique o status do serviço e depois separe problemas de acesso à conta, autenticação de API, descoberta de modelo, inferência e pagamento. Um modelo que aparece no catálogo não estabelece disponibilidade ao vivo: GET /v1/models lista implantações conectadas.

Um 503 service_unavailable significa que o serviço necessário não pode aceitar a solicitação. Verifique o status do serviço e a referência da API antes de tentar novamente; solicitações repetidas não podem habilitar um serviço indisponível. Para uma GPU dedicada, aguarde o provisionamento confirmado. Para pagamentos, siga as instruções da ordem e o status de verificação registrado; atualizar uma ordem não adiciona crédito.

Registre o status HTTP e o code e o message do erro. Verifique a URL base da API configurada, o ID exato do modelo e a versão do cliente antes de alterar a lógica da aplicação.

• 401: verifique o cabeçalho Bearer e se a chave foi revogada. Mantenha a chave completa fora dos logs.
• 403: escolha um modelo permitido pela lista de permissões da chave.
• 400 ou 413: verifique o JSON, os campos obrigatórios, o limite de saída e o orçamento combinado de contexto de entrada/saída.
• 402: verifique se a conta tem uma recarga confirmada qualificada de pelo menos USD 100; depois verifique o crédito disponível e o orçamento da chave selecionada. Contas qualificadas não precisam manter um saldo de USD 100.
• 429: siga um cabeçalho Retry-After, se fornecido; use novas tentativas limitadas e verifique os limites de serviço aplicáveis; não há franquia diária de avaliação gratuita.
• 502 ou 503: verifique a disponibilidade e a mensagem de erro antes de uma nova tentativa limitada.

O guia de erros e os limites explicam os caminhos de recuperação. Uma nova solicitação pode criar novo trabalho; não presuma que as novas tentativas do cliente sejam deduplicadas.

Uma aba do navegador fechada, tempo limite ou fluxo quebrado não prova que a geração parou. Salve qualquer identificador de resposta e o quadro de uso final, se recebido. O quadro de uso final pode chegar após o finish_reason da escolha; um pedaço de rede não é necessariamente um evento completo.

Um 409 pending_reconciliation, ou um erro upstream após o envio, pode deixar crédito reservado até que o uso autoritativo esteja disponível. Evite enviar solicitações duplicadas para limpar a retenção. Compare o horário UTC, modelo e nome da chave com o uso do console e retenha os detalhes da solicitação para reconciliação. Os tempos de liberação não são garantidos.

Para um problema de pagamento, registre a referência da ordem, ativo, rede, valor e status visível. Nunca envie outro pagamento apenas porque o primeiro está pendente. Saques de carteira estão atualmente indisponíveis. Cancelar uma ordem de GPU paga antes da ativação devolve o pagamento ao saldo da conta WeightsAPI; ele não transfere fundos para uma carteira.

Um relatório útil inclui a operação, o carimbo de data/hora UTC, o caminho do endpoint, o ID do modelo, o SDK ou a integração e a versão, a configuração de streaming, o limite de tokens de saída, o status/erro, o resultado esperado e o resultado real. Inclua uma referência de resposta ou transação somente se disponível; o gateway atualmente não expõe um ID de suporte em todos os erros.

Adicione o menor exemplo sintético que reproduza o problema. Substitua conversas reais, registros de clientes e documentos privados por texto inventado. Inclua contagens de novas tentativas relevantes e se o problema se repete entre solicitações. As capturas de tela devem mostrar o erro e o contexto após remover credenciais, saldos ou identificadores que você não pretende compartilhar.

Para um pedido de GPU dedicada, inclua a referência do pedido, a configuração e o status visível de pagamento ou provisionamento. Um pedido pendente não é uma máquina ativa.

Nunca inclua um segredo de API, cabeçalho Authorization, cookie de sessão, chave privada de carteira, frase de recuperação ou arquivo de ambiente completo. Um nome de chave ou prefixo deliberadamente encurtado é suficiente para distinguir aplicações. Referências de transações públicas ainda podem conectar atividade a uma carteira; compartilhe apenas o que a investigação precisa.

Se uma chave foi exposta, crie uma substituição, atualize a aplicação e revogue a chave antiga. A revogação bloqueia novas admissões; solicitações anteriormente admitidas são liquidadas normalmente. Consulte autenticação para manuseio de chaves.

Copie e revise seu relatório, depois mantenha-o com a referência de solicitação ou ordem relevante. Copiar não envia um ticket. Contatos de suporte oficiais e horários de serviço não estão publicados; use apenas um canal confirmado para compartilhar um relatório.

Metas de resposta, contatos de escalonamento e créditos de serviço não foram estabelecidos. Mantenha credenciais e conteúdo sensível do cliente fora do seu relatório.