Claude Opus 4.7 y el principio del fin de la abundancia en IA

Pasé un mes entero sin respuesta de Anthropic cuando se cayó mi acceso a la API. No fue un problema de billing. No fue un bug de mi lado. Fue silencio. Treinta días redirigiendo flujos, reescribiendo prompts para otros modelos, explicándole a mi equipo por qué el sistema que habíamos construido sobre Claude dejó de funcionar de un día para el otro. Lo cuento porque hoy, con Opus 4.7 trendeando al mismo tiempo que un artículo sobre 'el inicio de la escasez en IA', me cayó la ficha de que ese mes no fue un accidente. Fue un síntoma.

La escasez en IA modelos frontier costo: el régimen que estamos dejando atrás

Desde 2022 hasta hace muy poco vivimos algo que, en retrospectiva, fue extraordinario: cada tres meses un modelo nuevo era simultáneamente más inteligente y más barato. GPT-4 salió caro. Después vino GPT-4 Turbo, más barato. Claude 2, Claude 3, Gemini. La tendencia era tan consistente que se volvió un axioma de planning: si esperás seis meses, el mismo resultado te cuesta la mitad.

Eso nos enseñó a construir de una manera muy específica. Apostaste fuerte en un proveedor frontier porque el lock-in parecía un riesgo manejable frente a la capacidad diferencial. Optimizaste para calidad primero, costo después, porque el costo iba a bajar solo. Diseñaste arquitecturas donde el LLM era el centro, no la periferia, porque era lo suficientemente barato para justificarlo.

El problema es que ese régimen terminó, y la mayoría de los sistemas que construimos en ese período asumen implícitamente que va a continuar.

Opus 4.7 es un ejemplo concreto de hacia dónde vamos. Es un modelo extraordinariamente capaz para tareas de razonamiento largo y trabajo agéntico. También es extraordinariamente caro. Anthropic está apostando a que existe un segmento de mercado dispuesto a pagar una prima significativa por la frontera real de capacidad. Y probablemente tengan razón. Pero eso implica algo que no estábamos modelando: que la frontera y el precio accesible van a divergir.

Qué cambia en la arquitectura cuando el costo deja de bajar solo

Cuando estaba reconstruyendo mis flujos durante ese mes sin Anthropic, me di cuenta de algo incómodo: no tenía una capa de abstracción real entre mi lógica de negocio y el proveedor. Tenía comentarios en el código que decían "acá va el modelo", pero en práctica todo estaba hardcodeado alrededor de las quirks específicas de Claude.

Esto es lo que reconstruí después, y lo que recomendaría a cualquiera que esté en esa situación hoy:

// Capa de abstracción para proveedores LLM
// La idea es que el resto de tu código no sepa con quién habla

interface LLMProvider {
  nombre: string;
  // Tier de capacidad: 'frontier' | 'mid' | 'local'
  // Esto importa para routing por costo
  tier: 'frontier' | 'mid' | 'local';
  costoInputPorMillon: number; // USD
  costoOutputPorMillon: number; // USD
  completar(params: CompletionParams): Promise<CompletionResult>;
}

// Configuración de providers disponibles
// Nunca dependas de que UNO esté disponible
const providers: Record<string, LLMProvider> = {
  claude_opus: {
    nombre: 'claude-opus-4-7',
    tier: 'frontier',
    costoInputPorMillon: 15, // Aproximado — verificar en la doc
    costoOutputPorMillon: 75,
    completar: (p) => anthropicClient.completar(p)
  },
  claude_sonnet: {
    nombre: 'claude-sonnet-4-5',
    tier: 'mid',
    costoInputPorMillon: 3,
    costoOutputPorMillon: 15,
    completar: (p) => anthropicClient.completar(p)
  },
  gemini_flash: {
    nombre: 'gemini-2-flash',
    tier: 'mid',
    costoInputPorMillon: 0.15,
    costoOutputPorMillon: 0.60,
    completar: (p) => geminiClient.completar(p)
  }
};

// Router que elige proveedor según contexto
// Si necesitás capacidad frontier, pagás frontier
// Si no, no la uses
function elegirProvider(tarea: TipoTarea, presupuesto: 'bajo' | 'normal' | 'sin_limite'): LLMProvider {
  // Tareas que genuinamente necesitan frontier
  const necesitaFrontier = [
    'razonamiento_multi_paso',
    'codigo_critico_produccion',
    'analisis_contractual'
  ];

  if (necesitaFrontier.includes(tarea) && presupuesto !== 'bajo') {
    return providers.claude_opus;
  }

  // La mayoría de las tareas no necesitan frontier
  // Y en un régimen de escasez, esa diferencia importa mucho
  if (presupuesto === 'bajo') {
    return providers.gemini_flash;
  }

  return providers.claude_sonnet;
}

Esto parece obvio. Pero si revisás tu código de hace 18 meses, probablemente el modelo está hardcodeado en tres lugares distintos y la lógica de fallback no existe. Yo también lo hice así. Era razonable cuando asumías que el costo iba a bajar y la disponibilidad iba a mejorar indefinidamente.

El problema de la opacidad en el uso real de tokens tampoco desaparece en un régimen de escasez — al contrario, se amplifica. Cuando el costo baja, no importa mucho si tus herramientas usan más créditos de los que te informan. Cuando el costo sube o se estabiliza alto, cada token no reportado empieza a doler.

Los errores que cometemos cuando asumimos abundancia infinita

Hay un patrón específico que veo mucho y que se vuelve muy caro en un régimen de escasez:

El agente que hace todo con frontier. Flujos donde absolutamente cada paso usa el modelo más capaz disponible, independientemente de si la tarea lo justifica. Clasificar un email en tres categorías no necesita Opus. Extraer una fecha de un texto no necesita Opus. Pero cuando el modelo era barato y la diferencia de calidad era visible, nadie quería optimizar.

La falta de fallback real. No me refiero a retry logic. Me refiero a arquitecturas donde si el proveedor principal no está disponible, el sistema directamente no funciona. Eso era un riesgo aceptable cuando había un proveedor dominante con 99.9% de uptime. Es un riesgo inaceptable cuando empezás a ver restricciones de acceso, rate limits más agresivos, o diferenciación de precio que te excluye del tier superior.

El lock-in de prompts. Esto es más sutil. Los prompts que funcionan bien con Claude tienen características específicas que no se traducen uno a uno a Gemini o GPT-4o. Si tu sistema tiene mil prompts optimizados para un solo proveedor, migrar tiene un costo real de ingeniería que nadie presupuestó. El mismo problema aparece cuando tratás de curar recursos técnicos sin un sistema que se auto-regule: la deuda crece silenciosamente hasta que de repente no podés moverla.

Asumir que el precio de los modelos locales no importa. El argumento de que los modelos on-device son para casos de uso específicos y de nicho se sostiene menos cada mes. Lo que probé con Gemma 4 en iPhone no era producción-ready para todo, pero hay tareas donde ya es suficientemente bueno y el costo marginal es literalmente cero. En un régimen donde frontier cuesta más, esa brecha importa.

Lo que cambia en cómo tomás decisiones técnicas

Hay algo más profundo acá que la arquitectura. Es cómo evaluás riesgo.

Durante el régimen de abundancia, la pregunta era: ¿qué modelo me da el mejor resultado hoy? La respuesta era casi siempre el más nuevo, y el costo de equivocarte era bajo porque el precio bajaba igual.

En un régimen de escasez, la pregunta es: ¿qué modelo puedo sostener en producción en 18 meses? Eso incluye el costo, sí, pero también la disponibilidad, el acceso al tier, y la estabilidad del proveedor. Y acá aparece algo que no estábamos modelando: la dependencia de un solo proveedor frontier no es solo un riesgo técnico. Es una apuesta implícita sobre quién va a poder pagar lo que viene.

Si tu empresa tiene presupuesto de enterprise y relación directa con Anthropic o Google, la apuesta es diferente a si sos un dev indie o una startup sin acuerdo enterprise. Pero en ambos casos, la apuesta es real, y en el régimen de abundancia la ignorábamos porque no costaba nada.

Hay otro vector de riesgo que en este contexto se vuelve más urgente: los datos. Cuando dependés de un proveedor frontier y ese proveedor cambia sus términos, sus precios, o su política de retención de datos, no tenés mucho leverage. Eso tiene implicancias legales concretas que en un régimen donde todos usamos el mismo tier de API tendíamos a ignorar. Y el compliance por sí solo no te salva: necesitás diseño real.

FAQ: escasez en IA, modelos frontier y costo

¿Opus 4.7 realmente es significativamente más caro que versiones anteriores? Sí, y la diferencia no es marginal. El patrón que estamos viendo es que Anthropic está diferenciando más agresivamente entre tiers: Haiku para volumen alto y bajo costo, Sonnet para el caso de uso general, Opus para capacidad máxima con precio acorde. Lo nuevo es que la brecha entre Sonnet y Opus en precio es más grande que en generaciones anteriores, mientras que la brecha en capacidad también creció. Antes la decisión era fácil porque la diferencia de precio era chica. Ahora tenés que justificar genuinamente por qué necesitás frontier.

¿Qué significa 'régimen de escasez' en este contexto? ¿Los modelos van a dejar de existir? No, los modelos no van a desaparecer. Lo que cambia es el patrón de precio-capacidad. Durante el régimen de abundancia, cada generación era más barata y más capaz simultáneamente. Lo que algunos análisis están señalando es que esa curva se está aplanando: seguirá habiendo mejoras de capacidad en frontier, pero ya no necesariamente van a venir con reducción de precio. Y en algunos casos, como Opus 4.7, la apuesta explícita es lo contrario: más capacidad, más caro, mercado más chico.

¿Tiene sentido migrar a modelos open source o locales como estrategia de hedge? Depende de qué parte de tu stack. Para tareas de clasificación, extracción de información estructurada, generación de texto corto con formato definido — sí, los modelos open source modernos son perfectamente viables y el costo es dramáticamente menor. Para razonamiento complejo, código crítico, o tareas donde la calidad del output impacta directamente en el usuario final — frontier sigue siendo la opción. La estrategia más robusta no es migrar todo, es tener capas claras en tu arquitectura que te permitan routear por tipo de tarea.

¿Cómo afecta esto a las startups que construyeron sobre un solo proveedor frontier? Es el riesgo más concreto y menos discutido. Si construiste tu producto asumiendo el precio actual de un proveedor frontier y ese precio sube, o si el acceso al tier que usás cambia, tu unit economics se rompe sin que hayas hecho nada malo técnicamente. La recomendación es evaluar qué porcentaje de tus llamadas a LLM genuinamente necesitan capacidad frontier y empezar a migrar las que no. No como ejercicio teórico — con métricas reales de calidad para tu caso de uso específico.

¿El auge de los agentes de IA hace que este problema sea peor? Mucho peor. Un agente que hace diez llamadas para completar una tarea consume diez veces el costo de una llamada única. Si cada una de esas llamadas usa el tier más caro, el costo se multiplica rápidamente. La mayoría de los frameworks de agentes que vi no tienen routing inteligente por costo — asumen que vas a usar el mismo modelo para todos los pasos. En un régimen donde frontier es caro, eso no escala. Los agentes bien diseñados para el nuevo régimen van a necesitar routing explícito: qué pasos justifican frontier, cuáles no.

¿Vale la pena migrar ahora o esperar a ver cómo evoluciona el mercado? No esperaría. No porque sea urgente cambiar todo hoy, sino porque introducir la capa de abstracción no cuesta mucho si lo hacés de forma incremental, y te da optionalidad real. Si el mercado evoluciona hacia más abundancia, no perdiste nada. Si evoluciona hacia más escasez y diferenciación, ya tenés la infraestructura para moverte rápido. El riesgo asimétrico está del lado de no hacerlo.

Qué haría diferente hoy

El mes que estuve sin Anthropic me costó tiempo, fricción, y alguna conversación incómoda con usuarios. No fue un desastre, pero fue más caro de lo que hubiera sido si hubiera diseñado pensando en que la disponibilidad no es garantizada y el precio no es estático.

Lo que haría diferente es simple: cada vez que tomo una decisión de arquitectura sobre LLMs, la pregunta que me hago es ¿qué pasa si este proveedor duplica el precio o se cae por un mes? Si la respuesta es el sistema no funciona, hay trabajo por hacer. Si la respuesta es routeamos a otro proveedor con degradación controlada de calidad, eso es un diseño que sobrevive al régimen que viene.

Opus 4.7 probablemente sea un modelo extraordinario. Quizás lo use para casos específicos donde frontier genuinamente importa. Pero lo que me llevé del día de hoy no es el benchmark de capacidad — es el recordatorio de que el período en que podías construir como si los recursos fueran infinitos y los precios bajaran solos se está cerrando. Y los sistemas que se construyeron sin esa consideración van a tener que revisarse.