Files

Jordan 651d61b096 P0 contexto: ventana por modelo + recuperación ante overflow + self-heal del catálogo

Que las conversaciones largas no se rompan ni gasten de más:

Ventana de contexto por modelo (antes: budget estático 120k/200k para todos):
- cost.resolve_context_window: lee context_length del catálogo OpenRouter/DeepSeek
  en Redis, con fallback a litellm. config.budget_for_window deriva el budget de
  la ventana real (window - max_output - reserve). build_context lo aplica por
  turno (param model_id) en vez del fijo de settings.
- Self-heal del catálogo OpenRouter: el admin panel lo cachea con TTL 1h y solo lo
  repuebla al abrir su ventana de IA → en runtime caducaba y se perdían ventana y
  precio. Ahora cost._get_catalog lo refresca solo (fetch público, mismo shape,
  cooldown 5min, TTL 24h). Arregla también el coste (caía al fijo).

Recuperación ante overflow:
- adapters.base.ContextOverflowError; openai_adapter traduce el error de
  context-length del proveedor (init e iteración del stream).
- base.py: retry proactivo que recompacta hasta caber en la ventana ANTES de
  llamar al LLM; si ni así cabe → error accionable (no rompe la sesión).
- engine.py: mensaje user-facing claro (modelo + ventana).

Tests: ventana/budget, self-heal (mockeado), overflow, y sesión REAL de Redis. 106 verdes.

evals/: harness para evaluar al agente acai-code (driver + README + resultados).
Comparativa kimi vs deepseek vs glm (deepseek-v4-pro high = mejor calidad/precio).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-20 13:48:19 +01:00

.gitignore

P0 contexto: ventana por modelo + recuperación ante overflow + self-heal del catálogo

2026-06-20 13:48:19 +01:00

driver.py

P0 contexto: ventana por modelo + recuperación ante overflow + self-heal del catálogo

2026-06-20 13:48:19 +01:00

README.md

P0 contexto: ventana por modelo + recuperación ante overflow + self-heal del catálogo

2026-06-20 13:48:19 +01:00

results-landing-build.md

P0 contexto: ventana por modelo + recuperación ante overflow + self-heal del catálogo

2026-06-20 13:48:19 +01:00

README.md

Evals del agente acai-code

Harness para evaluar el comportamiento del agente IA (acai) montando una landing real con módulos gestionables, capturando cada turno (thinking, tool calls, resultados, errores). Sirve para comparar entre modelos y discernir si un fallo es del modelo o de la documentación/KB (mismo flujo, mismo proyecto, distinto modelo → ¿cambian los errores?).

Cómo correrlo

Elige el modelo activo en el Forge Admin Panel → ventana de IA (provider + modelo + reasoning). El catálogo OpenRouter se auto-repuebla en runtime aunque caduque (ver orchestrator/cost.py: _get_catalog).
Usa un proyecto en modo TEST (no producción) — el agente escribe módulos/ records reales en la copia forge-local. Nunca corras esto contra producción.
Lanza cada turno con el driver, reutilizando el session_id que devuelve el primer turno para mantener la MISMA conversación:

NET=acai-vscode-plugin_acai-net   # red docker del compose
docker run --rm --network $NET \
  -v "$PWD/agenticSystem/evals:/data" -v "$PWD/agenticSystem/evals/logs:/logs" \
  -e EVAL_PROJECT=empleo.cocosolution.com \
  -w /data acai-vscode-plugin-agentic \
  python /data/driver.py "Móntame una sección de beneficios con 3 tarjetas"

# turno 2 (reusa el SESSION_ID del turno 1):
docker run ... python /data/driver.py "Ahora una sección de equipo con fotos y enlaces" "<SESSION_ID>"

El log completo (en vivo) se acumula en evals/logs/session.log.
El driver autentica con X-Acai-User hiteando app:9091 directo en la red interna (somos superadmin en infra de confianza).

Métricas que captura

nº de tool calls, errores (success:false, HTTP_4xx), tools repetidas (señal de bucle), tokens de input/output (coste del thrashing).

Resultados

Ver results-landing-build.md — un apartado por modelo, para comparar.