Breadcrumb

Breadcrumb se instala como una dependencia de código, lo que significa que no hay cuenta externa ni salto de red para tus datos de traza. Creas una instancia, la apuntas a tu base de datos y corre dentro de tu proceso. Nada sale de tu infraestructura salvo que tú decidas lo contrario. Sin sorpresas. Para equipos con reglas estrictas de datos, eso suele ser el factor decisivo.

Los spans se normalizan en una sola tabla, breadcrumb_spans, que vive en la base de datos donde tu app ya escribe. No es una exportación, un webhook ni una API de solo lectura sobre el esquema de otro. Tus analíticas se vuelven consultas normales con el ORM que uses, así que puedes unir las trazas con usuarios, pedidos o cualquier otra cosa que guardes. Los usuarios de Prisma, por ejemplo, pueden traer la tabla y tratarla como cualquier otro modelo.

Las llamadas al modelo se instrumentan solas. Pasas bc.telemetry() donde el Vercel AI SDK espera experimental_telemetry, y Breadcrumb lee el modelo, el proveedor, los conteos de tokens, el costo y las cargas útiles desde atributos que el SDK ya emite. No hay construcción manual de spans alrededor de cada llamada. Eso mantiene pequeña la configuración y hace más fácil añadir trazado a un proyecto existente sin reescribirlo.

El trabajo alrededor de las llamadas al modelo no se instrumenta solo, así que lo envuelves en bc.trace(). La recuperación, las llamadas a herramientas y la escritura final en la base de datos quedan en la misma línea de tiempo que los spans del modelo. Cuando una solicitud se siente lenta, puedes ver si el retraso está en la recuperación, en una herramienta o en el modelo mismo, en lugar de adivinar.

Breadcrumb expone las trazas vía MCP, así que un agente puede consultarlas como lo haría un desarrollador. Puedes darle una clave a un agente de código y dejar que revuelva entre las trazas de producción, o leer tú mismo el panel. La opción hidePayloads mantiene los prompts en bruto fuera de lo que ve el agente, lo cual importa cuando las trazas contienen entradas sensibles del usuario.

El panel es un componente, no una pantalla SaaS fija. Una herramienta alojada tiene que ser genérica porque sirve a la app de todos; el tuyo solo tiene que servir a la tuya. Lo montas detrás de tu propia autenticación y puedes añadir paneles extra como páginas dentro de él. Esa flexibilidad es difícil de conseguir cuando la interfaz del panel vive en el dominio de otro y tiene que servir a la app de cada cliente.

La retención es una ventana que fijas por entorno y que se limpia a medida que llegan las trazas. Nada se mide por evento, así que nunca tienes que muestrear ni descartar cargas útiles solo para mantener baja una factura. Tú decides cuánto tiempo se quedan los datos, y conservas trazas completas mientras estén ahí.