Claude Opus 4.7: review honesto desde la trinchera
Cuando sale una versión nueva de un modelo, todo el mundo opina en la primera semana. Yo prefiero esperar. Tres semanas usándolo en cosas reales antes de escribir nada. Acá va lo que aprendí de Opus 4.7 sin comprar el hype y sin descalificarlo gratis.
Qué probé exactamente
Tres flujos, los tres en producción, los tres con benchmark mental contra 4.6:
- Agentes largos: tareas de 20 a 40 pasos, con tool use, planning y autocorrección.
- Code review: revisión de PRs en proyectos propios, mezclando Python, JavaScript y SQL.
- Razonamiento de marketing: análisis de campañas, decisiones de portafolio, redacción crítica.
No usé benchmarks sintéticos. No corrí evals con datasets públicos. Esos números los publica Anthropic y los publica gente que los hace bien. Yo te cuento lo que se siente al usarlo en serio.
Lo que mejora claro
Agentes de varios pasos
Acá la mejora es notable. 4.7 mantiene el plan más estable cuando la tarea tiene muchos pasos. 4.6 a veces se desviaba a la mitad y había que recordarle el objetivo. 4.7 se acuerda mejor por más tiempo.
En un flujo de 30 pasos donde antes tenía que reinjectar contexto cada cierto tiempo, 4.7 lo lleva sin necesidad. Eso ahorra tokens y ahorra dolor.
Mantener contexto largo
Le pegué documentos largos, conversaciones extensas, históricos. 4.7 cita con más precisión partes específicas del contexto cuando uno se las pide. 4.6 a veces parafraseaba. 4.7 cita textual cuando importa.
Razonamiento sobre data
Cuando le pego una tabla y le pido conclusiones cualitativas, 4.7 es más conservador y más preciso. Menos invención, más "esto no está claro en los datos, necesitaríamos X". Eso es bueno.
Lo que empeoró (sí, hay cosas)
Acá viene la parte que la mayoría de reviews evita.
Matiz de español
En español neutro, 4.7 funciona igual o mejor. En español mexicano con tuteo y modismos, sentí algunos retrocesos. El modelo es más cauteloso y a veces "limpia" giros que yo quería conservar. Hay que ser más explícito en el prompt sobre el registro.
Sobrecorrección en correos cortos
Para un correo de tres líneas, 4.7 a veces te devuelve uno de seis con disclaimers innecesarios. 4.6 era más conciso de fábrica. Se arregla con prompt, pero es fricción.
Cautela extra en código que toca infra
Cuando el code review involucra deployment, secrets o cosas que pueden romper producción, 4.7 es más cauto. Eso es bueno en general, pero a veces sobre-advierte cosas obvias. Cansa.
Lo que se mantiene
- Calidad de redacción larga: similar.
- Honestidad cuando no sabe: similar, sigue siendo de los mejores en decir "no estoy seguro".
- Tool use básico: sólido, sin grandes diferencias.
- Velocidad subjetiva: parecida. La latencia no se siente diferente en uso normal.
Costos
No voy a meter cifras inventadas. Lo que sí puedo decir cualitativamente: si tu flujo gasta tokens en mantener contexto y reinyectar, 4.7 te puede salir más barato porque mantiene más sin recordatorios. Si tu flujo es prompts cortos one-shot, la diferencia económica es menor.
La regla mental: 4.7 te ahorra tokens en flujos largos y te puede costar marginalmente más en flujos cortos. Mide tú, no creas a nadie.
Cuándo todavía conviene quedarse en 4.6
- Pipelines críticos en producción: si ya optimizaste prompts para 4.6 y tu flujo es estable, no rompas algo que funciona por moda.
- Costo súper sensible: si tu margen depende de cada centavo de API, evaluá con números, no con feels.
- Outputs cortos en español: donde la concisión y el tuteo importan, 4.6 sigue sintiéndose más natural en algunos casos.
- Code review hardcore: en algunos casos detecté que 4.6 cazaba bugs sutiles que 4.7 dejaba pasar. Hay que probar en tu codebase.
Cuándo upgradeo de inmediato
- Agentes largos con tool use.
- Análisis de documentos extensos.
- Tareas nuevas que estás empezando desde cero.
- Cualquier flujo donde el contexto largo sea el cuello de botella.
Recomendación de migración
Lo que yo hago: corro 4.6 y 4.7 en paralelo dos semanas en flujos comparables. Anoto qué casos prefiero en cada uno. Migro por bloque, no por proyecto entero. Si algún caso queda mejor en 4.6, ahí se queda.
Esto es lo que la gente con prisa no hace. Migran todo de golpe, descubren regresiones a la semana, y vuelven enojados. La transición ordenada toma dos o tres semanas y vale la pena.
Qué hago yo
yo recomiendo evaluar Opus 4.7 con tu propio benchmark interno, no con tweets de hype. Pruébalo en paralelo, anota regresiones honestas, migra por bloque. La nueva versión no es siempre mejor para tu caso. La regla es testear con tus prompts, tus datos y tu juicio. Y baja las expectativas: en agentes largos sí mejora bastante, en outputs cortos a veces no.
Cuando salga 4.8 hacemos lo mismo. Sin religión.
Preguntas frecuentes
¿Vale la pena upgradear a 4.7?
Sí, pero gradual. Para flujos de marketing y agentes largos, se siente mejor. Para code review profundo, en algunos casos 4.6 todavía gana. La recomendación es probar en paralelo dos semanas antes de migrar todo.
¿Hay regresiones reales en 4.7?
Sí. Detecté tres tipos: pérdida de matiz en español en algunos casos, sobrecorrección en correos cortos y un toque más cauteloso en código que toca infra. Nada bloqueante, pero existe.
¿Cuándo me quedo en 4.6?
Si tu flujo está estable, si optimizaste prompts para 4.6 y si el costo importa. No hay que migrar por moda. La nueva versión no siempre es mejor para tu caso particular.
¿Cómo decido objetivamente?
Corré los dos modelos en paralelo dos semanas en flujos comparables. Anotá qué casos prefieres. Migrá por bloque. Si algún caso quedó mejor en 4.6, ahí se queda.
¿Quieres robarte algo útil?
30 prompts curados, listos para copiar y pegar. Por perfil. Sin formularios.
Ir a Róbate Esto →