Tu agente de código está pagando precios de modelo frontier 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 abandono? ¿Qué tests 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 ellas las responde el modelo más caro que tienes, con el modo thinking activado, leyendo todo el contexto y escribiendo un párrafo antes de decidirse.
Ahí está la fuga.
Este artículo te muestra cómo taparla. Opus 5.5 se queda con el razonamiento difícil: planificar, escribir código, depurar. Jev se encarga de las cuatro decisiones que ocurren en casi cada paso. Tu harness prepara las opciones, comprueba las respuestas y toma la decisión final.
En el ejemplo práctico de abajo, una sesión para desarrollar una funcionalidad pasa de $6.42 a $2.00. Eso es un 69 % menos, y cada línea del cálculo está en este artículo para que puedas contrastarlo 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 bucle 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 haciendo 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 renombrado puede ir a un modelo barato. Elegir qué hacer después de que npm test agote el tiempo. Decidir qué 12 archivos de test ejecutar antes de los 1,400 completos. Estas respuestas 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 bucle llama a Opus, Opus piensa, Opus responde, el bucle continúa.
Funciona. Pero también es lento y caro de una forma fácil de pasar por alto, porque las llamadas de decisión no parecen costosas si las miras de una en una. Una sola llamada de "qué notas necesito" cuesta quizá un centavo. Pero ocurre en cada paso, y arrastra consigo todo el contexto cada vez.
Y hay un segundo coste aún más fácil de ignorar: cuando el agente no sabe qué cargar, lo carga todo. Cada nota del proyecto, cada documento de convenciones, cada decisión pasada, metido a presión 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" sigue sumando.
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 sencilla 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 mantiene el control. 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 pases.
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 hay ahí: ninguna pregunta que le pida a Jev cuán 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 potente, 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 de "nunca toques el módulo de facturación sin una migración". Quizá 30,000 tokens de eso. La mayoría de los agentes lo cargan todo en cada llamada, porque nadie quiere ser quien dejó fuera la nota importante.
Así que, en lugar de cargarlo todo, le haces a Jev una pregunta simple sobre cada nota, todo en paralelo: ¿necesita el agente 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 puntú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í importan tres detalles.
Carga siempre lo innegociable. Algunas notas deberían 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 sáltate su puntuación.
Mantén un mínimo y un plan B. Si nada supera el 0.55, aun así cargas las dos mejores. Un agente con cero 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 la puntuación. Ese log es lo que te permite ajustar keep y floor.
En el ejemplo práctico, este único cambio reduce la parte de notas de cada llamada de 30,000 tokens a 6,000. Por sí solo, eso recorta el coste 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. Añadir un campo a un formulario que ya tiene nueve campos idénticos, tampoco. Actualizar una ruta de importación, tampoco. Son ediciones que siguen un patrón que ya está en el código.
Así que, 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]
Fíjate en cómo están escritas las opciones. No son "fácil" y "difícil", y desde luego no son "¿puede un modelo pequeño encargarse de esto?". Son tipos concretos de trabajo que tu código puede mapear a una acción. Esa es la regla para cada pregunta a Jev: cada opción tiene que ser algo sobre lo que tu harness sepa actuar.
Y observa el valor por defecto. Por debajo de 0.8, el paso va a Opus. Los errores de enrutamiento 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. Los tests agotan el tiempo. Una ruta de archivo es incorrecta. Falta un paquete por instalar. 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 lo 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 se atascan en bucles. 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 incorrectos5 "switch_tool", # esta herramienta no puede hacerlo, otra sí6 "escalate_to_opus", # necesita 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 regex y lo instala. fix_path_and_retry comprueba 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 comprobaciones focalizadas antes de la suite completa de tests
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 tests. Si tu suite tarda cuatro minutos, tu agente pasa cuatro minutos esperando tras cada edición, y luego lee cientos de líneas de output buscando el único fallo que importa.
La solución sigue el mismo patrón que con las notas: puntúa cada archivo de test frente al diff, ejecuta primero los más relevantes y solo lanza la suite completa cuando las comprobaciones 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 sigue ejecutándose antes de que se haga commit de nada. Las comprobaciones focalizadas son una alerta temprana, no un reemplazo. Detectas la mayoría de los fallos en segundos en lugar de minutos, y nunca subes algo que la suite completa habría detectado.
Añade también primero las comprobaciones baratas: type check y lint solo sobre los archivos modificados. Tardan un segundo y atrapan una proporción sorprendente de errores antes de que corra ningún test.
Uniendo las piezas: el bucle del harness
Así es como encajan las cuatro decisiones dentro de un paso del bucle:
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. enrutamiento: 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: gestionar 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. comprobaciones: tests focalizados 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í es como se ve un solo paso en el log una vez que las cuatro decisiones están activas. La tarea: añadir 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] 41 fragmentos puntuados en paralelo
kept: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
dropped: 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 de archivos modificados: pass
tests focalizados (12 de 1,388): pass
suite completa: pass
Léelo de arriba 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. Enrutamiento: nada, cada paso iba a Opus. El paquete faltante: un paso completo de razonamiento para deducir que un módulo ausente significa "instala el módulo". Elegir tests: nada, la suite completa en cada edición.
Ahora solo una línea de 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 por el camino. Todos los precios son los precios públicos actuales.
Antes: Opus 5.5 lo 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 genera unos 1,500 tokens de salida, porque el thinking siempre está activado en Opus 5.5.
cache reads: 56,000 × $0.20/M = $0.0112
fresh input: 14,000 × $4.00/M = $0.0560
output: 1,500 × $20.00/M = $0.0300
per step = $0.0972
66 steps × $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 bucles de reintento desaparecen. Y 12 de los 36 pasos de trabajo restantes van a Haiku 4.5.
Opus 5.5: 24 steps × $0.0742 = $1.78
Haiku 4.5: 12 steps × $0.0169 = $0.20
Jev: 102 calls × 5,000 tokens
× $0.042/M, output free = $0.02
total = $2.00
De $6.42 a $2.00. Eso es un 68.8 % más barato para la misma funcionalidad.
define el umbral según lo que cueste una respuesta equivocada
Y aquí tienes 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
- enrutamiento a worker rápido $2.00 68.8% ahorrado
Dos apuntes honestos sobre estos cálculos.
Primero, son cifras modeladas basadas en suposiciones explícitas, no una medición de tu stack. Tu tamaño de contexto, tasa de aciertos de caché y número de decisiones serán distintos. El motivo de mostrar cada línea es para que puedas sustituir mis números por los tuyos. Una vez que midas tu antes y después real, usa tu cifra, no la mía.
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, bucles 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. ¿Por qué añadir un modelo nuevo?
Tres razones.
Sigue escribiendo. Haiku responde en texto. Tienes que indicarle mediante prompt que responda con una de tus opciones, luego parsear la respuesta, y luego lidiar con las veces que añade una explicación, elige algo que no está en la lista o envuelve la respuesta en una frase. 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 lanzar una moneda y tu harness puede escalar. Cuando un modelo de texto dice "needed", no tienes ni idea de si estaba seguro. Los umbrales solo funcionan cuando puedes ver las probabilidades.
La matemática del coste es distinta. El output de Jev es gratis y su input cuesta $0.042 por millón de tokens. Puntuar 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 coste 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 a la vez. Este es el orden que yo seguirí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. Fíjate solo en las filas donde Jev y tu agente actual discreparon. Ordénalas por la probabilidad de Jev. Normalmente encontrarás una línea clara: por encima de cierta probabilidad, Jev acierta casi tan a menudo como Opus. Esa línea es tu umbral. Esas filas de desacuerdo se convierten además en tu conjunto de pruebas, generado gratis a partir de tu tráfico real.
Semana 3: activa la selección de notas. Es la palanca más potente y la más fácil de revertir, ya que una nota omitida aparece rápido en tus logs.
Semana 4: activa la recuperación y los tests. Ambas tienen límites estrictos y alternativas en el código, así que el peor escenario es volver a lo que haces hoy.
Por último: el enrutamiento. Los errores de enrutamiento son los más visibles para los usuarios, porque una tarea difícil enviada al worker rápido produce mal código. 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 con una sola línea.
Definir umbrales según el riesgo
Un único umbral para todo es un error. Defínelos según lo que pase cuando la respuesta sea 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 tests. Una respuesta equivocada cuesta un poco de contexto o unos segundos.
Riesgo medio: 0.8. Enrutamiento y recuperación. Una respuesta equivocada cuesta un paso fallido, que tu harness detecta.
Riesgo alto, difícil de deshacer: 0.9 o nunca. Borrar archivos. Hacer force push. Tocar la configuración de producción. Ejecutar una migración. Mi consejo sincero: 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 necesita razonamiento, a un humano si necesita 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. Seguirás obteniendo el ahorro de la selección de notas, pero poco más.
Los proyectos diminutos no lo necesitan. Si toda tu carpeta de notas son 2,000 tokens y tu suite se ejecuta en ocho segundos, el esfuerzo de montar esto aún no compensa.
Jev no es ideal para tomar la decisión final por su cuenta. Es excelente detectando cosas y eligiendo de una lista corta. No es el modelo que quieres decidiendo "¿está esta pull request lista para fusionarse?" como una única pregunta. Divide las preguntas grandes en pequeñas, puntú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 parsear texto libre.
Preguntarle a Jev si está seguro. Lee la probabilidad en su lugar. Un autoinforme casi siempre será "sí".
Sin alternativa. 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 de en el 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 tests. Las comprobaciones focalizadas te aceleran. La suite completa te mantiene honesto. Quédate con ambas.
No medir nada. Si no registras el coste por sesión antes de empezar, nunca sabrás si ahorraste un 20 % o un 70 %. Extrae primero los datos de uso de una semana de trabajo normal. Te llevará diez minutos y es la única cifra que importa.
Qué hacer esta semana
Aquí tienes todo el proceso en forma de lista:
- Registra una semana de sesiones del agente: pasos, tokens, coste y fallos.
- Identifica las decisiones ocultas en tu bucle: notas, enrutamiento, recuperación y pruebas.
- Formula 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 riesgo.
- Activa primero la selección de notas, luego la recuperación y las pruebas, y por último el enrutamiento.
- Compara el coste por sesión antes y después. Esa es tu cifra.
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 ha resultado útil, sigue a @cyrilXBT. Cada semana explico cómo desarrollar con los modelos de IA más recientes, siempre con cifras reales.
Guarda este artículo en favoritos para tenerlo a mano cuando empieces a construir.
