Context-Stitcher es una pasarela de inferencia que permite a varios agentes de inteligencia artificial compartir, a nivel de memoria de la GPU, la caché de clave-valor (KV Cache) que se genera durante la fase de prefill de un modelo de lenguaje. Su objetivo es resolver un problema muy concreto de los flujos multi-agente: cuando dos agentes procesan de forma consecutiva el mismo documento largo —por ejemplo, un auditor legal y un analista financiero que leen el mismo contrato de 200 páginas—, los motores de inferencia convencionales obligan a repetir el prefill, duplican activaciones en la GPU y disparan la latencia hasta el primer token (TTFT).
La herramienta, basada en PagedAttention (vLLM), divide los prompts en bloques físicos y les asigna huellas topológicas encadenadas tipo Merkle. Cuando un segundo agente comparte el mismo prefijo, el sistema reasigna las direcciones lógicas de su tabla de atención directamente a los bloques físicos del primer agente, sin copiar datos en memoria. Un módulo de Zero-Trust (puerta de seguridad) limita qué sesiones pueden leer qué bloques, mediante listas de control configurables.
Según las pruebas recogidas en el repositorio, frente a un prefill en frío con vLLM sobre un documento compartido de 200 páginas, la latencia TTFT pasa de 1200 ms a 48 ms (una aceleración de 25 veces) y el uso de bloques físicos en GPU baja de 53 a 30 bloques, un 43,4 % menos de VRAM.
Context-Stitcher se ejecuta como un servidor local en el puerto 8000 y ofrece una API compatible con OpenAI (/v1/chat/completions), un panel web para supervisar en tiempo real el estado de los bloques (libres, privados, compartidos o con alertas de seguridad) y un SDK de Python con los decoradores @stitch_agent y el objeto StitcherMesh. Las políticas de compartición entre agentes se gestionan, consultan y revocan mediante endpoints REST (/policies, /policy).
Está pensado para pipelines donde varios agentesColaboran sobre el mismo contexto largo —auditoría de documentos, due diligence, análisis de código, agentes conversacionales encadenados— y se quiera reducir el coste computacional sin renunciar a un control de acceso entre sesiones. Como limitaciones relevantes, el proyecto asume prefijos idénticos o muy solapados para que la reutilización merezca la pena, depende de un backend compatible con vLLM y requiere configurar manualmente las políticas que autorizan el acceso compartido.