Tu agente de código está pagando precios premium por preguntas de opción múltiple.
¿Qué notas debería cargar? ¿Este paso va al modelo grande o a uno pequeño? La herramienta acaba de fallar. ¿Reintento, corrijo o me rindo? ¿Qué pruebas deberían ejecutarse primero?
Cada una de esas es una pregunta con cuatro o cinco respuestas posibles. Y en la mayoría de las configuraciones de agentes actuales, todas se responden con el modelo más caro que tienes, con el modo de razonamiento activado, leyendo todo el contexto y escribiendo un párrafo antes de tomar una decisión.
Esa es la fuga.
Este artículo te muestra cómo taparla. Opus 5.5 se queda con el razonamiento complejo: planificar, escribir código, depurar. Jev se encarga de las cuatro decisiones que ocurren en casi cada paso. Tu harness prepara las opciones, verifica las respuestas y toma la decisión final.
En el ejemplo práctico que verás más abajo, una sesión para desarrollar una funcionalidad pasa de $6.42 a $2.00. Eso es un 69 % más barato, y cada línea del cálculo está en este artículo para que puedas compararlo con tus propios números.
Esto está escrito para cualquiera que ejecute un agente de código en trabajo real: Claude Code, tu propio harness sobre la API o cualquier punto intermedio. No necesitas reescribir tu agente. Cada pieza de este artículo encaja en un loop existente como una llamada a función con un flag para desactivarla. Si leíste mi artículo sobre Jev + Claude Code, esta es la versión mejorada: misma idea, un modelo de razonamiento más nuevo y cuatro decisiones específicas en lugar de un principio general.
Necesitarás una clave de API de Jev, una clave de API de Anthropic y aproximadamente una semana de logs de tu propio agente para comparar.
Vamos a construirlo.
opus razona, jev decide.
El problema: un modelo haciendo dos trabajos
Observa trabajar a un agente de código durante diez minutos y lo verás hacer dos tipos de tareas muy distintas.
El primer trabajo es razonar. Planificar una funcionalidad. Escribir una función. Leer un stack trace y descubrir por qué el parser de fechas falla en los años bisiestos. Este trabajo es abierto. La respuesta no está en una lista. Aquí quieres el modelo más inteligente que puedas pagar, y Opus 5.5 es muy bueno en esto.
El segundo trabajo es decidir. Elegir las tres notas del proyecto que importan de entre cuarenta. Decidir que un cambio de nombre puede ir a un modelo barato. Elegir qué hacer después de que npm test agote el tiempo de espera. Seleccionar qué 12 archivos de prueba ejecutar antes de correr los 1,400 completos. Estas respuestas sí están en una lista. La lista es corta. Y tu código puede actuar directamente sobre la respuesta.
La mayoría de los agentes ejecutan ambos trabajos con el mismo modelo, porque es lo que viene por defecto. El loop llama a Opus, Opus piensa, Opus responde, el loop continúa.
Funciona. Pero también es lento y caro de una manera fácil de pasar por alto, porque las llamadas de decisión no parecen costosas si las miras una por una. Una sola llamada de "qué notas necesito" cuesta quizá un centavo. Pero ocurre en cada paso, y arrastra todo el contexto consigo cada vez.
Y hay un segundo costo aún más fácil de ignorar: cuando el agente no puede decidir qué cargar, carga todo. Cada nota del proyecto, cada documento de convenciones, cada decisión pasada, todo metido a la fuerza en cada llamada. Opus 5.5 abarató las lecturas de caché a $0.20 por millón de tokens, pero "barato multiplicado por sesenta pasos multiplicado por toda tu carpeta de notas" igual suma.
La solución: Opus razona, Jev decide, tu harness manda
Jev es el modelo de TypeSafe creado exactamente para el segundo trabajo. No escribe texto. Le das contexto y preguntas tipadas con un conjunto fijo de opciones, y te devuelve una probabilidad para cada opción. Responde en milisegundos, el input cuesta $0.042 por millón de tokens y el output es gratis.
Eso hace que la arquitectura sea simple de describir:
Opus 5.5 hace el razonamiento. Planificación, código, depuración, cualquier cosa donde la respuesta no esté en una lista.
Jev toma las decisiones pequeñas. Elige entre las opciones que preparó tu harness.
Tu harness sigue al mando. Construye las listas de opciones, lee las probabilidades, aplica umbrales y recurre a Opus cuando Jev no está seguro.
Esa tercera línea es la que la gente se salta, y es la que hace que todo el sistema sea seguro. Jev nunca inventa una opción. Jev nunca tiene la última palabra sobre algo que no puedas deshacer. Tu código decide qué significa "suficientemente seguro".
Aquí está la función auxiliar sobre la que se construye todo lo demás en este artículo:
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Conecta esto a tu cliente de Jev: el SDK de TypeSafe, Vercel AI Gateway,
o el paquete de LangChain. Debe devolver {opción: probabilidad}
para cada opción que le pasaste.
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
Fíjate en lo que no está ahí: ninguna pregunta que le pida a Jev qué tan seguro está. Lees la probabilidad que devuelve. Preguntarle a cualquier modelo "¿estás seguro?" te dará un "sí" casi siempre. La probabilidad es la señal honesta.
Ahora, las cuatro decisiones.
Las cuatro decisiones dentro de un paso del agente
Decisión 1: elegir las notas relevantes del proyecto antes de cargar el contexto
Esta es la palanca individual más grande, y es la que casi nadie ha implementado.
Tu agente tiene una carpeta de notas. Un AGENTS.md, documentos de arquitectura, convenciones, decisiones pasadas, advertencias como "nunca toques el módulo de facturación sin una migración". Quizá unos 30,000 tokens en total. La mayoría de los agentes cargan todo eso en cada llamada, porque nadie quiere ser quien dejó fuera la nota importante.
Así que, en lugar de cargar todo, le haces a Jev una pregunta simple sobre cada nota, todo en paralelo: ¿el agente necesita esta nota para esta tarea?
Primero, divide tus notas en fragmentos por encabezado. Cada sección de AGENTS.md se convierte en su propio fragmento. Cada documento de arquitectura se convierte en uno o más fragmentos.
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
Luego evalúa cada fragmento frente a la tarea actual:
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Would an engineer need this note to do the task correctly?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
Aquí hay tres detalles importantes.
Carga siempre lo innegociable. Algunas notas deben estar en cada llamada pase lo que pase: reglas de seguridad, "nunca hagas force push", esa única línea que dice qué base de datos es la de producción. Etiquétalas como always y omite evaluarlas.
Mantén un piso y un plan B. Si nada supera el 0.55, igual cargas las dos principales. Un agente sin contexto es peor que uno con un poco de contexto de más.
Registra lo que se descarta. Cuando el agente comete un error, lo primero que revisas es si la nota que lo habría evitado fue descartada por el puntaje. Ese log es lo que usas para ajustar keep y floor.
En el ejemplo práctico, este único cambio reduce la porción de notas de cada llamada de 30,000 tokens a 6,000. Por sí solo, eso recorta el costo de la sesión en aproximadamente un 24 %.
Decisión 2: derivar las tareas adecuadas a un worker más rápido
No todos los pasos necesitan a Opus.
Renombrar una función en ocho archivos no lo necesita. Agregar un campo a un formulario que ya tiene nueve campos idénticos tampoco. Actualizar una ruta de importación, menos. Son ediciones que siguen un patrón que ya existe en el código.
Entonces, antes de que se ejecute cada paso, Jev clasifica el paso y tu harness asigna esa clase a un worker:
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="What kind of work is this step?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
Observa cómo están escritas las opciones. No son "fácil" y "difícil", y definitivamente no son "¿puede un modelo pequeño manejar esto?". Son tipos concretos de trabajo que tu código puede mapear a una acción. Esa es la regla para cada pregunta de Jev: cada opción tiene que ser algo sobre lo que tu harness sepa cómo actuar.
Y fíjate en el valor por defecto. Por debajo de 0.8, el paso va a Opus. Los errores de ruteo aquí solo van en una dirección: una tarea difícil enviada al worker rápido te cuesta un paso fallido y un reintento, mientras que una tarea fácil enviada a Opus solo cuesta un poco más. Así que ante la duda, mándala hacia arriba.
Para el worker rápido uso Haiku 4.5 a $1 por millón de tokens de entrada y $5 por millón de salida. En el ejemplo práctico, 12 de los 36 pasos de trabajo real van a él.
Decisión 3: elegir una ruta de recuperación cuando falla una herramienta
Las herramientas fallan constantemente. Las pruebas agotan el tiempo. Una ruta de archivo está mal. Un paquete no está instalado. Un comando de shell da un error de permisos. Un linter se queja de algo que no tiene nada que ver.
La mayoría de los agentes manejan esto de la forma más cara posible: le devuelven todo el error al modelo grande y dejan que piense qué hacer. A veces eso es correcto. Muchas veces la respuesta es obvia, y Opus gasta 1,500 tokens redescubriendo que ENOENT significa que el archivo no está ahí.
Peor aún, los agentes quedan atrapados en loops. Reintentar, fallar, reintentar, fallar, pagando cada vez por un paso completo de razonamiento.
Así que le entregas el fallo a Jev con un conjunto fijo de rutas de recuperación:
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # últimos n caracteres del error
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="What is the best next move after this failure?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # red inestable o timeout3 "retry_after_install", # falta un paquete o herramienta4 "fix_path_and_retry", # ruta de archivo o cwd incorrecta5 "switch_tool", # esta herramienta no puede hacerlo, otra sí6 "escalate_to_opus", # requiere depuración real7 "stop_and_report", # necesita intervención humana8]
El límite estricto de intentos vive en el código, no en el modelo. Ningún modelo, por barato que sea, debería poder reintentar indefinidamente.
Cada ruta de recuperación se mapea a una pequeña función en tu harness. retry_after_install extrae el paquete faltante del error con una expresión regular y lo instala. fix_path_and_retry verifica las rutas que existen y sugiere la coincidencia más cercana. Solo escalate_to_opus gasta dinero real, y solo se dispara cuando el fallo realmente requiere pensar.
En el ejemplo práctico, esto elimina 6 pasos de reintento desperdiciados de la sesión.
Decisión 4: ejecutar verificaciones focalizadas antes de la suite completa de pruebas
Esta ahorra más tiempo que dinero, y el tiempo es lo que hace que un agente se sienta rápido.
Después de cada cambio, la mayoría de los agentes ejecutan toda la suite de pruebas. Si tu suite tarda cuatro minutos, tu agente pasa cuatro minutos esperando después de cada edición, y luego lee cientos de líneas de output buscando el único fallo que importa.
La solución usa el mismo patrón que con las notas: evalúa cada archivo de prueba contra el diff, ejecuta primero los más relevantes y corre la suite completa solo cuando las verificaciones focalizadas pasan.
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Could this change break tests in this file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # falla rápido, corrige antes que nada18 return run_tests(test_files) # la suite completa sigue siendo requisito para el commit
Lee esa última línea dos veces. La suite completa se sigue ejecutando antes de que se haga algún commit. Las verificaciones focalizadas son una alerta temprana, no un reemplazo. Detectas la mayoría de los errores en segundos en lugar de minutos, y nunca subes algo que la suite completa habría detectado.
Agrega también primero las verificaciones baratas: chequeo de tipos y lint solo en los archivos modificados. Toman un segundo y atrapan una cantidad sorprendente de errores antes de que corra cualquier prueba.
Integrando todo: el loop del harness
Así es como las cuatro decisiones encajan dentro de un paso del loop:
def run_step(task: str, step: str, state):
1. contexto: cargar solo las notas que este paso necesita
notes = state.always_notes + pick_notes(step, state.notes)
2. ruteo: elegir el worker para este paso
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. recuperación: manejar cualquier fallo de herramienta en este paso
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. verificaciones: pruebas focalizadas primero, suite completa antes del commit
if result.diff:
state.log_check(check(result.diff, state.test_files))
Y aquí está la parte de Opus: es simplemente tu llamada normal a Opus 5.5. Pon primero tu contexto estable (system prompt, definiciones de herramientas, las notas "always") para que se mantenga en caché entre pasos, y deja el material específico del paso para el final.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # el id de tu modelo Opus 5.5
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
Nada exótico. El ahorro viene de lo que dejas de enviarle, no de un prompt ingenioso.
Un paso, trazado
Así se ve un solo paso en el log una vez que las cuatro decisiones están activas. La tarea: agregar rate limiting al endpoint público de registro. Esta traza es ilustrativa, pero es la forma que verás en tus propios logs.
step 14 "add a per IP rate limit to POST /signup"
[notes] evaluados 41 fragmentos en paralelo
mantenidos: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
descartados: 37 fragmentos, incluyendo facturación, plantillas de email, CI
[route] new_logic (0.91) → opus
[opus] planifica el cambio, escribe middleware + config + edición del handler
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, volver a ejecutar
[checks] typecheck en archivos modificados: pass
pruebas focalizadas (12 de 1,388): pass
suite completa: pass
Léelo de arriba a abajo y cuenta cuántas de esas líneas solían ser una llamada completa a Opus. Elegir notas: una llamada enorme, o ninguna selección y 30,000 tokens de notas cargados a ciegas. Ruteo: nada, cada paso iba a Opus. El paquete faltante: un paso completo de razonamiento para deducir que un módulo faltante significa "instalar el módulo". Elegir pruebas: nada, la suite completa en cada edición.
Ahora solo una línea en esa traza es Opus, y es la línea que realmente necesitaba un modelo frontier: planificar y escribir el limitador de tasa.
Esa es toda la idea en una imagen. El modelo caro dedica su tiempo a la parte del trabajo que solo él puede hacer.
El ejemplo práctico: de dónde sale el 69 %
Aquí está el cálculo completo para una sesión de desarrollo de una funcionalidad: 60 pasos del agente más los 6 reintentos desperdiciados que un agente típico acumula en el camino. Todos los precios son los de lista públicos actuales.
Antes: Opus 5.5 hace todo
Cada paso carga 70,000 tokens de contexto: 15,000 para el system prompt y las herramientas, 30,000 para toda la carpeta de notas y 25,000 para la conversación hasta ese momento. Asumo que el 80 % de eso es un acierto de caché. Cada paso produce unos 1,500 tokens de salida, porque el razonamiento siempre está activo en Opus 5.5.
lecturas de caché: 56,000 × $0.20/M = $0.0112
input nuevo: 14,000 × $4.00/M = $0.0560
output: 1,500 × $20.00/M = $0.0300
por paso = $0.0972
66 pasos × $0.0972 = $6.42
Después: la capa de decisión
El contexto baja a 46,000 tokens por paso, porque Jev elige 6,000 tokens de notas en lugar de cargar los 30,000 completos. Los 24 pasos puramente de decisión pasan a Jev. Los 6 loops de reintento desaparecen. Y 12 de los 36 pasos de trabajo restantes van a Haiku 4.5.
Opus 5.5: 24 pasos × $0.0742 = $1.78
Haiku 4.5: 12 pasos × $0.0169 = $0.20
Jev: 102 llamadas × 5,000 tokens
× $0.042/M, output gratis = $0.02
total = $2.00
De $6.42 a $2.00. Eso es un 68.8 % más barato por la misma funcionalidad.
define el umbral según lo que cuesta una respuesta incorrecta
Y así es cuánto aporta cada palanca, apiladas en orden:
solo selección de notas $4.89 23.7 % ahorrado
- decisiones movidas a Jev $3.13 51.2 % ahorrado
- rutas de recuperación $2.69 58.1 % ahorrado
- ruteo a un worker rápido $2.00 68.8 % ahorrado
Dos aclaraciones honestas sobre estos cálculos.
Primero, estos son números modelados basados en suposiciones explícitas, no una medición de tu stack. El tamaño de tu contexto, tu tasa de aciertos de caché y tu cantidad de decisiones serán distintos. El objetivo de mostrar cada línea es para que puedas intercambiarlas por tus propios números. Una vez que midas tu antes y después real, usa tu número, no el mío.
Segundo, mira adónde va realmente el dinero. Las 102 llamadas de Jev cuestan dos centavos en total. El ahorro no viene de que Jev sea barato por llamada. Viene de todo lo que deja de ocurrir una vez que Jev toma la decisión: contexto inflado, pasos completos de razonamiento para preguntas de opción múltiple, loops de reintento y llamadas al modelo grande para tareas de renombrado.
¿Por qué no usar simplemente Haiku para las decisiones?
Pregunta justa. Haiku 4.5 es barato y rápido. ¿Para qué agregar un modelo nuevo?
Tres razones.
Sigue escribiendo. Haiku responde en texto. Tienes que indicarle en el prompt que responda con una de tus opciones, luego parsear la respuesta, y después lidiar con las veces que agrega una explicación, elige algo que no está en la lista o envuelve la respuesta en una oración. Jev devuelve una probabilidad para cada opción que le pasaste. No hay nada que parsear y nada fuera de la lista.
Obtienes la distribución completa, no solo una respuesta. Cuando Jev dice needed: 0.52, not_needed: 0.48, sabes que es como lanzar una moneda y tu harness puede escalar. Cuando un modelo de texto dice "needed", no tienes idea de si estaba seguro. Los umbrales solo funcionan cuando puedes ver las probabilidades.
La matemática de costos es distinta. El output de Jev es gratis y su input cuesta $0.042 por millón de tokens. Evaluar 41 fragmentos de notas en cada paso significa 41 llamadas pequeñas por paso. Con Jev eso es una fracción de centavo. Con cualquier modelo de texto, incluso uno barato, son 41 generaciones con su propio costo de output y latencia.
Usa Haiku para ediciones pequeñas, donde realmente tiene que escribir código. Usa Jev para elegir de listas. Usa Opus para pensar. Cada modelo hace el trabajo para el que fue diseñado.
Cómo implementarlo sin romper nada
No actives las cuatro decisiones de golpe. Este es el orden que yo usaría.
Semana 1: shadow mode. Mantén tu agente actual exactamente como está. Para cada decisión que tome, hazle también a Jev la misma pregunta y registra ambas respuestas junto con la probabilidad de Jev. No actúes en absoluto sobre la respuesta de Jev.
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
Semana 2: lee los desacuerdos. Mira solo las filas donde Jev y tu agente actual discreparon. Ordénalas por la probabilidad de Jev. Generalmente encontrarás una línea clara: por encima de cierta probabilidad, Jev acierta casi tan seguido como Opus. Esa línea es tu umbral. Esas filas de desacuerdo también se convierten en tu set de pruebas, generado gratis a partir de tu tráfico real.
Semana 3: activa la selección de notas. Es la palanca más grande y la más fácil de deshacer, ya que una nota omitida aparece rápido en tus logs.
Semana 4: activa la recuperación y las pruebas. Ambas tienen límites estrictos y planes B en el código, así que el peor escenario es volver a lo que haces hoy.
Por último: el ruteo. Los errores de ruteo son los más visibles para los usuarios, porque una tarea difícil enviada al worker rápido produce código malo. Actívalo al final, con un umbral conservador, y vigila la tasa de fallos en los pasos del worker rápido.
Pon cada decisión detrás de un flag de encendido/apagado para que puedas deshacerla en una línea.
Definiendo umbrales según el riesgo
Un solo umbral para todo es un error. Defínelos según lo que pasa cuando la respuesta es incorrecta.
Una sesión de desarrollo, mismo resultado: de $6.42 a $2.00
Riesgo bajo, fácil de deshacer: 0.55 a 0.65. Elegir notas. Ordenar pruebas. Una respuesta incorrecta cuesta un poco de contexto o unos segundos.
Riesgo medio: 0.8. Ruteo y recuperación. Una respuesta incorrecta cuesta un paso fallido, que tu harness detecta.
Riesgo alto, difícil de deshacer: 0.9 o nunca. Eliminar archivos. Hacer force push. Tocar la configuración de producción. Ejecutar una migración. Mi consejo honesto: no dejes que ningún modelo tome estas decisiones solo. Derívalas a un humano o, como mínimo, a Opus con un paso de confirmación.
Todo lo que quede por debajo del umbral escala: a Opus si requiere razonamiento, a un humano si requiere criterio.
Dónde esto no ayuda
Esta arquitectura no es un multiplicador mágico para cualquier carga de trabajo.
Las cargas de generación pura apenas cambian. Si tu agente pasa la mayor parte del tiempo escribiendo grandes cantidades de código nuevo a partir de una especificación clara, no hay muchas decisiones que mover. Igual obtendrás el ahorro de la selección de notas, pero poco más.
Los proyectos pequeños no lo necesitan. Si toda tu carpeta de notas tiene 2,000 tokens y tu suite corre en ocho segundos, el esfuerzo de construir esto todavía no vale la pena.
Jev no es ideal para tomar la decisión final por su cuenta. Es excelente para notar cosas y elegir de una lista corta. No es el modelo que quieres decidiendo "¿este pull request está listo para mergearse?" como una sola pregunta. Divide las preguntas grandes en pequeñas, evalúa cada una y combina los resultados en tu propio código con tus propios pesos.
Si ya tienes datos etiquetados para una pregunta fija, un modelo pequeño alojado por ti mismo puede superar a Jev en precio. Jev brilla cuando las preguntas cambian constantemente y no tienes datos de entrenamiento, lo cual describe a la mayoría de los agentes de código.
Los errores que yo evitaría
Dejar que el modelo escriba la lista de opciones. Toda la arquitectura depende de opciones sobre las que tu código pueda actuar. Si un modelo genera las opciones, vuelves a tener que parsear texto libre.
Preguntarle a Jev si está seguro. Lee la probabilidad en su lugar. Un autoinforme casi siempre será "sí".
Sin plan B. Cada decisión de Jev necesita una ruta para "no estoy seguro", y esa ruta es Opus o un humano, nunca una suposición.
Límites de reintento en el prompt en lugar del código. Un modelo al que le dices "reintenta solo 3 veces" ocasionalmente reintentará 30 veces. El código no.
Descartar la suite completa de pruebas. Las verificaciones focalizadas te aceleran. La suite completa te mantiene honesto. Quédate con ambas.
No medir nada. Si no registras el costo por sesión antes de empezar, nunca vas a saber si ahorraste un 20 % o un 70 %. Primero, extrae los datos de uso de una semana de trabajo normal. Te toma diez minutos y es la única métrica que importa.
Qué hacer esta semana
Aquí tienes todo el proceso en forma de checklist:
- Registra una semana de sesiones del agente: pasos, tokens, costo y fallos.
- Identifica las decisiones ocultas en tu loop: notas, ruteo, recuperación y pruebas.
- Redacta cada una como una pregunta con una lista fija de opciones.
- Ejecuta Jev en modo sombra junto a tu agente actual durante una semana.
- Define los umbrales a partir del registro de discrepancias, según el nivel de riesgo.
- Activa primero la selección de notas; luego, la recuperación y las pruebas; y por último, el ruteo.
- Compara el costo por sesión antes y después. Ese es tu número.
Opus 5.5 es el mejor modelo de razonamiento que he usado para código. El error es obligarlo a hacer también todo lo demás.
Déjalo pensar. Deja que Jev decida. Deja que tu código mande.
Si te resultó útil, sigue a @cyrilXBT. Cada semana explico cómo desarrollar con los modelos de IA más nuevos, con números reales.
Guarda este artículo en tus marcadores para tenerlo a mano cuando empieces a construir.
