cloud / sistemas
Quando um agente de programação está trabalhando, movimento no terminal é o que não falta. Surgem comandos, arquivos mudam e mensagens chegam. Mas as perguntas que quero responder costumam ser bem mais simples: qual modelo esta sessão usa? Quanto do contexto já foi ocupado? Estou mesmo na sessão que imagino? E quanto isso está me custando?
A animação responde a outra pergunta
Minha história anterior sobre ETA tratava de organizar meu tempo: espero, mudo de assunto ou volto depois? A linha de status resolve outra parte do mesmo problema. Antes de decidir o próximo passo, quero entender a sessão que está na minha frente.
Uma animação mostra que algo acontece. Um histórico longo mostra o que aconteceu. Nenhum dos dois necessariamente entrega, de relance, os fatos que procuro.
O que a linha de status torna visível
A imagem do terminal ajuda a concretizar a ideia. Uma linha reúne a rota escolhida, o modelo usado de fato, o consumo de contexto e as estimativas de custo. Os identificadores de projeto e conta foram trocados por exemplos neutros.
O nome da rota e o modelo para o qual ela aponta são informações diferentes. Nesta imagem, a rota passa pelo OpenRouter e usa um modelo OpenAI. É uma configuração estendida, não a interface padrão do Claude Code.
O indicador mostra 186.551 de 1.000.000 de tokens, ou 19,0%. Isso facilita visualizar uma capacidade abstrata. Mas 19% de contexto ocupado não significa que a tarefa está 19% pronta, nem revela quantos minutos faltam.
Os campos de custo são explicitamente estimativas ou contadores específicos do provedor. Cada um precisa de uma definição; eu não confundiria o número da linha de status com uma fatura conferida. A previsão e o modo automático são sinais adicionais dessa configuração, não funções do renderizador mínimo apresentado aqui.
Controle de custo na mesma linha
Ver o custo é um dos motivos mais úteis para ter uma linha de status. O agente pode continuar produzindo atividade enquanto eu perco a conta de quantas tentativas, repetições ou sessões paralelas iniciei. Quero perceber isso antes de olhar a fatura.
A imagem mostra “est. $6.61” e “OR today $9.31”. São contadores com rótulos diferentes, não dois valores para somar automaticamente. Antes de confiar neles, preciso saber seu escopo, a fonte dos preços e a frequência de atualização. Estimativas ajudam a conduzir o trabalho; os registros do provedor continuam sendo a referência para verificar cobranças reais.
Minha rotina prática seria simples:
- Definir um ponto de revisão de gastos antes de começar. Decidir quando pausar e revisar novas execuções, em vez de esperar uma surpresa desagradável.
- Comparar o aumento de custo com os resultados úteis. Se o número sobe enquanto o mesmo teste continua falhando, vale reduzir o escopo ou investigar o bloqueio antes de pedir outra tentativa abrangente.
- Escolher o próximo passo com intenção. Um ajuste menor, um modelo adequado ou uma verificação manual podem bastar. Qualquer troca de modelo continua exigindo as mesmas verificações de qualidade.
Um contador visível não é um limite automático de orçamento e não interrompe requisições. Cobranças de API, assinaturas e saldos de cada provedor também precisam ficar separados. A ideia é tratar o gasto de forma consciente, junto com tempo e qualidade técnica.
Um percentual deve ajudar a decidir
Quando o uso de contexto sobe, penso na continuidade. Os próximos passos estão claros? As decisões importantes foram registradas em um lugar durável? Uma passagem de contexto curta ajudaria antes da próxima etapa?
Não existe um percentual universal a partir do qual a sessão fica ruim. Uma tarefa curta e bem definida exige algo diferente de uma investigação extensa. Eu usaria o número como referência e depois examinaria o trabalho em si.
O medidor de contexto também não informa se o agente precisa de permissão ou de uma decisão. Isso exige um sinal explícito de atenção, assunto separado desta série.
“Não sei” também é uma resposta útil
A indicação menos útil é a que transforma informação ausente em um número tranquilizador. Se um campo não está disponível, a linha deve dizer isso.
A captura mostra valores disponíveis. Se algum faltar, prefiro um simples “indisponível” a um zero verde. Assim sei o que não tenho, em vez de receber uma precisão que a interface não consegue sustentar.
Pequeno o bastante para entender e remover
O Claude Code permite configurar uma linha de status: um comando local lê o JSON da sessão e imprime a indicação. A documentação oficial descreve os campos de modelo e contexto. É um ponto de partida prático, sem precisar de outro dashboard.
Na versão mínima, eu começaria por modelo e contexto e só acrescentaria custo quando a origem e o escopo da estimativa estivessem claros. O renderizador deve usar os campos fornecidos: sem varrer repositórios, consultar a rede ou guardar conversas. São escolhas deste exemplo, não promessas sobre toda extensão de linha de status.
Antes de ativá-lo, eu testaria entradas conhecidas e verificaria se os valores ausentes continuam claramente ausentes. Para mim, o melhor começo são sinais compreensíveis, não a maior coleção possível de números.
A ideia é ter menos coisas na cabeça
Uma linha de status não faz o agente raciocinar melhor nem substitui a revisão das alterações. Ela oferece um lugar pequeno e consistente para informações que eu teria de lembrar ou procurar.
É essa a direção que me interessa nas ferramentas para agentes: menos interrupções para recuperar o contexto básico e mais atenção para decisões que realmente precisam de uma pessoa.
O que você colocaria em uma linha discreta abaixo da sua sessão de programação?
Referência
Documentação oficial da linha de status do Claude Code, consultada em 27 de outubro de 2026.