TokenLab Request Console: Depure chamadas de API de IA a partir de um único painel

Uma chamada de API de IA que falha raramente se anuncia claramente. Você recebe um código de status, talvez uma string de erro e um canal de suporte onde alguém pergunta 'qual foi o ID da requisição?'. Se você não o tiver à mão, a investigação trava antes mesmo de começar. Criamos o TokenLab Request Console para fechar essa lacuna, colocando detalhes em nível de requisição em uma única visualização de painel. Ele mostra o modelo, a chave, o estado do cache, o estado do faturamento, o tempo de resposta e uma prévia do payload com dados sensíveis ocultos. Em nosso pipeline, tratamos o ID da requisição como a primeira chave de busca.

Principais pontos

• O TokenLab Request Console é uma interface de depuração em nível de requisição dentro do painel da API do TokenLab, não um relatório de faturamento.
• Cada requisição possui um ID que você pode pesquisar diretamente. Você pode usar um link direto para uma requisição específica com requestId na URL.
• O console mostra o roteamento, o estado do faturamento, o estado do cache, o contexto de modelo/chave e prévias de payload com dados sensíveis ocultos para requisições recentes.
• O acesso é limitado à sua organização e regido pelas permissões de membro do painel — os colegas de equipe veem o que sua função permite.
• Para depuração de incidentes individuais, use o console. Para revisão de custos em lote em intervalos de tempo, use as exportações de uso.

O que é o TokenLab Request Console

Você o acessa em /dashboard/api?tab=requestConsole, dentro da seção de API do painel do TokenLab. O painel da API em si fica em /dashboard/api. O console foi construído com uma premissa: quando uma requisição falha, a correção mais rápida vem de ter o contexto completo à sua frente, e não de suposições baseadas apenas em uma mensagem de erro.

A descrição do painel define o console como um inspetor para requisições recentes, cobrindo roteamento, faturamento, corpo da requisição/resposta e contexto do provedor do modelo. Vemos que ele se divide em algumas seções de trabalho.

Visualização em lista. Uma tabela filtrável de requisições recentes. É aqui que você começa quando ainda não tem um ID de requisição específico. Você está procurando pela chamada falha ou incomum.

Painel do inspetor. Assim que você seleciona uma requisição, o inspetor abre com os detalhes completos: qual modelo a atendeu, qual chave de API foi usada, se ela atingiu o cache e qual foi o status final.

Contexto de erro. Se a requisição falhou, o console exibe as informações de erro vinculadas a essa chamada específica. Você não precisa cruzar dados com um log de erros separado.

Estado de rota e faturamento. Mostra como a requisição foi roteada e se ela foi faturada, está pendente, foi reembolsada ou falhou. Esses quatro estados são os mais importantes quando um cliente pergunta 'fui cobrado por esse erro?'.

Prévia do payload. Os corpos da requisição e da resposta são exibidos como prévias com dados sensíveis ocultos quando disponíveis, fornecendo a forma e a estrutura sem expor segredos brutos no corpo.

Contexto do provedor do modelo e da chave do modelo. Qual provedor e qual modelo específico manipularam a chamada. Isso é útil quando você executa vários modelos por trás de uma única integração e precisa confirmar se o correto foi invocado.

Nada disso exige que você crie seu próprio pipeline de logs sobre a API. Ele já é exibido por organização, filtrado pelas permissões de membro do painel, para que os colegas de equipe com acesso apropriado vejam os mesmos dados de requisição que você.

O que inspecionar primeiro

Quando uma chamada de API falha, existe uma ordem natural para verificar as coisas. Pular direto para 'o modelo está fora do ar' antes de confirmar se a requisição sequer chegou ao endpoint correto é perda de tempo.

A triagem de cinco campos

Verificação	O que ela lhe diz
ID da requisição	Confirma que você está olhando exatamente para a chamada em questão, não para uma similar
Status	Faturada, pendente, reembolsada ou falha — diz se é uma questão de custo ou técnica
Modelo	Qual modelo realmente atendeu à requisição (útil se você roteia entre vários modelos)
Estado do cache	Se um acerto ou erro de cache de prompt alterou o custo ou a latência
Origem da chave	Qual chave de API foi usada, útil quando várias chaves ou ambientes compartilham uma integração

Comece com o ID da requisição. Se você o tiver a partir de um log do lado do cliente, um ticket de suporte ou um relatório de erro, use o padrão de link direto:

/dashboard/api?tab=requestConsole&requestId=%3Crequest_id>

Isso abre o inspetor diretamente na requisição em questão, ignorando a visualização em lista completamente. É o caminho mais rápido quando alguém lhe entrega um ID e pergunta 'o que aconteceu aqui'.

Se você ainda não tiver um ID de requisição, os filtros do console permitem restringir por modelo, intervalo de tempo, estado do cache de prompt, origem da chave e status. Por exemplo, quando uma requisição falha, filtre pelo status 'falha' na última hora e, em seguida, procure na lista pela chamada específica sobre a qual um usuário está perguntando.

Lendo o campo de status corretamente

Os quatro estados — faturada, pendente, reembolsada, falha — respondem a perguntas diferentes:

• Faturada significa que a chamada foi concluída e consumiu créditos. Se um usuário relata um erro, mas a requisição aparece como faturada, vale a pena sinalizar isso separadamente. Sugere que a falha ocorreu no lado do cliente após uma resposta bem-sucedida.
• Pendente significa que a requisição ainda está em processamento ou aguardando liquidação. Não trate isso como uma falha prematuramente.
• Reembolsada significa que o TokenLab reverteu a cobrança, geralmente vinculada a uma falha no lado do provedor ou do roteamento.
• Falha significa que a chamada não foi concluída com sucesso e não foi faturada.

Saber qual desses estados se aplica antes de escalar o problema evita idas e vindas com o suporte.

Confirmando o modelo e o estado do cache

Se você está executando requisições contra modelos como Claude Sonnet 5, DeepSeek V4 Pro ou Gemini 3.5 Flash através de uma integração compartilhada, confirme se o console mostra o modelo que você esperava. Um cliente mal configurado, uma variável de ambiente obsoleta ou uma substituição de roteamento pode enviar tráfego para o modelo errado sem um erro óbvio no lado do cliente.

O estado do cache é importante por dois motivos: custo e latência. Um erro de cache onde você esperava um acerto geralmente significa que o prefixo do prompt mudou, mesmo que sutilmente. Procure por um carimbo de data/hora, um campo reordenado ou um caractere de espaço em branco extra. O filtro de estado de cache do console permite comparar requisições de acerto e erro lado a lado.

Como o TokenLab Request Console funciona com as exportações de uso

O Request Console e as exportações de uso resolvem problemas diferentes, por isso é útil ser explícito sobre a fronteira. O console foi criado para investigação de requisições individuais: uma chamada, um erro, uma questão de faturamento, respondidos no painel do inspetor. É o que você abre quando uma requisição específica falha e você precisa saber o porquê, agora mesmo.

As exportações de uso são criadas para revisão agregada: gastos em um intervalo de tempo, detalhamentos por modelo ou chave e o tipo de relatório que você entregaria a uma parte interessada financeira ou usaria para uma reconciliação mensal. Se você quer responder 'quanto gastamos com o DeepSeek V4 Pro na semana passada', essa é uma pergunta de exportação, não de console. Veja o guia de exportações de uso do painel do TokenLab para esse fluxo de trabalho.

Em resumo: console para incidentes, exportações para totais. Algumas equipes usam ambos em sequência. Uma exportação revela uma anomalia nos gastos agregados, e o console é onde você investiga as requisições específicas que a causaram.

Uma rotina prática de depuração

A depuração ad hoc transforma-se em suposições sob pressão. Uma rotina repetível evita que os incidentes durem mais do que o necessário.

Checklist: quando uma requisição falha

1. Obtenha o ID da requisição. A partir de seus logs de cliente, resposta de erro ou relatório de usuário. Se você não registra IDs de requisição do seu lado hoje, comece agora. É a chave de busca mais rápida que você tem.
2. Abra o console com o link direto. Use o parâmetro de consulta requestId para pular direto para o inspetor.
3. Verifique o campo de status primeiro. Faturada, pendente, reembolsada ou falha. Isso enquadra o restante da investigação.
4. Confirme o modelo que realmente atendeu à requisição. Compare-o com o que você esperava enviar.
5. Verifique o estado do cache. Um erro de cache onde você esperava um acerto pode explicar latência ou custo inesperados.
6. Verifique a origem da chave. Confirme se a chave de API e o ambiente corretos estavam em uso, especialmente em configurações de staging vs. produção.
7. Leia o contexto do erro e as informações de rota. Geralmente é aqui que a causa raiz real se torna visível.
8. Revise a prévia do payload com dados sensíveis ocultos. Confirme se a forma da requisição corresponde ao que seu cliente enviou. Parâmetros malformados geralmente aparecem aqui antes de aparecerem em qualquer outro lugar.
9. Cruze com a referência da API, se necessário. A referência da API de chat completions do TokenLab em https://docs.tokenlab.sh/api-reference/chat/create-completion documenta as formas esperadas de requisição e resposta. Use-a para confirmar se um payload foi malformado no lado do cliente.
10. Se for um padrão, não um caso isolado, mude para as exportações de uso. Uma única requisição falha é um problema de console. Dez requisições falhas em uma hora é um padrão que vale a pena exportar e revisar de forma agregada.

Seguir esta ordem — ID, status, modelo, cache, chave, erro, payload — evita que você pule o campo que realmente explica a falha.

Perguntas frequentes

Como encontro uma requisição falha sem um ID de requisição?

Use os filtros da visualização em lista no TokenLab Request Console. Restrinja por modelo, intervalo de tempo, estado do cache de prompt, origem da chave e status. Por exemplo, filtre pelo status 'falha' na última hora e, em seguida, procure pela chamada sobre a qual um usuário está perguntando. Assim que encontrá-la, abra o inspetor e copie o ID da requisição para logs futuros.

Por que uma requisição apareceria como faturada quando o cliente relata um erro?

Faturada significa que a chamada foi concluída e consumiu créditos. Se um usuário relata um erro, mas a requisição aparece como faturada, a falha provavelmente ocorreu no lado do cliente após uma resposta bem-sucedida. Sinalize esse caso separadamente, pois ele aponta para um caminho de correção diferente de uma requisição falha ou reembolsada.

O que um erro de cache me diz no inspetor?

Um erro de cache significa que a requisição não atingiu o cache de prompt. Isso é importante para custo e latência. Um erro onde você esperava um acerto geralmente significa que o prefixo do prompt mudou, mesmo que sutilmente. Verifique se há um carimbo de data/hora, um campo reordenado ou um caractere de espaço em branco extra.

Posso compartilhar um link de requisição com um colega de equipe?

Sim, se as permissões de membro do painel dele permitirem. Os dados da requisição são limitados à sua organização. Use o formato de link direto /dashboard/api?tab=requestConsole&requestId=<request_id> para abrir o inspetor diretamente. Os colegas de equipe veem o que sua função permite.

Quando devo mudar do console para as exportações de uso?

Mude quando o problema for um padrão, não um caso isolado. Uma única requisição falha é um problema de console. Dez requisições falhas em uma hora é um padrão que vale a pena exportar e revisar de forma agregada. Use as exportações para gastos em um intervalo de tempo, detalhamentos por modelo ou chave e reconciliação mensal.

Fontes e atualização

• TokenLab Request Console — /dashboard/api?tab=requestConsole — observado em 09/07/2026
• Referência da API de Chat Completions do TokenLab — https://docs.tokenlab.sh/api-reference/chat/create-completion — observado em 09/07/2026
• Exportações de uso do painel do TokenLab — /blog/tokenlab-dashboard-usage-exports — observado em 09/07/2026
• Diretório público de modelos do TokenLab — /models — observado em 09/07/2026
• Painel de chaves de API do TokenLab — /dashboard/api — observado em 09/07/2026

Os exemplos de modelos referenciados (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) refletem a fonte única de verdade (SSOT) atual dos modelos em 19/09/2026. O snapshot da fonte para esta nota do console foi observado em 09/07/2026; a data original da SSOT dos modelos na fonte era 07/07/2026.

Próximos passos

Se você atualmente depura falhas de API de IA pesquisando logs do lado do cliente e cruzando dados com um painel de faturamento separado, o Request Console remove uma etapa desse ciclo. O console fica em /dashboard/api?tab=requestConsole. O painel de chaves de API está em tokenlab.sh/dashboard/api. A forma de requisição/resposta de chat completions está documentada em https://docs.tokenlab.sh/api-reference/chat/create-completion. Para revisão de gastos agregados, use as exportações de uso. Para detalhes de preços de modelos e janelas de contexto, veja o diretório de modelos. Abra o console e localize uma requisição falha recente pelo ID.