Um console único para codificação e apps de IA: o que mudou e como trabalhar com ele

O TokenLab Console deixou de ser apenas um painel para nós quando o modo de assistente de codificação e o modo de aplicativo de IA se fundiram em uma única superfície de trabalho. Em nosso pipeline, a solicitação, a resposta e o estado da conta em torno delas agora ficam juntos. Isso remove uma alternância de contexto de cada sessão e muda a forma como lemos uma resposta lenta.

Principais pontos

• O modo de assistente de codificação e o modo de aplicativo de IA agora residem no TokenLab Console; os dois pontos de entrada antigos foram mesclados nele.
• Links existentes ainda funcionam e conversas anteriores permanecem lá. Não há nada para migrar manualmente.
• As respostas são transmitidas (stream) conforme o modelo as gera, em vez de aparecerem apenas no final. A interface mostra o tempo do primeiro token.
• A latência do primeiro token é um sinal de solicitação registrado (ttft_ms no log de solicitações), não apenas uma decoração da interface.
• Quando o saldo fica baixo no meio de uma conversa, a opção de recarga fica ao lado da conversa, em vez de em uma página de faturamento separada.
• A escolha de modelos do Console segue o catálogo público; verifique o diretório de modelos para as opções atuais. Exemplos do catálogo atual incluem Claude Sonnet 5 e DeepSeek V4 Pro.

O que mudou no TokenLab Console e o que não mudou

A mudança foi lançada como duas entradas no changelog. A convergência do Console (2026-08-04) moveu os dois pontos de entrada antigos para um único Console. O streaming de chat do Console (2026-08-18) adicionou streaming ao chat. As duas mudanças ocorreram com um mês de intervalo, então as equipes que perderam a primeira entrada ainda recebem a segunda gratuitamente.

Esta é uma mudança de superfície, não de comportamento. Chamadas de modelo, chaves e faturamento permanecem inalterados. Links antigos continuam funcionando e as conversas existentes foram preservadas durante a fusão. Não há etapa de migração manual.

A etapa de convergência trata dos pontos de entrada, não do acesso aos modelos. A etapa de streaming trata de como uma resposta aparece, não de quais tokens são cobrados. Isso é importante porque uma mudança na superfície do produto pode esconder uma mudança comportamental, e esta não o fez. O modo de assistente de codificação e o modo de aplicativo de IA agora compartilham o mesmo lugar, portanto, a primeira decisão em uma sessão não é mais sobre qual ponto de entrada abrir.

Se sua equipe possui runbooks que apontam para os pontos de entrada antigos, atualize os rótulos quando puder. Os links antigos ainda funcionam, então o runbook não será interrompido. O Console é o lugar para marcar como favorito para novos trabalhos. Quando você escolhe um modelo em qualquer um dos modos, a escolha segue o catálogo público, então verifique o diretório de modelos. Exemplos do catálogo atual incluem Claude Sonnet 5 e DeepSeek V4 Pro.

O streaming no TokenLab Console muda a forma como você lê uma sessão

O streaming muda o momento em que você sabe que algo está acontecendo. Em nosso pipeline, o cliente de gateway do Console cria solicitações de chat via streaming, e a resposta é renderizada incrementalmente. A interface mostra o tempo do primeiro token, para que você possa ver quando o modelo começa a responder. O Console também registra esse sinal como ttft_ms, uma coluna opcional no log de solicitações.

O tempo do primeiro token informa quando o primeiro token chegou, enquanto a latência total informa quando a resposta inteira terminou. Essas são perguntas diferentes, então, quando uma resposta parece lenta, verifique o ttft_ms primeiro. Se o primeiro token estiver atrasado, a espera ocorre antes da geração. Se o primeiro token for rápido e a resposta demorar, a espera ocorre no restante do stream.

Quando observamos uma sessão lenta, comparamos o ttft_ms com o restante das evidências da solicitação em vez de adivinhar pelo ícone de carregamento. As evidências no nível da solicitação são limitadas à organização e cobrem roteamento, estado de faturamento, estado de cache e o contexto do modelo e da chave por trás de uma solicitação. O Console expõe o mesmo registro de solicitação que você encontraria nos logs.

Um exemplo prático de leitura do sinal do primeiro token:

# O log de solicitações do Console expõe `ttft_ms` como uma coluna opcional.
# 1. Filtre o log de solicitações para a solicitação que você está verificando.
# 2. Leia o `ttft_ms`.
# 3. Compare o `ttft_ms` com a latência total da solicitação na mesma linha.

Para o formato exato da solicitação de streaming, use a documentação da API do TokenLab atual. Um exemplo de solicitação copiado com campos inventados seria menos útil do que a página de documentação que detém esses nomes.

O streaming não altera o que é cobrado, porque os mesmos tokens são produzidos, mas ficam visíveis à medida que chegam. Como as respostas agora são transmitidas, uma sessão interrompida ainda mostra a resposta parcial em vez de nada. Isso muda a forma como você diagnostica uma falha no meio da sessão. Para trabalhos de longa duração que um stream de chat não cobre, consulte o guia de tarefas de geração de imagem assíncronas.

Como verificar uma sessão lenta sem adivinhar

Comece pelo log de solicitações, não pelo ícone de carregamento, porque a coluna ttft_ms informa quando o primeiro token chegou. Se esse número for alto, o modelo ainda não começou a responder. Se esse número for baixo, o modelo começou cedo e o stream restante consumiu o tempo. Essa separação evita que você culpe a parte errada do caminho.

O registro da solicitação é limitado à sua organização. Ele inclui a rota que atendeu à solicitação, o estado de faturamento, o estado de cache e o contexto do modelo e da chave. Esses campos ficam juntos, para que você possa ler a sessão como um único evento em vez de juntar páginas separadas. O mesmo registro de solicitação está disponível no painel, o que ajuda ao comparar a visualização do Console com os dados do nível da conta. O guia do Request Console explica onde essas evidências residem.

Por exemplo, se o primeiro token for rápido e a resposta demorar, o ttft_ms não é o sinal principal, porque o restante do stream é. Você pode observar a rota e o estado do cache no mesmo registro de solicitação. Você pode verificar se a solicitação atingiu um cache ou foi para o modelo. Você pode ver qual chave e contexto de modelo foram anexados.

Nada disso conta a história toda por si só, mas juntos eles dão a você um lugar para procurar. Quando observamos uma sessão lenta, o log de solicitações tem os detalhes de que precisamos. Comparamos o ttft_ms com as outras evidências no nível da solicitação antes de tirar uma conclusão.

O mesmo fluxo de trabalho ajuda quando uma solicitação falha ou pausa devido ao saldo. O registro da solicitação inclui o estado de faturamento, portanto, a falha não é um mistério. A entrada de recarga fica ao lado da conversa, para que a correção permaneça na mesma janela. Você não precisa sair da sessão para encontrar a próxima etapa, então pode recarregar e continuar.

Se o saldo estiver bom, você pode passar para o roteamento, estado do cache ou escolha do modelo. O objetivo é ler as evidências no nível da solicitação em ordem. Primeiro, pergunte quando o primeiro token chegou, depois pergunte qual rota o atendeu e, em seguida, pergunte o que mais o registro diz sobre faturamento, cache, modelo e contexto da chave. Essa ordem é simples e corresponde à forma como o Console apresenta os dados.

Limitações

O streaming mostra o progresso, não o throughput, porque um stream pode começar rapidamente e ainda levar muito tempo para terminar. Um primeiro token rápido não prova que toda a solicitação é rápida. O tempo do primeiro token também depende do modelo e da rota. Compare dentro de um modelo em vez de entre modelos.

Uma mudança no ttft_ms pode refletir roteamento, estado de cache ou escolha de modelo, não apenas o prompt. Trate o ttft_ms como um sinal no log de solicitações. Combine-o com as outras evidências no nível da solicitação antes de tirar uma conclusão. Esta é uma superfície para ler uma sessão, não um benchmark para classificar modelos.

O Console não transforma um stream de chat em um executor de tarefas. Se você tiver uma tarefa de imagem de longa duração, use o guia de tarefas de geração de imagem assíncronas em vez de manter um stream de chat aberto. A superfície de streaming é para respostas que chegam token por token. O guia assíncrono é para trabalhos que são executados fora de uma resposta de chat.

Lembre-se também de que as evidências no nível da solicitação são limitadas à organização, o que vincula uma solicitação ao contexto da conta ao redor dela. Isso também significa que você não deve tratar uma solicitação como um benchmark global. O registro cobre roteamento, estado de faturamento, estado de cache e contexto de modelo e chave para aquela solicitação. É um ótimo lugar para iniciar um diagnóstico. Não é um ranking de provedores ou modelos. Quando comparamos sessões, comparamos dentro do mesmo modelo e da mesma família de rotas, o que mantém a comparação honesta.

Perguntas frequentes

Meus links antigos do Console ainda funcionam?

Sim. Links antigos continuam funcionando e as conversas existentes foram preservadas durante a fusão. Não há nada para migrar manualmente. Se você marcou uma página do Console, ela ainda funciona.

O que o tempo do primeiro token realmente mede?

Ele mede quando o primeiro token chega em uma resposta de streaming, e o Console o exibe na interface e o registra como ttft_ms, uma coluna opcional no log de solicitações. Ele não mede a latência total ou o throughput.

Onde faço a recarga quando uma conversa fica sem saldo?

Use a entrada de recarga ao lado da conversa, que aparece quando o saldo fica baixo no meio da conversa, para que você possa lidar com o saldo sem sair da sessão. A página de faturamento no painel continua sendo o local para trabalhos mais amplos da conta.

Posso comparar o tempo do primeiro token entre diferentes modelos?

Não, não como uma comparação limpa. O tempo do primeiro token depende do modelo e da rota, portanto, compare dentro de um modelo em vez de entre modelos. Use o ttft_ms como um sinal de nível de solicitação, não como um ranking de modelos.

Crie uma chave de API e execute uma sessão no novo Console no painel.