Breadcrumb

O Breadcrumb se instala como uma dependência de código, o que significa que não há conta externa nem salto de rede para os seus dados de rastreamento. Você cria uma instância, aponta para o seu banco de dados e ela roda dentro do seu processo. Nada sai da sua infraestrutura, a menos que você decida o contrário. Sem surpresas. Para equipes com regras rígidas de dados, esse costuma ser o fator decisivo.

Os spans são normalizados em uma única tabela, breadcrumb_spans, que vive no banco de dados onde o seu app já grava. Não é uma exportação, um webhook nem uma API somente leitura sobre o esquema de outra pessoa. Suas análises viram consultas comuns com o ORM que você usar, então você pode juntar as trilhas com usuários, pedidos ou qualquer outra coisa que guarde. Usuários do Prisma, por exemplo, puxam a tabela e a tratam como qualquer outro modelo.

As chamadas ao modelo se instrumentam sozinhas. Você passa bc.telemetry() onde o Vercel AI SDK espera experimental_telemetry, e o Breadcrumb lê o modelo, o provedor, as contagens de tokens, o custo e as cargas úteis a partir de atributos que o SDK já emite. Não há construção manual de spans em torno de cada chamada. Isso mantém a configuração pequena e facilita adicionar rastreamento a um projeto existente sem reescrevê-lo.

O trabalho em torno das chamadas ao modelo não se instrumenta sozinho, então você o envolve em bc.trace(). A recuperação, as chamadas de ferramentas e a gravação final no banco caem na mesma linha do tempo que os spans do modelo. Quando uma requisição parece lenta, você vê se o atraso está na recuperação, em uma ferramenta ou no próprio modelo, em vez de adivinhar.

O Breadcrumb expõe as trilhas via MCP, então um agente pode consultá-las como um desenvolvedor faria. Você pode entregar uma chave a um agente de código e deixá-lo vasculhar as trilhas de produção, ou ler o painel por conta própria. A opção hidePayloads mantém os prompts brutos fora do que o agente vê, o que importa quando as trilhas contêm entradas sensíveis do usuário.

O painel é um componente, não uma tela SaaS fixa. Uma ferramenta hospedada tem que ser genérica porque serve o app de todo mundo; o seu só precisa servir o seu. Você o monta atrás da sua própria autenticação e pode acrescentar painéis extras como páginas dentro dele. Essa flexibilidade é difícil de conseguir quando a interface do painel mora no domínio de outra pessoa e precisa servir o app de cada cliente.

A retenção é uma janela que você define por ambiente e que é varrida conforme as trilhas chegam. Nada é medido por evento, então você nunca precisa amostrar nem descartar cargas úteis só para manter uma fatura baixa. Você decide por quanto tempo os dados ficam, e mantém as trilhas completas enquanto elas estiverem lá.