Paritok: ¿reduce el coste de los agentes 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 cambios.

El proveedor le factura 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 que «el contexto dura más», y por eso 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 July 2026 y la etiqueta actual es v1.3.0, fechada el 5 de August 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 (low-rank adaptation) sobre Qwen3-4B-Instruct-2507, entrenado con 45,000 muestras destiladas de un modelo profesor y extraídas de trayectorias reales de agentes de programación.

Por qué esto no es recorte del 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 se cobran 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 una llamada a read_original o expand_context. Esto cambia el modo de fallo. Un recortador falla al olvidar contenido 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 funciona del mismo modo. Los esquemas de herramientas filtrados se sustituyen por marcadores en lugar de eliminarse, y el modelo recupera uno mediante una llamada a gateway_search_tools. Esto importa porque un filtro que oculta permanentemente una herramienta cambia lo que el agente puede hacer, y usted lo descubriría a través de una tarea que falló sin hacerlo evidente.

Las tres palancas y cuál es gratuita

La primera palanca es el filtro del esquema de herramientas. Cada solicitud incluye el array completo tools. En un turno de Claude Code con varios servidores MCP (model context protocol) conectados, el proyecto calcula que ese bloque ocupa 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 del 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 quedar en el 25.7% de su tamaño original. De ahí procede la cifra 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, los turnos anteriores a la ventana reciente se resumen para que una sesión larga siga ejecutándose 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 con qué banco de pruebas

[
  {
    "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 con su propio banco de pruebas sobre 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, 93.6%, pero sólo comprime hasta 61.9%; pagarías precios de frontera para ahorrar precios de frontera.

Lee la columna de calidad con honestidad. Conservar el 86.5% de la tasa de resolución significa que las ejecuciones comprimidas fallaron problemas que las ejecuciones sin comprimir resolvieron: casi uno de cada siete. En un benchmark, es un número en una tabla. En tu repositorio, es una tarea que ejecutas 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 25% en un solo turno, 39% en el turno 5 y 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, una vez que 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, así que no planifiques basándote en ella.

¿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 fecha del 7 de agosto de 2026, la tarifa bajo demanda mediana publicada para una RTX 4090 de 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 monetaria. 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 habitual en un agente de programación, y compruebe esa suposición con su propia factura. El ahorro monetario 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% para sesiones saturadas, conserva el 68% de la factura. Por tanto, una tarjeta que permanece encendida se amortiza cuando el gasto mensual en el agente supera aproximadamente los $472, o aproximadamente los $114 si detiene la instancia fuera del horario laboral. Con la cifra del 63% para el turno 20, esos valores pasan a ser $637 y $154. Con la cifra del 39% para el turno 5, que es lo habitual en sesiones cortas, necesita aproximadamente $1,030 al mes para que merezca la pena alquilar la tarjeta.

Hay dos factores que mejoran el resultado respecto a lo que indica la tabla. El modelo no necesita 24 GB: la compilación q4 ocupa aproximadamente 2.5 GB y la compilación bf16, aproximadamente 8 GB. Por tanto, una tarjeta más pequeña, o un equipo GPU que ya ejecute para otra tarea, reduce todas las cifras del gráfico. Además, detener la instancia cuando nadie está programando es la medida más eficaz, porque reduce el alquiler aproximadamente en tres cuartas partes.

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

Si está comparando en general las horas de GPU alquiladas con los tokens de API, 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 básica de VPS es suficiente para la parte que usa sólo 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 proporciona un gateway diferente la semana siguiente y no deja constancia de cuál generó las cifras medidas.

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

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

Como el modelo local genera una reescritura por cada segmento que comprime, una pasada de compresión que tarda demasiado se manifiesta como un turno del agente bloqueado, y el límite num_predict de Ollama para la longitud de salida es el parámetro que lo acota.

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 dirigir un agente hacia é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 adaptador 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, lo que empieza a ser importante en cuanto más de un agente comparte el servidor. La diferencia práctica entre Ollama y vLLM es la que determina esta elección.

Dirija 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 comunicándose directamente con el proveedor, y una señal de ello 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 servidor ascendente, por lo que un proxy accesible desde Internet se convierte en 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 sobreviva a un reinicio. Ajuste las rutas para que coincidan con 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 sale inmediatamente suele indicar que la ruta del archivo de configuración es incorrecta, y 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 al proveedor de modelos. El alojamiento propio existe precisamente para evitar ese salto. Decida cuál de estos dos objetivos quiere priorizar antes de activar ese indicador, porque el cambio 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 la ruta. Registre los tokens de entrada, los tokens leídos de 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 de caché. La salida debería mantenerse aproximadamente estable, porque nada la comprime. Si la salida cambió mucho, también cambió otra cosa aparte del proxy.
• Cuente las tareas que tuvo que repetir. Esa es la parte de calidad del intercambio, y ningún panel informa de ella.
• Añada las horas de GPU de la semana dos 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 de 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 aplicado a la entrada le resulta útil. Dónde se utilizan realmente los tokens de Claude Code indica qué parte de su contexto es lo bastante grande como para justificar la compresión.

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 sirve desde la caché con el 10% del precio de entrada. Eliminar 21,000 tokens de un bloque almacenado en caché ahorra 21,000 tokens a $0.30 por millón, unos $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 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.

Lo que sigue sin verificar

Todas las cifras de rendimiento anteriores proceden del propio proyecto. No existe una reproducción independiente de los resultados de SWE-bench Lite y, dado que las primeras etiquetas están fechadas en julio de 2026, el código tampoco tiene un historial operativo amplio. La tasa de compresión y la cifra de calidad conservada las mide la misma parte que se beneficia de que parezcan favorables. Eso no significa que sean incorrectas. Significa que no están confirmadas y que debe valorarlas de forma distinta de 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 utiliza el filtro de la herramienta se carga con la primera petición, 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 petición descartable después de iniciar el proxy. Así, el primer turno real del agente no parecerá quedar bloqueado.

Hay cuatro aspectos que puede comprobar usted mismo en una tarde: si el proxy se 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 terminando el trabajo. Esos aspectos determinan mucho mejor el resultado en su entorno que cualquier benchmark publicado.

En cuanto a su relación con el resto de sus herramientas: un gateway de LiteLLM autohospedado enruta y contabiliza las peticiones 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 utilizar específicamente esta herramienta, 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 el proveedor cobra por lo que recibe. El tamaño de esa reducción es menor de lo que sugiere 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 lo que el modelo cabe en una tarjeta de 24 GB con mucho margen. 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 obtendrás la reducción de bloques de herramientas a cambio de consumir un poco de RAM.

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

No se elimina nada. Los segmentos comprimidos incluyen 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 un archivo ausente: el modelo trabaja a partir de un resumen con pérdida y nunca se da cuenta de que debería solicitar el original. Eso es lo que mide la cifra del 86.5% de calidad conservada en SWE-bench Lite.

¿Por qué tarda quince segundos mi primera solicitud?

El modelo de embeddings que usa el filtro de herramientas se carga con la primera solicitud, no al iniciar el servicio. El proyecto documenta un calentamiento de 10 a 15 segundos y, después, aproximadamente 15 ms por llamada. Envía una solicitud desechable con curl después de iniciar el proxy para que el primer turno real del agente no se bloquee.

¿Debería usar el servidor GPU alojado en lugar de alojarlo yo?

Elimina el coste del alquiler de la GPU y el mantenimiento. A agosto de 2026, tiene un precio de $0.30 por cada 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 tú mismo para mantener el código en una infraestructura que controlas, esa opción contradice el motivo por el que empezaste. El alojamiento propio mantiene tanto el contexto como la clave de API del proveedor en tu propio equipo.