Paritok: ¿reduce el coste de tu agente de código?

Qué hace Paritok con una solicitud

Paritok es una puerta de enlace de tokens: un proxy que se sitúa entre el agente de programación y la API del modelo y comprime cada solicitud antes de reenviarla. El agente se comunica con http://127.0.0.1:8080 en lugar de hacerlo directamente con el proveedor. El proxy reescribe los esquemas de herramientas, las lecturas de archivos, la salida de las herramientas y los turnos anteriores, envía la carga útil más pequeña al proveedor y devuelve la respuesta sin modificarla.

El proveedor le factura por lo que recibe, por lo que una carga útil más pequeña genera una factura menor. Esa es toda la idea. Es una afirmación distinta de «el contexto dura más» y es la razón por la que esta herramienta resulta interesante, en lugar de limitarse a ordenar el contenido.

El proyecto es reciente. Sus primeras etiquetas públicas están fechadas en julio de 2026 y la etiqueta actual es v1.3.0, fechada el 5 de agosto de 2026. Los pesos y el código de la puerta de enlace usan la licencia Apache 2.0. El modelo de compresión es un adaptador LoRA (adaptación de bajo rango) sobre Qwen3-4B-Instruct-2507, entrenado con 45,000 muestras destiladas de un modelo profesor y obtenidas de trayectorias reales de agentes de programación.

Por qué esto no es recorte de contexto

El recorte elimina contenido. Cuando un agente se acerca a su límite de contexto y descarta los turnos más antiguos, el archivo que leyó en el turno 3 desaparece. Si necesita ese archivo en el turno 20, vuelve a leerlo y paga esos tokens por segunda vez. El ahorro era un préstamo.

Paritok reemplaza un segmento por una forma más corta y una etiqueta, [REF:id], y conserva el texto completo en el proxy. El modelo recupera un segmento mediante read_original o expand_context. Esto cambia el modo de fallo. Un recortador falla al olvidar y nunca se lo comunica. Un compresor falla al entregar al modelo un resumen con pérdida, y el modelo puede solicitar el original cuando el resumen no es suficiente.

El filtro de herramientas se comporta de la misma forma. Los esquemas de herramientas filtrados se sustituyen por stubs en lugar de eliminarse, y el modelo recupera uno mediante gateway_search_tools. Esto es importante porque un filtro que oculta una herramienta de forma permanente cambia lo que el agente puede hacer, y usted lo descubriría mediante una tarea que falló sin indicarlo claramente.

Las tres palancas y cuál es gratuita

La primera palanca es el filtro de esquemas de herramientas. Cada solicitud incluye el array tools completo. En una interacción de Claude Code con varios servidores MCP (model context protocol) conectados, el proyecto calcula que ese bloque contiene aproximadamente 29,000 tokens. El filtro genera embeddings de la solicitud del usuario y de la descripción de cada herramienta con BAAI/bge-small-en-v1.5, un modelo de embeddings de 130 MB; conserva las herramientas relevantes y sustituye el resto por stubs. El bloque se reduce a aproximadamente 8,000 tokens. Ese modelo de embeddings se ejecuta en la CPU.

La segunda palanca es la compresión de contenido. Esta es la parte que necesita el modelo 4B en una GPU. Las lecturas de archivos, la salida de las herramientas y el historial se reescriben hasta ocupar el 25.7% de su tamaño original. De ahí procede la cifra principal del 74%. Léala con atención: el 74% es la tasa de compresión del contenido que se comprime, no la reducción de su factura.

La tercera palanca es el resumen del historial. Cuando se llena el presupuesto de contexto, se resumen las interacciones anteriores a la ventana reciente para que una sesión larga continúe en ejecución en lugar de alcanzar el límite.

Sólo la segunda palanca necesita una GPU. Esta es la frase más útil de esta página. pip install "paritok[toolselect]" le proporciona el filtro de herramientas en un VPS normal con CPU, y es la mitad del producto que no le cuesta nada al mes. Pruébelo antes de alquilar una tarjeta.

Qué midió el proyecto y en qué entorno

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

Estas son las cifras publicadas por el propio proyecto, medidas en su propio entorno de pruebas con SWE-bench Lite. Paritok-4B-v1 comprime el contenido hasta el 25.7% del tamaño original y conserva el 86.5% de la tasa de resolución sin comprimir. Usar gpt-5 como compresor conserva más calidad, el 93.6%, pero sólo comprime hasta el 61.9%; para ahorrar costes de frontier acabaría pagando precios de frontier.

Interprete la columna de calidad de forma realista. Conservar el 86.5% de la tasa de resolución significa que las ejecuciones comprimidas fallaron problemas que las ejecuciones sin comprimir resolvieron, aproximadamente uno de cada siete. En un benchmark, es una cifra de una tabla. En su repositorio, es una tarea que ejecuta dos veces.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

El ahorro de extremo a extremo aumenta a medida que avanza la sesión, porque el historial se acumula y el historial es lo que se comprime. El proyecto informa de aproximadamente un 25% en un solo turno, un 39% en el turno 5 y un 63% en el turno 20. También indica dónde se detiene el crecimiento: con un presupuesto de 200,000 tokens, el ahorro absoluto se estabiliza en unos 48,000 tokens por turno, aproximadamente entre los turnos 8 y 12, porque cuando el contexto se llena el historial deja de crecer. La cifra de «más del 85%» que se cita habitualmente describe sesiones con el contexto saturado. Es el mejor caso, por lo que no debe planificar basándose en él.

¿Una GPU de 24 GB se amortiza con Paritok?

Una tarjeta de 24 GB es la unidad de alquiler habitual para un modelo de este tamaño. A 7 de agosto de 2026, la tarifa mediana publicada bajo demanda para una RTX 4090 con 24 GB era de $0.44 por hora, y las ofertas más baratas rondaban los $0.20. Tomemos $0.44. Si permanece encendida todo el mes, son 730 horas, es decir, $321. Si se ejecuta sólo durante el horario laboral, 8 horas al día durante 22 días, son 176 horas, es decir, $77.

Ahora convierta la reducción de tokens en una reducción en dólares. La reducción se aplica a los tokens de entrada. Los tokens de salida pasan por el proxy sin modificaciones, por lo que no cambian en absoluto. Suponga que los tokens de entrada representan el 80% del total facturado, algo normal en un agente de programación, y compruebe esa suposición con su propia factura. El ahorro en dólares es, por tanto, la reducción de tokens multiplicada por 0.8.

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

Con la cifra del 85% en sesiones saturadas, conserva el 68% de la factura. Por tanto, una tarjeta que permanece encendida se amortiza cuando el gasto mensual en agentes supera aproximadamente los $472, o aproximadamente los $114 si detiene la instancia fuera del horario laboral. Con la cifra del 63% en el turno 20, esos valores pasan a ser $637 y $154. Con la cifra del 39% en el turno 5, que es lo habitual en sesiones cortas, necesita gastar aproximadamente $1,030 al mes antes de que merezca la pena alquilar la tarjeta.

Hay dos factores que mejoran estos resultados frente a lo que sugiere la tabla. El modelo no necesita 24 GB: la compilación q4 ocupa aproximadamente 2.5 GB y la compilación bf16 unos 8 GB. Por tanto, una tarjeta más pequeña, o un equipo GPU que ya utilice para otra tarea, reduce todos los valores del gráfico. Además, detener la instancia cuando nadie está programando es la medida más importante, porque reduce el alquiler aproximadamente en tres cuartas partes.

Hay un factor que empeora el resultado. La pasada de compresión requiere trabajo real. Cada token que comprime el modelo 4B debe leerlo y después escribirlo, lo que añade latencia a cada turno del agente. En una tarjeta que alquila por horas, ese coste aparece como tiempo de espera, no como una línea en la factura. Por eso es fácil pasarlo por alto hasta que lo percibe.

Si está comparando las horas de GPU alquiladas con los tokens de API en general, el punto de equilibrio entre una GPU VPS y los tokens de API aplica el mismo cálculo a la inferencia propiamente dicha.

Ejecutar el gateway de Paritok en un VPS

Se requiere Python 3.10 o posterior. Ubuntu 24.04 incluye Python 3.12, por lo que una imagen normal de VPS es suficiente para la parte que sólo usa CPU.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

Fije la versión. El repositorio etiquetó v1.2.8 el 29 July 2026 y v1.3.0 el 5 August 2026, y un proyecto que avanza a ese ritmo cambia los nombres de las claves de configuración entre versiones. Un pip install paritok sin versión, o un git clone de main, le entrega un gateway diferente la semana siguiente y no deja constancia de cuál produjo las cifras que midió.

El backend predeterminado es Ollama. Descargue el modelo y asígnele el nombre corto que busca el proxy.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

Escriba paritok.yaml junto a él. use_gpu_server: false es lo que mantiene la compresión en su propio hardware.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

paritok up es el atajo para todo lo anterior: descarga el modelo si falta e inicia el proxy en el puerto 8080. Compruebe el proxy antes de conectar un agente a él.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/health devuelve un objeto JSON pequeño que contiene "status":"ok" y una cadena de versión. /stats devuelve los totales de compresión y la estimación del propio proxy sobre lo que ahorró. Considere esa estimación como una evaluación que el proxy hace de su propio trabajo y confírmela en la página de uso de su proveedor.

Para obtener rendimiento en lugar de comodidad, vLLM sirve el adapter sobre el modelo base.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollama se configura más rápido. vLLM gestiona mucho mejor las solicitudes simultáneas, algo que empieza a ser importante en cuanto más de un agente comparte el servidor. La diferencia práctica entre Ollama y vLLM es lo que determina cuál debe usar.

Apunte el agente al proxy mediante las variables de entorno de la URL base.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI ignora OPENAI_BASE_URL, por lo que el proyecto escribe ~/.codex/config.toml cuando codex.enabled: true está definido en paritok.yaml. Exportar sólo la variable deja a Codex conectado directamente al proveedor. La señal de esto es un contador /stats que nunca cambia mientras trabaja.

Mantenga el listener en 127.0.0.1, nunca en 0.0.0.0. El proxy reenvía la clave de API de su proveedor al upstream, por lo que un proxy accesible desde Internet es un relay abierto para esa clave: quien encuentre el puerto puede gastar su dinero sin ver la clave. Acceda desde un portátil mediante un túnel SSH o una VPN en lugar de abrir el puerto.

Ejecútelo con systemd para que siga funcionando después de reiniciar. Ajuste las rutas según su instalación.

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

Habilítelo con sudo systemctl enable --now paritok y vuelva a ejecutar curl /health. Una unidad que se inicia y termina de inmediato suele indicar que la ruta del archivo de configuración es incorrecta. journalctl -u paritok -n 50 muestra el motivo.

La opción alojada y su coste

El proyecto también ofrece la compresión como servicio. Configure use_gpu_server: true con una clave de API y el modelo 4B se ejecutará en su hardware, con un precio de $0.30 por millón de tokens procesados. Según su propia documentación, el servicio es gratuito hasta finales de agosto de 2026. Esto elimina el coste del alquiler de la GPU y todo el trabajo operativo descrito anteriormente.

También significa que sus prompts y los archivos que lee su agente salen de su máquina y llegan a un tercero antes de llegar a su proveedor de modelos. El alojamiento propio existe precisamente para evitar ese salto. Decida cuál de estos dos objetivos quiere priorizar antes de establecer ese indicador, porque cambiarlo requiere una sola línea, pero sus consecuencias no.

Cómo medir sus propios resultados antes y después

Las cifras publicadas son las del proyecto, obtenidas con el arnés del proyecto en SWE-bench Lite. Su repositorio no es SWE-bench Lite. Mida sus propios resultados.

• Ejecute una semana normal sin ningún proxy en el recorrido. Registre los tokens de entrada, los tokens leídos desde la caché y los tokens de salida en líneas separadas desde la página de uso de su proveedor, no como un único total en dólares.
• Ejecute la semana siguiente con el proxy delante y realice el mismo tipo de trabajo.
• Compare las líneas de entrada y de lectura desde la caché. La salida debería mantenerse aproximadamente estable, porque nada la comprime. Si la salida cambió mucho, también cambió algo distinto del proxy.
• Cuente las tareas que tuvo que repetir. Esa es la parte de calidad de la evaluación, y ningún panel de control informa de ella.
• Añada las horas de GPU de la segunda semana antes de comparar los totales.

Separar la entrada de la salida es importante porque tienen precios muy distintos y un compresor sólo actúa sobre una de ellas. En agosto de 2026, Claude Sonnet 4.6 cuesta $3 por millón de tokens de entrada y $15 por millón de tokens de salida, y una lectura desde la caché de prompts cuesta el 10% de la tarifa de entrada: $0.30 por millón. La diferencia entre el coste de los tokens de entrada y de salida determina si un compresor del lado de entrada le aporta algún beneficio. Dónde se usan realmente los tokens de Claude Code indica qué parte de su contexto es lo bastante grande como para que valga la pena comprimirla.

La caché de prompts complica especialmente el cálculo del filtro de herramientas. El bloque de herramientas se encuentra al principio de la solicitud, por lo que, después del primer turno, normalmente se lee desde la caché al 10% del precio de entrada. Eliminar 21,000 tokens de un bloque almacenado en la caché ahorra 21,000 tokens a $0.30 por millón, aproximadamente $0.006 por turno, en lugar de los $0.063 que indicaría la tarifa sin caché. El proyecto mantiene fijo el bloque filtrado durante la sesión para que el prefijo almacenado en la caché no cambie. Un filtro que volviera a seleccionar las herramientas en cada turno invalidaría ese prefijo y costaría más de lo que ahorrase.

Qué sigue sin estar verificado

Todas las cifras de rendimiento anteriores proceden del propio proyecto. No existe una reproducción independiente de los resultados de SWE-bench Lite y, como las primeras etiquetas están fechadas en July 2026, el código tampoco tiene mucha trayectoria operativa. La tasa de compresión y la cifra de calidad conservada las mide la misma parte que se beneficia de que sean favorables. Eso no significa que sean incorrectas. Significa que no están confirmadas, y debe valorarlas de forma distinta a una cifra que haya obtenido usted mismo.

Conviene conocer un comportamiento documentado antes de atribuir el problema a su configuración. El modelo de embeddings que usa el filtro de la herramienta se carga con la primera solicitud, no durante el arranque. Por eso, el proyecto documenta un calentamiento de 10 a 15 segundos y, después, unos 15 ms por llamada. Envíe una solicitud desechable después de iniciar el proxy para que el primer turno real del agente no parezca bloqueado.

Puede comprobar cuatro cosas por su cuenta en una tarde: si el proxy inicia y permanece activo, si /stats cambia mientras trabaja, si la línea de tokens de entrada de su proveedor realmente disminuye y si el agente sigue completando el trabajo. Esas comprobaciones determinan si le sirve en su configuración mucho mejor que cualquier benchmark publicado.

En cuanto a su relación con las demás herramientas: una puerta de enlace LiteLLM autoalojada enruta y contabiliza las solicitudes sin modificar su contenido, por lo que ambas herramientas resuelven problemas distintos y pueden encadenarse, con Paritok situado más cerca del agente. Si el objetivo real es reducir la factura y no usar esta herramienta concreta, el conjunto más amplio de controles de costes para un agente en un VPS incluye varios cambios que no cuesta nada probar primero.

FAQ

¿Paritok reduce mi factura de API o sólo el uso de contexto?

Reduce la factura, porque el proxy reescribe la solicitud antes de que llegue al proveedor y este cobra por lo que recibe. La reducción real es menor que la cifra destacada. El 74% corresponde a la tasa de compresión del contenido comprimido. De extremo a extremo, el proyecto informa de aproximadamente un 25% en un solo turno y un 63% en el turno 20, y sólo cambian los tokens de entrada. Los tokens de salida pasan sin modificaciones.

¿Cuánta GPU necesito para alojar el modelo de compresión?

La compilación q4 ocupa aproximadamente 2.5 GB y la compilación bf16, unos 8 GB. Por tanto, el modelo cabe con mucho margen en una tarjeta de 24 GB. También funciona con una tarjeta más pequeña, lo que mejora el punto de equilibrio a tu favor. El filtro de esquemas de herramientas no necesita GPU: usa BAAI/bge-small-en-v1.5, un modelo de embeddings de 130 MB que se ejecuta en la CPU. Instala paritok[toolselect] en un VPS normal y tendrás la reducción de bloques de herramientas a cambio de una pequeña cantidad de RAM.

¿Qué ocurre si el compresor elimina algo que el agente necesitaba?

No se elimina nada. Los segmentos comprimidos llevan una etiqueta [REF:id] y el modelo recupera el texto completo con read_original o expand_context. Los esquemas de herramientas filtrados se sustituyen por stubs en lugar de eliminarse, y el modelo recupera uno con gateway_search_tools. El riesgo real es más sutil que la falta de un archivo: el modelo trabaja con un resumen con pérdida y nunca detecta que debería solicitar el original. Eso es lo que mide la cifra de calidad retenida del 86.5% en SWE-bench Lite.

¿Por qué mi primera solicitud tarda quince segundos?

El modelo de embeddings que utiliza el filtro de herramientas se carga con la primera solicitud, no durante el arranque. El proyecto documenta un calentamiento de 10 a 15 segundos y, después, aproximadamente 15 ms por llamada. Envía una solicitud de prueba con curl después de iniciar el proxy. Así, el primer turno real del agente no se bloqueará.

¿Debo usar el servidor GPU alojado en lugar de alojar el servicio por mi cuenta?

Elimina el coste del alquiler de la GPU y el mantenimiento. A fecha de agosto de 2026, cuesta $0.30 por millón de tokens procesados. También envía tus prompts y los archivos que lee tu agente a un tercero antes de que lleguen a tu proveedor de modelos. Si alojas el servicio por tu cuenta para mantener el código en una infraestructura que controlas, esa configuración contradice el motivo inicial. El alojamiento propio mantiene tanto el contexto como la clave de API del proveedor en tu propio servidor.