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

Uma chamada de API de IA com 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.

O Console de Requisições do TokenLab existe para fechar essa lacuna. Ele coloca detalhes em nível de requisição — modelo, chave, estado do cache, estado de faturamento, tempo de resposta e uma prévia do payload redigido — em uma única visualização de painel, para que você possa ir de "esta chamada falhou" para "aqui está o porquê" sem precisar juntar logs de três lugares diferentes.

Este artigo percorre o que o console mostra, o que verificar primeiro quando algo quebra e como ele se encaixa junto com as exportações de uso para equipes que também precisam de relatórios em nível de custo.

Principais pontos

• O Console de Requisições é uma superfície 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 tem um ID que você pode pesquisar diretamente, e você pode criar um link direto para uma requisição específica com requestId na URL.
• O console mostra o roteamento, estado de faturamento, estado do cache, contexto do modelo/chave e prévias de payload redigidas 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 únicos, use o console. Para revisão de custos em lote em intervalos de tempo, use as exportações de uso.

O que é o Console de Requisições

Você o acessa em https://tokenlab.sh/en/dashboard/api?tab=requestConsole, dentro da seção de API do painel do TokenLab. Ele foi construído com base em uma premissa: quando uma requisição falha, a correção mais rápida vem de ter o contexto completo à sua frente, não de adivinhar com base 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. Na prática, isso 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 todos os detalhes: 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, para que você não precise cruzar referências com um log de erro separado.

Estado de rota e faturamento. Mostra como a requisição foi roteada e se ela foi faturada, pendente, reembolsada ou falhou — os quatro estados que mais importam quando um cliente pergunta "fui cobrado por esse erro?".

Prévia do payload. Os corpos de requisição e resposta são mostrados como prévias redigidas quando disponíveis, dando a você a forma e a estrutura sem expor segredos brutos no corpo.

Contexto do provedor do modelo e chave do modelo. Qual provedor e qual modelo específico lidaram com a chamada — útil quando você está executando 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 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	Faturado, pendente, reembolsado ou falhou — diz se é uma questão de custo ou técnica
Modelo	Qual modelo realmente atendeu a requisição (útil se você roteia entre vários modelos)
Estado do cache	Se um hit ou miss 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:

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

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

Se você ainda não tem 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. Um padrão comum: filtrar pelo status "falhou" na última hora e, em seguida, procurar na lista a chamada específica sobre a qual um usuário está perguntando.

Lendo o campo de status corretamente

Os quatro estados — faturado, pendente, reembolsado, falhou — respondem a perguntas diferentes:

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

Saber qual desses se aplica antes de escalar economiza uma rodada de 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, vale a pena confirmar 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 importa por dois motivos: custo e latência. Um miss de cache onde você esperava um hit geralmente significa que o prefixo do prompt mudou, mesmo que sutilmente — um timestamp, um campo reordenado, um caractere de espaço extra. O filtro de estado de cache do console permite comparar requisições de hit e miss lado a lado.

Como funciona com as exportações de uso

O Console de Requisições e as exportações de uso resolvem problemas diferentes, e vale a pena ser explícito sobre o limite para que você não recorra à ferramenta errada.

O console foi criado para investigação de requisições únicas: uma chamada, um erro, uma questão de faturamento, respondida 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 foram 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 um stakeholder financeiro ou usaria para uma reconciliação mensal. Se você está tentando responder "quanto gastamos no DeepSeek V4 Pro na semana passada", essa é uma pergunta para exportação, não para o 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 de depuração prática

A depuração ad hoc transforma-se em adivinhação 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. Faturado, pendente, reembolsado ou falhou — isso enquadra o restante da investigação.
4. Confirme o modelo que realmente atendeu a requisição. Compare-o com o que você esperava enviar.
5. Verifique o estado do cache. Um miss de cache onde você esperava um hit 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 de erro e as informações de rota. É aqui que a causa raiz real geralmente se torna visível.
8. Revise a prévia do payload redigido. 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 documenta as formas esperadas de requisição e resposta, úteis 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ê ignore o campo que realmente explica a falha.

Próximos passos

Se você está atualmente depurando falhas de API de IA fazendo grep em seus próprios logs do lado do cliente e cruzando referências com um painel de faturamento separado, o Console de Requisições remove uma etapa desse loop. Comece encontrando uma requisição falha recente e abrindo-a diretamente.

• Abra o console e localize uma requisição por ID: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Crie uma chave de API do TokenLab em tokenlab.sh/en/dashboard/api para começar a fazer requisições a partir de seu próprio console ou scripts.
• Verifique a forma da requisição/resposta de chat completions se você suspeitar de um payload malformado: https://docs.tokenlab.sh/api-reference/chat/create-completion
• Para revisão de gastos agregados, use exportações de uso em vez do console: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Se você estiver comparando modelos por custo ou capacidade antes de mudar, o diretório de modelos tem preços atuais e detalhes da janela de contexto: https://tokenlab.sh/en/models

FAQ

O que é o Console de Requisições do TokenLab? É uma visualização de depuração em nível de requisição dentro do painel da API do TokenLab. Ele mostra roteamento, estado de faturamento, estado do cache, contexto de modelo e chave, e prévias de payload redigidas para requisições recentes, limitadas à sua organização.

Posso inspecionar uma requisição pelo ID da requisição? Sim. Use o formato de link direto /dashboard/api?tab=requestConsole&requestId=<request_id> para abrir o inspetor diretamente em uma requisição específica, ou pesquise pelo ID da requisição na visualização em lista.

O console substitui as exportações de uso? Não. O console serve para investigar requisições individuais — uma falha, uma questão de faturamento. As exportações de uso servem para revisão de gastos agregados em um intervalo de tempo. Use ambos juntos quando uma exportação revelar um padrão no qual você precisa se aprofundar.

O que devo verificar primeiro quando uma requisição de API de IA falha? Comece com o ID da requisição para confirmar que você está olhando para a chamada certa, depois verifique o campo de status (faturado, pendente, reembolsado, falhou), o modelo que realmente a atendeu e o estado do cache. A partir daí, o contexto de erro e a prévia do payload geralmente tornam a causa raiz visível.

Fontes e Atualidade

• Console de Requisições do TokenLab — https://tokenlab.sh/en/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 — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — observado em 09/07/2026
• Diretório público de modelos do TokenLab — https://tokenlab.sh/en/models — observado em 09/07/2026

Os exemplos de modelos referenciados (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) refletem o SSOT atual do modelo em 07/07/2026. Para preços e disponibilidade atuais exatos, verifique o link do diretório de modelos acima antes de tomar decisões de roteamento.