← Todas las noticias
ARTÍCULO
22 de septiembre de 2026 Actualizado el 28 de octubre de 2026 3 min de lectura

SoL-Pi: menos tokens en agentes de programación, ahorro medible

SoL-Pi reduce el tráfico de tokens en la prueba de sus autores. Qué medir en costes, calidad y tratamiento de datos antes de usarlo con código empresarial.

En este artículo
  1. Cuatro mecanismos, un armazón
  2. Qué mostró la evaluación
  3. Qué significa para los equipos de ingeniería
  4. Por qué te interesa: medir el trabajo terminado

SoL-Pi modifica el funcionamiento de los agentes de programación: en la evaluación de sus autores reduce el tráfico de tokens con un rendimiento comparable al sistema de referencia. Este análisis, actualizado el 28 de octubre de 2026, parte del artículo publicado el 17 de septiembre y distingue sus resultados de las comprobaciones necesarias antes de utilizarlo con código empresarial.

Manos escribiendo en el teclado de un portátil con líneas de código en pantalla y una taza oscura al fondo
Foto: Free-Photos from Pixabay (CC0), Wikimedia Commons. Recorte a 16:9.

Cuatro mecanismos, un armazón

SoL-Pi integra cuatro técnicas que, según los investigadores, superaron las pruebas en un conjunto creciente de entornos de desarrollo: Action Fusion, ObservationPack, un reductor que preserva evidencias y Online Context Compact. En conjunto, se centran en cómo el agente ejecuta acciones, compacta el contexto, gestiona la salida de las herramientas y decide qué necesita volver a leer, en lugar de modificar el modelo de lenguaje subyacente que realiza el razonamiento.

Qué mostró la evaluación

En EdgeBench, una evaluación de 51 tareas, los autores informan de que SoL-Pi iguala el rendimiento de su armazón de referencia, Pi, con dos modelos de respaldo diferentes, al tiempo que reduce el tráfico de tokens registrado entre un 44,7% y un 49,0% y el coste de API en aproximadamente un tercio. Son las cifras que el propio artículo comunica sobre su propia evaluación: una señal útil de lo que es posible, no una garantía de los mismos ahorros en una base de código o cadena de herramientas distinta.

Qué significa para los equipos de ingeniería

El código está disponible en github.com/NVlabs/SoL-Pi, de modo que los equipos que ejecutan agentes de programación a escala pueden probar el armazón con sus propios repositorios y herramientas en lugar de dar por buenas las cifras de la evaluación del artículo. El interés inicial en GitHub no equivale a adopción en producción, y una mejora de eficiencia a nivel de armazón no cambia lo que el modelo subyacente puede o no puede hacer: cambia lo barato que resulta ejecutarlo. Cualquiera que construya sobre esto debería medir el ahorro de tokens y de costes con sus propias cargas de trabajo antes de citar las cifras del artículo en una propuesta para un cliente.

Por qué te interesa: medir el trabajo terminado

Para una prueba útil, elige tareas que el equipo realice de verdad: corregir un error, añadir una función pequeña o actualizar una dependencia con sus pruebas. Repite la comparación manteniendo el mismo modelo, repositorio, instrucciones y criterios de aceptación. Cuenta también intentos fallidos, esperas y correcciones manuales: una sesión que consume menos tokens pero deja el trabajo sin terminar no supone un ahorro. Conserva el estado inicial para poder comparar los cambios y deshacerlos sin perder las pruebas originales.

Registra por separado los tokens de entrada y salida, el coste facturado, la duración y las tareas aceptadas tras la revisión. El precio depende del modelo y de las condiciones del proveedor: reducir tráfico no implica el mismo descuento porcentual en la factura. Un MSP debe separar las mediciones por proyecto, sin copiar contenido de un cliente en los registros o las pruebas de otro. La comparación debe seguir siendo reproducible después de una actualización, con la configuración utilizada debidamente documentada.

El tratamiento de las observaciones necesita una comprobación específica. Verifica que un error de compilación, una prueba fallida o una advertencia de seguridad sigan siendo recuperables después de reducir el contexto. Define dónde se guardan los archivos, quién puede leerlos y cuándo se eliminan. Antes de activar un modelo adicional para resumir registros, comprueba el recorrido de los datos y las credenciales implicadas. Un resumen útil debe conservar las pruebas necesarias para revisar un cambio, incluso si contradicen una respuesta final aparentemente satisfactoria.

Empieza con una copia aislada del repositorio y datos de prueba, sin credenciales de producción. Establece un límite de gasto y una condición de parada; amplía el alcance solo si la calidad y los tiempos resultan aceptables. La decisión se refiere al coste de una tarea completada y verificada, no a un contador aislado. Para encajar esta evaluación en los procesos de la empresa, puedes partir de los servicios de inteligencia artificial de Altovar y definir antes los objetivos y la persona responsable de la revisión.

Fuentes: arXiv, GitHub.