Tenés un agente en producción. Funciona bien. Después empieza a responder diferente — no mal, distinto. Más cauto en algunos casos, más directo en otros. Lo primero que revisás es tu código. Después tus herramientas. Después pensás que estás loco.
Un system prompt es básicamente la constitución de un paÃs. No la ves en el dÃa a dÃa, pero cada decisión que toma el estado tiene esa constitución de fondo. Cambiá tres artÃculos y de repente el juez falla diferente — no porque el juez sea otro, sino porque el marco legal cambió. El juez ni sabe que cambió la constitución. Vos tampoco.
Eso es exactamente lo que pasó entre Opus 4.6 y 4.7.
Claude system prompt diff: qué cambió realmente entre versiones
Anthropologic publica documentación de sus modelos, pero no hace un changelog de comportamiento como hacés con semver en código. No hay un CHANGELOG.md. No hay un git diff público entre system prompts. Tenés que construirlo vos.
Agarré los system prompts documentados públicamente — la especificación de alma de Claude, lo que llaman "Claude's character" — y los comparé entre lo que estaba disponible antes del lanzamiento de 4.7 y lo que se actualizó después. El diff es real. Te lo muestro.
Las áreas que cambiaron
1. Manejo de incertidumbre epistémica
En 4.6, el framing era algo asÃ:
# Comportamiento antes (4.6 — reconstrucción aproximada)
"Cuando no estás seguro, indicalo claramente pero
procedé con la mejor estimación disponible."
En 4.7, el énfasis se movió:
# Comportamiento después (4.7 — reconstrucción aproximada)
"Cuando no estás seguro, explorá activamente la
incertidumbre antes de dar una respuesta. Prefiere
preguntas clarificadoras a estimaciones sin base."
Diferencia práctica: mis agentes de análisis de código empezaron a pedir más contexto antes de responder. Yo pensé que habÃa un bug en el manejo de contexto del tool call. Era el modelo siendo más epistemicamente honesto.
2. Agentic behavior y autonomÃa
Este es el cambio más importante que encontré, y tiene todo el sentido dado el contexto del que ya hablé sobre tests falsos positivos en agentes.
El 4.6 tenÃa un sesgo hacia completar tareas. El 4.7 agrega fricción intencional:
# Lógica nueva en comportamiento agentic (4.7)
# El modelo ahora prefiere:
# 1. Hacer menos si hay ambigüedad sobre el scope
# 2. Confirmar antes de acciones irreversibles
# 3. Reportar dudas MID-TASK, no solo al final
# Antes:
completar_tarea() -> reportar_resultado()
# Ahora:
verificar_scope() -> confirmar_si_ambiguo() -> completar_tarea() -> verificar_resultado()
Eso explica por qué mis workflows de automatización de pronto tenÃan más interrupciones. No era un bug. Era una feature de safety que yo no pedà pero que Anthropic decidió que todos necesitábamos.
3. Tono en contextos técnicos
Este es sutil pero lo medÃ. En 4.6, cuando le dabas un system prompt técnico, Claude asumÃa audiencia experta y comprimÃa explicaciones. En 4.7, hay un recalibrado: aun con system prompts técnicos, hay más tendencia a explicar razonamiento intermedio.
Lo que antes era:
Respuesta: "Usá Ãndice compuesto en (user_id, created_at)
descendente. El query planner va a elegir index-only scan."
Ahora tiende más a:
Respuesta: "Para este patrón de consulta, un Ãndice compuesto
en (user_id, created_at) descendente deberÃa ayudar porque
[dos oraciones de razonamiento]. El query planner deberÃa
elegir index-only scan en la mayorÃa de los casos."
Más verboso. Más legible para alguien que no sabe. Menos útil cuando sos vos y querés densidad de información.
Los cambios que observé en producción antes de saber del diff
Acá está la parte que me tiene pensando. Tengo logs de mis agentes. Los reviso regularmente — lo hago desde que escribà sobre el costo semántico de comprimir prompts. No por paranoico, sino porque los números mienten de maneras interesantes.
Lo que observé antes de saber que habÃa cambiado el system prompt:
Señal 1: Más tool calls de "verificación"
Uno de mis agentes tiene acceso a herramientas de lectura de filesystem. Antes de 4.7, cuando le decÃas "analizá este directorio", iba directo. Después empezó a hacer un ls previo aunque ya le habÃas dado el path. Como checkeando que el terreno era el que pensaba.
Yo lo anoté como: "comportamiento raro, parece que no confÃa en el contexto provisto". Era el modelo siendo más cuidadoso con acciones en filesystem — exactamente el tipo de conservadurismo del que hablaba sobre confianza y configuración de entorno.
Señal 2: Respuestas más cortas en algunos contextos, más largas en otros
Mis métricas de tokens de output mostraban una distribución bimodal que antes no tenÃa. Para preguntas simples: outputs más cortos. Para preguntas con ambigüedad implÃcita: outputs más largos, con más preguntas embebidas.
El delta de costo era pequeño pero la distribución habÃa cambiado. Anoteé: "revisar si hay un problema con el temperature setting". No era el temperature.
Señal 3: El rechazo sutil
Uno de mis agentes hace análisis de código legacy — cosas feas, deuda técnica real. En algunos casos empecé a recibir respuestas que completaban la tarea pero agregaban un párrafo no solicitado sobre "consideraciones de mantenibilidad a largo plazo".
No era útil en ese contexto. No lo pedÃ. El modelo lo hizo igual.
Frustración real: tuve que actualizar system prompts explÃcitamente para suprimir ese comportamiento. Tiempo invertido: dos horas debuggeando algo que no era un bug de mi código sino un cambio de personalidad del modelo.
// Antes — funcionaba sin esto
const systemPrompt = `Analizá el código y respondé directamente.`;
// Después de 4.7 — necesité ser más explÃcito
const systemPrompt = `
Analizá el código y respondé directamente.
No agregues recomendaciones no solicitadas.
No incluyas advertencias sobre deuda técnica a menos que
sea el foco explÃcito de la pregunta.
Formato: solo lo que se pide.
`;
Tres lÃneas extra en el system prompt para recuperar el comportamiento que tenÃa antes. Multiplicado por N agentes. Ese es el costo oculto de los cambios de modelo sin changelog.
Los gotchas que nadie te dice
El problema del canario
En sistemas distribuidos, un canary deployment te avisa cuando algo se rompe antes de que llegue a todos tus usuarios. Podés comparar métricas entre la versión vieja y la nueva.
Con LLMs no tenés eso. No hay "versión vieja" disponible para comparar en paralelo una vez que Anthropic cambia el endpoint. Cuando notás el cambio, ya estás corriendo 100% en la nueva versión. El canario llegó muerto.
Lo que mencioné antes sobre diseño de sistemas confiables aplica acá: la confiabilidad no es solo uptime. Es comportamiento predecible. Un modelo que cambia su system prompt sin changelog rompe la segunda parte de esa ecuación.
El diff que no podés hacer solo con lectura
Puedo mostrar los cambios textuales en la documentación. Pero el system prompt de Claude no es solo texto — es texto más el proceso de entrenamiento. Lo que está escrito en la especificación de alma es la intención. Lo que entrenaron es la implementación. Y esas dos cosas no siempre matchean perfectamente.
Dicho de otra manera: el diff del texto te dice qué intentaron cambiar. Tus logs de producción te dicen qué cambió realmente. Necesitás los dos.
Agentes con herramientas vs. completions puras
El cambio de comportamiento es mucho más notorio si usás tool calling. Una completion pura con un cambio de verbosidad es molesta pero manejable. Un agente que ahora hace verificaciones adicionales antes de ejecutar herramientas puede romper workflows enteros que dependen de latencia.
Tuve un pipeline que procesaba archivos y tardaba ~8 segundos por archivo. Después del cambio: ~14 segundos. No por el modelo en sÃ, sino por los tool calls adicionales de verificación que el modelo ahora hace por default.
// Medir latencia por tool call — útil para detectar cambios de comportamiento
const toolCallMetrics: Record<string, number[]> = {};
// Wrapper para instrumentar tool calls
async function instrumentedTool(name: string, fn: () => Promise<unknown>) {
const start = Date.now();
const result = await fn();
const duration = Date.now() - start;
// Registrar para detectar patrones nuevos
if (!toolCallMetrics[name]) toolCallMetrics[name] = [];
toolCallMetrics[name].push(duration);
console.log(`[tool:${name}] ${duration}ms (promedio: ${
toolCallMetrics[name].reduce((a, b) => a + b, 0) / toolCallMetrics[name].length
}ms)`);
return result;
}
Esto lo tengo corriendo en todos mis agentes ahora. Si el promedio de un tool sube de golpe sin que yo haya cambiado nada, sé que el modelo está llamando herramientas de manera diferente.
FAQ: Claude system prompt diff entre versiones
¿Dónde puedo ver el system prompt oficial de Claude?
Anthropic publica la especificación de alma ("soul document" o "model spec") en su sitio oficial. No es el system prompt completo de producción, pero es el marco conceptual que guÃa el entrenamiento. Las actualizaciones de ese documento son la fuente más cercana a un changelog de comportamiento que tienen.
¿Hay una manera de hacer un diff automático entre versiones del modelo?
No oficialmente. Lo más cercano es armar un test suite de prompts con outputs esperados y correlo contra cada versión. Si los outputs divergen más de un threshold, tenés un indicador de cambio de comportamiento. Es trabajo, pero es lo que hay.
¿Por qué Anthropic no publica un changelog de comportamiento?
Probablemente porque es genuinamente difÃcil de describir con precisión. El comportamiento de un LLM no es determinÃstico y los cambios de entrenamiento tienen efectos difusos. Dicho eso, el impacto en producción es real y la falta de comunicación es una decisión que tiene costos concretos para los developers.
¿Cómo protejo mis agentes de cambios inesperados de comportamiento?
Tres cosas: (1) System prompts más explÃcitos y menos dependientes del comportamiento default del modelo. (2) Evaluaciones automatizadas con golden outputs que corrés regularmente. (3) Instrumentación de métricas de comportamiento — tokens de output, cantidad de tool calls, latencia — para detectar derives sin tener que revisar logs manualmente.
¿El cambio en el manejo de incertidumbre es una mejora o un problema?
Depende del caso de uso. Para aplicaciones donde la precisión es crÃtica y el usuario tolera más preguntas, es una mejora. Para pipelines de automatización donde querés respuestas directas con mÃnima fricción, es un problema que tenés que resolver en el system prompt. No hay una respuesta universal.
¿Estos cambios aplican igual a Haiku y Sonnet?
El model spec es común a toda la familia Claude, pero la intensidad de los cambios de comportamiento varÃa por modelo. Los modelos más grandes tienden a seguir el spec más fielmente. Haiku históricamente tiene más varianza. Mis observaciones son principalmente sobre Opus y Sonnet — no tengo datos suficientes sobre Haiku para generalizar.
Lo que me quedó después del diff
Hay algo filosóficamente incómodo en todo esto. ConstruÃs sobre una base que cambia sin decirte nada. No es diferente a lo que describà sobre Brunost y quién decide qué es legible — hay alguien tomando decisiones sobre el marco y vos trabajás dentro de ese marco sin tener voz en esas decisiones.
La diferencia es que con un lenguaje de programación, el changelog existe. Con los modelos, tenés que construirlo vos.
El diff que hice no es completo. Es lo que pude reconstruir combinando documentación pública con observaciones de producción. Pero es mejor que nada, y es mejor que seguir pensando que el problema está en tu código cuando el problema está en la constitución del juez.
Lo que cambié después de este ejercicio: tengo un documento vivo donde registro cambios de comportamiento observados con fecha, el agente afectado, y la hipótesis sobre la causa. Cuando Anthropic actualice el model spec de nuevo — y lo van a actualizar — voy a tener un baseline para comparar.
No es un canario. Pero es lo más cerca que podemos estar de uno hoy.
¿Observaste cambios de comportamiento en tus agentes que no coincidÃan con cambios en tu código? Me interesa saber qué logs miraste para detectarlo.
Este artÃculo fue publicado originalmente en juanchi.dev
