thrift-memory

Thrift Memory

El servidor de memoria MCP que demuestra cuántos tokens ahorraste. (npm: thrift-memory)

🌐 Página de thrift-memory →  ·  npm

No afiliado con Apache Thrift, el framework de RPC. Este proyecto siempre se denomina Thrift Memory — una capa de memoria MCP para agentes de codificación.

Thrift Memory es un servidor de memoria MCP centrado en el costo para agentes de codificación que dejan de recargar archivos grandes de MEMORY.md, AGENTS.md y contexto de proyecto en cada sesión. Recupera solo la memoria relevante a la tarea bajo un presupuesto de tokens estricto y devuelve un recibo de ahorro: baselineTokens vs injectedTokens vs savedTokens.

savedTokens = baselineTokens - injectedTokens

Si tu agente de codificación vuelve a cargar el mismo archivo de contexto grande al inicio de cada sesión, esa recarga es un costo de tokens puro y repetido. Thrift Memory lo limita y — de forma única — registra un recibo en cada recuperación para que puedas ver el uso de tokens que evitaste, no solo confiar en que lo evitaste.

Recuperación con presupuesto, en una línea: Thrift Memory recupera solo la memoria relevante a la tarea bajo un presupuesto de tokens estricto y registra un recibo que muestra baselineTokens vs injectedTokens vs savedTokens.

Estado: 0.0.x temprana. Las APIs son útiles pero aún pueden cambiar antes de v0.1.

Qué Hace

Thrift tiene tres superficies:

Superficie	Propósito
Servidor MCP	Herramientas de memoria para agentes: remember, recall, search_memory
Panel local	Interfaz de ahorro respaldada por el JSONL del medidor, más controles del propietario (fijar/deshabilitar, presupuestos, interruptor de apagado)
Proxy	Puerta de enlace HTTP opcional que recorta solicitudes LLM en vivo y reintenta límites de tasa

Sé preciso sobre la división:

• MCP gestiona la recuperación de memoria y los recibos de tokens.
• thrift-proxy gestiona el recorte de solicitudes en vivo y los reintentos por límites de tasa.

Cómo Se Compara

La comparación correcta para Thrift Memory no es con capas de calidad de recuperación / grafo de conocimiento como Mem0, Zep o Graphiti — esas optimizan lo inteligente que es la recuperación. Thrift Memory compite con el creciente conjunto de servidores de memoria MCP para agentes de codificación, y se diferencia de todos ellos en un eje: visibilidad de costos.

Cada recuperación devuelve un recibo de ahorro — baselineTokens, injectedTokens, savedTokens — para que puedas ver cuántos tokens evitaste. Ningún otro servidor en esta categoría se posiciona en torno a probar el ahorro.

Servidor	Qué optimiza	¿Presupuesto de tokens estricto en la recuperación?	¿Emite un recibo de ahorro (baseline vs injected vs saved)?
Thrift Memory	Recuperación centrada en el costo — limita los tokens y prueba el ahorro	Sí	Sí — en cada recuperación
Official Memory MCP	Memoria de grafo de conocimiento (entidades / relaciones)	No	No
Context Mode	Aislamiento de contexto — mantiene salidas grandes de herramientas/archivos fuera del contexto (SQLite FTS5)	No (aislamiento, no un presupuesto de recuperación)	No
Agent Memory MCP	Devuelve un índice pequeño vía memory_read, luego memory_search por tema	No	No
@provos/memory-mcp-server	Recuperación memory_context / task dentro de un presupuesto de tokens	Sí	No
memento-memory-mcp	Memoria para agentes de codificación — importa CLAUDE.md, SQLite, sincronización git, interfaz local	No	No
MCP Context Server	Almacenamiento con ámbito de hilo, búsqueda de texto completo / semántica / híbrida, reordenamiento	No	No
smart-claude-memory-mcp	Almacén de memoria orientado a Claude	No	No

El competidor más cercano, @provos/memory-mcp-server, también recupera bajo un presupuesto de tokens — pero no muestra lo que el presupuesto te ahorró. El diferenciador de Thrift Memory no es "hago memoria"; es "hago memoria con una contabilidad de costos". El recibo de savedTokens = baselineTokens - injectedTokens es lo que nadie más en esta categoría destaca.

Resumen honesto: si necesitas la recuperación más inteligente posible, usa una capa de grafo de conocimiento como Mem0 o Zep. Si tus agentes de codificación siguen pagando por recargar archivos grandes de MEMORY.md / AGENTS.md / contexto de proyecto al inicio de cada sesión y quieres medir y limitar ese costo sin infraestructura adicional, ese vacío es lo que Thrift Memory llena. Los dos no son mutuamente excluyentes — Thrift Memory puede ubicarse frente a un almacén más pesado como capa de presupuesto/medición.

Para la comparación completa — incluyendo cómo Thrift Memory se diferencia de Mem0, Zep y Graphiti en el eje costo-vs-calidad-de-recuperación — consulta docs/COMPARISON.md. Las preguntas comunes se responden en docs/FAQ.md. Para un recorrido narrativo de todo el campo de la memoria — capas de calidad de recuperación vs. los servidores de memoria MCP centrados en el costo — lee la publicación del blog sobre Mem0 vs Zep vs Graphiti.

Herramientas MCP

remember(scope, text, agentId?, sessionId?, tags?)
  Store a memory in org, agent, or session scope.

recall(agentId, tokenBudget, task?, tags?)
  Return relevant memories under a hard token budget.
  Also returns { injectedTokens, baselineTokens, savedTokens }.

search_memory(agentId, task?, tags?, limit?)
  Browse matching memories without applying a small recall budget.

Ve Tu Propio Desperdicio (10 segundos, sin instalar nada)

Antes de adoptar cualquier cosa, mide lo que tus agentes ya recargan en cada sesión:

npx -y thrift-memory audit

Escanea el repositorio actual en busca de archivos de memoria / instrucciones de agentes — CLAUDE.md, CLAUDE.local.md, MEMORY.md, AGENTS.md, GEMINI.md, .cursorrules, .cursor/rules/, .windsurfrules, .clinerules, .github/copilot-instructions.md, más tu ~/.claude/CLAUDE.md global de usuario — e imprime la factura:

Thrift Memory audit — D:\myrepo

  File                               Tokens
  CLAUDE.md                           3,000
  .cursor/rules/api.mdc                 900
  AGENTS.md                             800
  .github/copilot-instructions.md       300
  TOTAL reloaded per session          5,000

At 10 sessions/day (--sessions): ~50,000 tokens/day, ~1,500,000/month
≈ $22.50/month at $15/M input tokens (an assumption — adjust: --price-per-mtok)

With recall capped at 2,000 tokens/session (--budget): projected saving ~60%

Cada número se calcula a partir de tus archivos con el mismo estimador que usa el medidor — nada se envía a casa, nada se instala. Banderas: --path=, --sessions=, --budget=, --price-per-mtok=.

Inicio Rápido

Opción A — Plugin de Claude Code (un comando, memoria automática)

Si usas Claude Code, instala todo — servidor MCP, un agente consciente de la memoria y comandos /thrift-recall / /thrift-remember — en un solo paso:

/plugin marketplace add YohadH/thrift-memory
/plugin install thrift-memory@thrift

Eso registra el servidor MCP thrift automáticamente (vía npx thrift-memory), por lo que recall / remember / search_memory están disponibles sin editar configuración. Consulta plugins/thrift-memory/ para ver qué incluye el plugin.

Memoria automática (plugin v0.2.0): el plugin incluye un hook de SessionStart que ejecuta thrift-memory session-context e inyecta una porción de memoria con presupuesto (por defecto 1,500 tokens) directamente en el contexto en cada inicio, reanudación, /clear y post-compactación de sesión. Tus memorias duraderas sobreviven la pérdida de contexto sin llamadas a herramientas — y cada auto-inyección se mide (agente session-start), por lo que el panel muestra lo que el camino automático cuesta y ahorra también. Un almacén vacío no inyecta nada.

Opción B — Configuración MCP (cualquier cliente MCP)

npm install -g thrift-memory

Añade Thrift a un cliente compatible con MCP:

{
  "mcpServers": {
    "thrift": {
      "command": "npx",
      "args": ["thrift-memory"]
    }
  }
}

O ejecuta el servidor MCP directamente:

npx thrift-memory \
  --store-path=~/.thrift/memories.jsonl \
  --meter-path=~/.thrift/meter.jsonl \
  --default-budget=2000

Recuperación Respaldada por Archivos + Superposición JSONL

Por defecto, el servidor MCP también escanea el directorio de trabajo actual en busca de archivos de contexto de agentes existentes: MEMORY.md, AGENTS.md, CLAUDE.md, GEMINI.md, .cursorrules, .windsurfrules, .clinerules, .cursor/rules/*.md|*.mdc, .windsurf/rules/*.md|*.mdc, .github/copilot-instructions.md, y carpetas específicas de agentes que coincidan con memory/<agentId>/*.md.

Esos archivos se tratan como fuentes de recuperación de solo lectura. remember() aún escribe nuevas memorias duraderas en el almacén JSONL en --store-path, por lo que el modelo de ejecución es:

MEMORY.md / AGENTS.md / rules files / memory/<agentId>/*.md  +  ~/.thrift/memories.jsonl
                       read-only sources                     +       writable overlay

Los archivos bajo memory/<agentId>/*.md se cargan como memorias con ámbito de agente, por lo que memory/takshi/crm.md es visible para agentId: "takshi", mientras que memory/qa-manager/smoke.md es visible para agentId: "qa-manager". Las carpetas compartidas como memory/reports, memory/feed y memory/advice no se tratan como IDs de agentes.

Los cambios en archivos se detectan en la siguiente recuperación/búsqueda. Para escanear una raíz de proyecto diferente, pasa --file-root=/path/to/repo o establece THRIFT_FILE_ROOT. Para deshabilitar la recuperación respaldada por archivos y usar solo memorias JSONL, pasa --file-memory=false o establece THRIFT_FILE_MEMORY=0.

Demo de 60 Segundos

No se requiere agente — prueba el bucle de remember → recall → receipt con la biblioteca. Guarda como demo.mjs después de npm install thrift-memory, luego node demo.mjs:

import { JsonlStore, ScopedRetriever } from "thrift-memory";

const store = new JsonlStore({ path: "./demo.jsonl" });
const now = Date.now();

// 1. remember — store a few org memories (cheap, no LLM enrichment)
store.add({ scope: "org", text: "All money values are stored as integer cents, never floats." }, now);
store.add({ scope: "org", text: "We deploy only on green CI; no Friday-evening releases." }, now);
store.add({ scope: "org", text: "Postgres is the system of record; Redis is cache-only." }, now);

// 2. recall — load only what the task needs, under a hard token budget
const r = new ScopedRetriever().recall(store, {
  agentId: "dev",
  task: "how should I store money values?",
  tokenBudget: 40,
});

// 3. receipt
for (const m of r.memories) console.log("•", m.text);
console.log(`injected ${r.injectedTokens} / baseline ${r.baselineTokens} (saved ${r.savedTokens})`);

• All money values are stored as integer cents, never floats.
injected 15 / baseline 43 (saved 28)

Solo se inyecta la memoria relevante — las notas de cadencia de despliegue y Postgres se descartan porque no coinciden con la tarea, no solo por el presupuesto (recall aplica un umbral de relevancia). Esa brecha, baseline - injected, es exactamente lo que dejas de pagar en cada ejecución. La relevancia aquí es superposición léxica, así que formula la tarea con palabras que tus memorias realmente usen; un resultado vacío significa que nada en el alcance era relevante — que es la respuesta honesta, no ruido para llenar el presupuesto.

Panel

El panel opcional es local. Muestra si Thrift realmente está ahorrando tokens en ejecuciones reales de agentes, y (a partir de 0.0.3) expone una pequeña superficie de escritura para controles del propietario — fijar/deshabilitar una memoria, establecer presupuestos por agente, silenciar un agente y un interruptor de apagado para toda la flota — a través de endpoints locales POST/DELETE. Los mismos controles están disponibles desde la CLI de thrift-panel.

npx thrift-panel serve \
  --store-path=~/.thrift/memories.jsonl \
  --meter-path=~/.thrift/meter.jsonl \
  --control-path=~/.thrift/control.json \
  --port=8585

Abre http://127.0.0.1:8585.

El panel muestra:

Vista	Qué demuestra
Resumen de flota	Total de tokens baseline, inyectados, ahorrados y tasa de ahorro
Flujo diario de tokens	Si los ahorros persisten entre días reales
Ahorro por agente	Qué agentes son costosos y cuáles ahorran más
Recibos recientes	Los últimos eventos de recuperación/proxy medidos
Rutas de auditoría	Los archivos locales que respaldan los números

Equivalentes en CLI:

npx thrift-panel summary --store-path=~/.thrift/memories.jsonl --meter-path=~/.thrift/meter.jsonl
npx thrift-panel agents --store-path=~/.thrift/memories.jsonl --meter-path=~/.thrift/meter.jsonl
npx thrift-panel memories --store-path=~/.thrift/memories.jsonl --scope=org

Medición del Rendimiento

Cada recall escribe un recibo en THRIFT_METER_PATH cuando una ruta de medidor está configurada:

{"at":1760000000000,"agentId":"dev","injectedTokens":420,"baselineTokens":2100,"savedTokens":1680}

Definiciones:

Campo	Significado
baselineTokens	El contrafactual sin Thrift: toda la memoria en alcance que se habría cargado
injectedTokens	La porción que Thrift realmente devolvió bajo presupuesto
savedTokens	baselineTokens - injectedTokens
Tasa de ahorro	savedTokens / baselineTokens

Bucle de medición recomendado:

1. Siembra memorias desde tus propios archivos markdown o usa remember.
2. Deja que agentes reales llamen a recall durante el trabajo normal.
3. Revisa thrift-panel summary y thrift-panel agents.
4. Valida la calidad por separado comparando los resultados de las tareas con memoria completa vs. recuperación de Thrift.

Para un informe público creíble, publica tanto la reducción de tokens como la evidencia de calidad. Por ejemplo: "ahorró el 72% de los tokens de memoria en 200 recuperaciones reales, con 19/20 tareas emparejadas produciendo el mismo resultado."

Ahorrador de tokens seguro — señales de presión de presupuesto

Recortar tokens solo es seguro si el agente puede distinguir "obtuve todo lo relevante" de "obtuve una fracción". Por lo tanto, cada resultado de recall también informa cuánta memoria relevante el presupuesto lo obligó a dejar atrás:

{
  "injectedTokens": 492,
  "baselineTokens": 14000,
  "savedTokens": 13508,
  "relevantTokens": 2100,
  "skippedForBudget": 12,
  "skippedTokensForBudget": 1608,
  "hasMoreRelevantMemory": true,
  "budgetPressure": "high"
}

Campo	Significado
relevantTokens	Tokens de memoria que superaron el filtro de relevancia — lo que valía la pena inyectar antes de aplicar el presupuesto
skippedForBudget	Cantidad de memorias relevantes descartadas solo porque no cabían en el presupuesto
skippedTokensForBudget	relevantTokens - injectedTokens
hasMoreRelevantMemory	true cuando se omitió memoria relevante por presupuesto
budgetPressure	none (todo lo relevante cabía) · low · high (se omitió tanta memoria relevante como se inyectó)

Estos cuentan solo la memoria que pasó el filtro de relevancia, por lo que hasMoreRelevantMemory nunca se activa por ruido que la recuperación descartó correctamente. El bucle previsto es recuperación progresiva, realizada por el agente (no por el usuario final): comienza con un presupuesto pequeño, y si budgetPressure es high, haz una recuperación enfocada más antes de actuar — nunca excediendo un presupuesto total de tarea. Eso es lo que convierte a Thrift de un ahorrador de tokens en un ahorrador de tokens seguro: nunca actúas silenciosamente sobre una porción insuficiente. El agente memory-keeper y el comando /thrift-recall del plugin de Claude Code ya siguen este bucle.

Ten en cuenta la sobrecarga de MCP. Registrar cualquier servidor MCP añade la carga de su esquema de herramientas al contexto de cada agente (a menudo varios miles de tokens). La cifra honesta es neta: savings = recall reduction − MCP schema/tool-call overhead. En un agente con mucho contexto que recarga memoria amplia en cada ejecución, el recuerdo suele ganar por un amplio margen — pero confírmalo con el medidor en tu propia carga de trabajo antes de implementarlo en toda la flota, en lugar de asumirlo. Los recibos existen precisamente para que no tengas que adivinar.

Benchmark Sintético

Este repositorio incluye un pequeño fixture sintético para que los usuarios puedan verificar el pipeline de medición sin ningún dato privado:

npm run build
node benchmark/run.mjs

Lee:

• benchmark/fixtures/memories.jsonl
• benchmark/fixtures/meter.jsonl

Consulta docs/case-study.md para ver un ejemplo sanitizado de cómo interpretar los números.

Observación de Contexto

El hook UserPromptSubmit del plugin se ejecuta thrift-memory context-watch en cada prompt. Realiza un seguimiento del uso del contexto en relación con la ventana del modelo y, cuando el uso cruza un límite de paso, inyecta una instrucción que le dice al agente que guarde hechos duraderos mediante remember y sugiere ejecutar /compact — para que las decisiones sobrevivan a la compactación en lugar de descartarse silenciosamente.

El tamaño del paso se limita entre un mínimo y un máximo para que no se active ni con demasiada frecuencia en ventanas pequeñas ni con demasiada poca en ventanas enormes:

step = clamp(stepPct% × window, minStepTokens, maxStepPct% × window)

Indicador	Predeterminado	Significado
--step-pct=	20	Tamaño de paso objetivo, como porcentaje de la ventana
--min-step-tokens=	80000	Mínimo del tamaño de paso, en tokens
--max-step-pct=	50	Máximo del tamaño de paso, como porcentaje de la ventana
--window-tokens=	(automático)	Anula el tamaño de ventana del modelo detectado
--state-path=	~/.thrift/context-watch/	Dónde se persiste el estado de cruce de pasos

El bucle guardar → compactar → recargar: context-watch solicita un guardado antes de que se cruza un límite de paso, PreCompact imprime orientación de compactación como red de seguridad, y el hook preexistente SessionStart recarga una porción de memoria con presupuesto inmediatamente después — cerrando el bucle para que ningún hecho duradero se pierda por la compactación.

Guardados delta, no re-guardados: cada cruce ahora etiqueta su orientación con un marcador específico de sesión, session:<sessionId>, para que al agente no solo se le diga "guardar hechos" a ciegas cada vez. La instrucción inyectada hace que el agente llame a search_memory para esa etiqueta primero y vea lo que ya almacenó en esta sesión, luego guarde solo hechos genuinamente nuevos, etiquetándolos de la misma manera. Eso evita que cruces posteriores en la misma sesión recuerden el mismo hecho una y otra vez, y evita que el agente asuma erróneamente que algo ya se guardó.

Exclusión voluntaria eliminando las entradas UserPromptSubmit (y opcionalmente PreCompact) de plugins/thrift-memory/hooks/hooks.json.

Ahorros medidos: node benchmark/context-watch.mjs muestra ~72.5% menos tokens recargados en ventanas simuladas (37,744 de referencia vs. 10,367 inyectados, ahorrando 27,377 tokens) — consulta Benchmark Sintético arriba para la metodología.

Verificado

Pruebas unitarias. npm test — 157 pruebas en 12 archivos, incluida una test/contextWatch.test.ts dedicada que cubre la tabla de límites (tamaños de paso 1M→200k, 200k→80k, 128k→64k, 32k→16k), la máquina de estados de cruce de pasos (el primer cruce se activa, el mismo paso no se reactiva, el siguiente paso se activa de nuevo, aislamiento por sesión), el análisis de la cola del transcript (message.usage real, una lectura de cola limitada para transcripts grandes, respaldo a fileSize / 4), la inferencia modelo → ventana, el rechazo de traversal de rutas en ID de sesión y entradas malformadas/ausentes. Todo en verde.

Ejecución manual del contrato de hooks. El CLI compilado (node dist/mcp/bin.js context-watch) se ejecutó directamente con JSON de stdin con forma de hook contra un transcript sintético: se activa con el JSON exacto de hookSpecificOutput en un cruce, permanece en silencio en una repetición del mismo paso, se activa de nuevo en el siguiente paso y permanece en silencio (salida 0) con stdin basura, stdin vacío y una ruta de transcript ausente — confirmando que el contrato de "nunca romper el prompt" se mantiene en cada modo de fallo, no solo en el camino feliz.

Ejecución real de extremo a extremo, contra la sesión de desarrollo de esta propia función. En lugar de solo un fixture sintético, context-watch se reprodujo contra el transcript real y en vivo de Claude Code que se generó mientras se construía esta función — una sesión genuinamente larga (963 KB, 410 líneas, datos reales de uso de claude-sonnet-5 / claude-fable-5, sin anulación de ventana). Cuatro instantáneas reales se cortaron de ese transcript en puntos crecientes de la historia real de la sesión y se alimentaron al CLI en orden cronológico, cada una como una invocación de hook nueva:

Turno	Uso real (tokens)	% de ventana de 200k	Resultado
T1	31,686	~16%	silencioso (por debajo del primer paso)
T2	94,821	~47%	se activa — cruza el paso del 40%
T3	135,227	~68%	silencioso (mismo paso que T2, sin reactivación)
T4	182,661	~91%	se activa — cruza el paso del 80%

Esto coincide exactamente con el comportamiento documentado de "ventana de 200k → guarda a ~40% y ~80%", usando crecimiento real de tokens por turno en lugar de números elegidos a mano. El transcript completo de 963 KB (muy por encima del umbral de lectura de cola limitada de 64 KB) también se ejecutó de forma independiente y regresó en menos de un segundo (~0.3–0.6s de tiempo de pared, dominado por el arranque del proceso de Node, no por el análisis del transcript) — confirmando que la lectura de cola limitada mantiene el hook económico incluso contra una sesión grande, real y de larga duración.

Proxy y Límites de Tasa

El proxy es opcional. Úsalo cuando un agente pueda apuntar su base_url de LLM a un gateway HTTP local.

Seguridad — ejecútalo solo localmente. El proxy reenvía tu clave de API real del proveedor aguas arriba sin cambios. Se vincula a 127.0.0.1 por defecto (aplicado en código, no solo en la documentación), por lo que no es accesible fuera del host a menos que optes deliberadamente con --host=0.0.0.0 / THRIFT_PROXY_HOST. Nunca lo expongas en una interfaz pública ni compartas el puerto. Es una herramienta de desarrollo de un solo inquilino, no un gateway multiusuario endurecido. Las respuestas también se almacenan en búfer, por lo que el streaming SSE aún no se transmite.

npx thrift-proxy \
  --upstream=https://api.anthropic.com \
  --host=127.0.0.1 \
  --port=8787 \
  --budget=4000 \
  --meter-path=~/.thrift/meter.jsonl

Luego configura la URL base del LLM del agente como http://localhost:8787 y sigue usando la clave de API real del proveedor.

El proxy:

• recorta el contexto de solicitudes en vivo bajo un presupuesto de tokens estricto,
• escribe los mismos recibos de ahorro que la superficie de MCP,
• reintenta respuestas 429 y 503 Retry-After aguas arriba,
• limita las solicitudes concurrentes aguas arriba por proveedor.

Valores predeterminados de límite de tasa:

Configuración	Predeterminado	Variable de entorno
Concurrencia máxima	5	THRIFT_MAX_CONCURRENCY
Reintentos máximos	5	THRIFT_MAX_RETRIES
Base de retroceso	1000ms	THRIFT_BACKOFF_BASE_MS
Retroceso máximo	60000ms	THRIFT_MAX_BACKOFF_MS

thrift-proxy almacena respuestas en búfer en esta versión; la transmisión de streaming es una mejora futura.

Importar Memorias Existentes

El script de importación es genérico y solo local. Puede importar archivos markdown a un almacén JSONL:

node scripts/import-memories.mjs \
  --source=./memory \
  --scope=org \
  --store-path=~/.thrift/memories.jsonl \
  --dry-run

Para memorias con ámbito de agente, coloca archivos markdown en directorios de proyecto y usa --scope=agent:

memory/
  checkout-service/
    dev.md
    qa.md
  docs-site/
    writer.md

node scripts/import-memories.mjs --source=./memory --scope=agent

Uso de la Biblioteca

import { JsonlStore, ScopedRetriever, InMemoryMeter, ThriftMcpServer } from "thrift-memory";

const server = new ThriftMcpServer({
  store: new JsonlStore({ path: "./memories.jsonl" }),
  retriever: new ScopedRetriever(),
  meter: new InMemoryMeter(),
  defaultTokenBudget: 2000,
});

await server.runStdio();

Desarrollo

npm install
npm run typecheck
npm run build
npm test

Estructura

Ruta	Propósito
src/mcp/	Servidor MCP stdio y definiciones de herramientas
src/store/	Almacén de memoria JSONL
src/retrieval/	Recuerdo con presupuesto y ámbito limitado
src/meter/	Medidor de tokens y resúmenes
src/control/	CLI y panel local
src/proxy/	Proxy HTTP, recorte de contexto, reintentos de límite de tasa
benchmark/fixtures/	Datos de benchmark sintético público
docs/	Documentación pública, captura de pantalla, estudio de caso sanitizado
test/	Pruebas unitarias y de integración

Licencia

Apache-2.0