Claude system prompt diff: lo que cambió entre Opus 4.6 y 4.7 (y yo lo estaba viendo sin saberlo)

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í:

En 4.7, el énfasis se movió:

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:

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:

Ahora tiende más a:

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.