Anthropic revirtió su posición sobre Claude CLI: la semana pasada era un gris, hoy es verde. Mi flujo de trabajo no cambió.

Anthropic acaba de confirmar que el uso de Claude vía CLI —el patrón que herramientas como OpenClaw popularizaron— está permitido. La comunidad lo celebra. Yo también lo uso. Pero estoy mirando esto desde un lugar bastante particular: mi flujo de trabajo no cambió ni una línea. Lo que cambió fue la posición oficial de Anthropic. Y eso, cuanto más lo pienso, más me molesta.

No porque hayan dado luz verde. Sino porque durante semanas estuve operando en una zona gris que nunca debería haber existido. Y porque el giro llegó sin comunicación proactiva, sin changelog, sin un email a los developers que ya estaban construyendo sobre esa base.

Son 32 años mirando cómo las plataformas se relacionan con sus ecosistemas. Esto tiene patrones conocidos.

Claude CLI usage policy reversal: qué cambió exactamente y qué no

El contexto rápido: Claude CLI es la práctica de acceder a Claude —el modelo de Anthropic— a través de interfaces de línea de comandos, scripts, o herramientas que automatizan la interacción sin pasar necesariamente por la API oficial de forma "convencional". OpenClaw fue una de las herramientas que popularizó este patrón: básicamente un wrapper que te dejaba usar Claude desde tu terminal como si fuera cualquier otra herramienta Unix.

Durante un período, los términos de uso de Anthropic eran ambiguos sobre si esto estaba permitido. La interpretación conservadora decía que no. La interpretación práctica —la que usaba el 90% de los developers que conozco— decía que sí, con ciertos límites razonables.

Ahora Anthropic dijo explícitamente: está bien.

Lo que cambió: el texto oficial. Lo que no cambió: lo que yo estaba haciendo.

Y ahí está el problema.

# Lo que yo tenía ANTES del anuncio
# (y sigo teniendo DESPUÉS, sin cambiar nada)

#!/bin/bash
# Script para procesar código con Claude via CLI
# Esto vivía en zona gris. Hoy vive en zona verde.
# Mi código no sabe la diferencia.

export ANTHROPIC_API_KEY="$CLAUDE_API_KEY"

claude_review() {
  local archivo="$1"
  local contexto="$2"
  
  # Le mando el archivo a Claude para review técnico
  cat "$archivo" | claude --system "Sos un arquitecto de software revisando código" \
    --message "Revisá este código y decime qué mejorarías: $contexto"
}

# Uso real en mi pipeline de desarrollo
claude_review "src/api/auth.ts" "enfocate en seguridad y edge cases"

Este script existía antes. Existe ahora. La diferencia está en si Anthropic aprueba oficialmente lo que hago con él. Y eso, cuando lo escribo así, suena absurdo. Pero es exactamente lo que pasó.

El problema real no es la reversión — es la arquitectura de la relación

Mirá, entiendo que las políticas evolucionan. Llevo tres décadas viendo esto. Cuando empecé a trabajar con hosting Linux a los 19 años, las reglas de uso aceptable de los proveedores cambiaban cada tanto y nadie se escandalizaba demasiado. Era parte del juego.

Pero hay una diferencia fundamental entre 2004 y 2026: la profundidad de la integración.

Hoy no estoy usando Claude para mandarte un email. Estoy construyendo sistemas enteros donde Claude es una pieza estructural. Tengo agentes que pasan tests, tengo pipelines de review, tengo workflows de generación de código que corren en producción. Cuando Anthropic reescribe sus términos —en cualquier dirección— me está tocando la arquitectura. Aunque no lo sepa.

Lo escribí hace poco en el contexto de la brecha de Vercel y el modelo de amenazas tercerizado: el riesgo de construir sobre infraestructura de terceros no es solo técnico. Es también contractual, legal, y de continuidad. Hoy sumamos: es también semántico. Las reglas que gobiernan lo que podés hacer con una herramienta pueden cambiar mientras dormís.

Anthropics es más transparent que la mayoría. Ya lo vi cuando analizé el diff entre los system prompts de Claude Opus 4.6 y 4.7 — hay cambios ahí que afectan directamente cómo se comporta el modelo en producción, y ninguno de nosotros recibió un email. Esta vez el cambio fue a favor de los developers. La próxima vez puede no serlo.

// El problema de construir sobre políticas que no controlás
// Esto no es código funcional — es una metáfora de arquitectura

interface PoliticaProveedor {
  permiteCLI: boolean;           // Cambió la semana pasada
  permiteAutomatizacion: boolean; // ¿Va a cambiar la próxima?
  definicionDeAbuso: string;      // Ambigua hasta que no lo es
  fechaUltimaActualizacion: Date; // Rara vez te avisan
}

// Tu sistema asume que esto es estable
// Tu sistema está equivocado
const construirSistema = (politica: PoliticaProveedor) => {
  // Toda tu arquitectura de agentes depende de esto
  // Y no tenés control sobre politica
  return new SistemaDeAgentes(politica);
};

// La solución no es no construir
// La solución es construir con capas de abstracción
// que te permitan cambiar el proveedor sin reescribir todo
interface AdaptadorModelo {
  completar(prompt: string): Promise<string>;
  // No le importa si es Claude, GPT, Gemini, o Llama local
  // No le importa si es via API, CLI, o SDK
}

Esto conecta directo con algo que estuve pensando desde que analicé cómo Emacs resuelve el problema de confianza en herramientas: las herramientas que sobreviven décadas son las que te dan control real sobre tu entorno. Las que no, te hacen dependiente de decisiones que no tomaste.

Los gotchas que nadie dice en voz alta

Cuando Anthropic dice "está permitido", hay algunas cosas que conviene tener claras antes de festejar demasiado:

"Permitido" no es lo mismo que "garantizado". Los términos pueden cambiar nuevamente. Construí tus sistemas asumiendo que van a cambiar. No como paranoia, sino como arquitectura honesta.

La zona gris no desapareció, se movió. Ahora la pregunta es qué cuenta como uso "razonable" vía CLI y qué empieza a parecerse a scraping agresivo o abuso. Esos límites siguen siendo ambiguos.

Rate limits y costos son el nuevo campo de batalla. Una cosa es que esté permitido, otra es que sea económicamente viable a escala. Tuve que aprender esto a los golpes con la API key que casi se me va a las nubes un domingo a la noche porque un script en loop no tenía backoff.

# Backoff exponencial — aprenderlo caro o aprenderlo gratis
# Yo lo aprendí caro

claude_con_retry() {
  local intento=0
  local max_intentos=5
  local espera=1
  
  while [ $intento -lt $max_intentos ]; do
    # Intentamos el llamado a Claude
    resultado=$(claude "$@" 2>&1)
    codigo=$?
    
    if [ $codigo -eq 0 ]; then
      echo "$resultado"
      return 0
    fi
    
    # Si es rate limit, esperamos con backoff exponencial
    if echo "$resultado" | grep -q "rate_limit"; then
      echo "Rate limit alcanzado. Esperando ${espera}s..." >&2
      sleep $espera
      espera=$((espera * 2))  # Duplicamos la espera
      intento=$((intento + 1))
    else
      # Error que no es rate limit — no reintentamos
      echo "Error: $resultado" >&2
      return 1
    fi
  done
  
  echo "Máximos reintentos alcanzados" >&2
  return 1
}

La identidad de tu agente importa más de lo que pensás. Con el CLI, el contexto de "quién está llamando" se vuelve más opaco. Estuve pensando en esto desde que escribí sobre los CAPTCHAs invertidos para agentes IA: el problema de identidad no desaparece porque Anthropic diga que está bien que uses CLI. El problema de identidad es estructural.

El anonimato que te da el CLI tiene un costo de debugging brutal. Cuando algo falla en un llamado a Claude vía SDK oficial, tenés logs, tenés request IDs, tenés estructura. Cuando algo falla en un script bash que wrappea un CLI, tenés un string en stderr y suerte.

FAQ: Claude CLI usage policy y lo que realmente te importa saber

¿Qué exactamente revirtió Anthropic sobre el uso de Claude vía CLI? Anthropics aclaró que el patrón de uso popularizado por herramientas como OpenClaw —acceder a Claude mediante interfaces de línea de comandos, scripts, y wrappers que automatizan la interacción— está permitido dentro de sus términos de uso. Anteriormente, los términos eran lo suficientemente ambiguos como para generar incertidumbre legítima sobre si este tipo de uso estaba autorizado.

¿Puedo usar cualquier herramienta CLI con Claude sin restricciones? No exactamente. "Permitido" viene con condiciones implícitas y explícitas: no podés usarlo para generar spam, no podés hacer scraping agresivo de otros servicios via Claude, y los rate limits del plan que tengas siguen aplicando. La reversión abre la puerta, no la tira abajo.

¿Qué pasaría si Anthropic vuelve a cambiar su posición? Esa es exactamente la pregunta correcta. Si construiste tu flujo de trabajo de forma que Claude CLI sea una dependencia directa y no abstraída, un cambio de política te obliga a reescribir. Si construiste con una capa de abstracción (un adaptador que puede apuntar a Claude, a GPT, a un modelo local), el cambio de política se convierte en un problema de configuración, no de arquitectura.

¿Es mejor usar el SDK oficial de Anthropic que el CLI para producción? Para producción: sí, casi siempre. El SDK te da tipado, manejo de errores estructurado, logging, y una interfaz que no va a cambiar silenciosamente cuando actualices una versión de CLI. Para experimentación y desarrollo local: el CLI es fantástico. La distinción importa.

¿Cómo esto afecta los datos que mando a Claude vía CLI? Igual que cualquier otro método de acceso: Anthropic tiene acceso a los prompts que mandás para safety monitoring, a menos que tenés un acuerdo específico de enterprise que lo limite. Esto no cambió con la reversión de política. Si mandás código propietario o datos sensibles, revisá los términos de privacidad independientemente de si usás CLI, SDK, o la interfaz web. Hablé de algo similar cuando salió el escándalo de Notion filtrando emails: la superficie de datos expuesta por usar herramientas de terceros es siempre más grande de lo que creemos.

¿Esto significa que Anthropic está "del lado" de los developers? Anthropics claramente quiere un ecosistema de developers activo — tienen demasiado incentivo económico para no quererlo. Pero "del lado" implica una alineación de intereses que es más compleja. Están construyendo un negocio con inversores, con consideraciones regulatorias, con presiones de seguridad legítimas. Pueden estar genuinamente a favor del uso creativo de sus APIs y al mismo tiempo tomar decisiones que te afecten sin consultarte. Ambas cosas son verdad.

Lo que aprendí mirando esto desde 1994

Cuando tenía 5 años y mi viejo me mostró la Amiga, las reglas sobre qué podías hacer con el hardware eran físicas. O el procesador lo soportaba o no. No había un abogado en Commodore decidiendo si mi caso de uso era conforme a los términos.

Hoy construyo sobre modelos de lenguaje cuyos términos de uso son documentos vivos, interpretados por equipos legales que a veces no tienen contexto técnico de lo que los developers estamos haciendo en la práctica. Y esos documentos pueden cambiar más rápido que mis deploys.

La reversión de Anthropic sobre Claude CLI usage es buena noticia. Genuinamente. Pero me deja con una convicción más fuerte que antes: la abstracción no es un lujo de arquitectura, es una necesidad de supervivencia. Si tu sistema solo funciona porque Anthropic dice hoy que está bien, tu sistema tiene un problema de diseño que ningún comunicado de política puede resolver.

Constituí en capa de abstracción. Documentá tus dependencias de política igual que documentás tus dependencias de código. Y mantené un ojo en los changelogs —aunque Anthropic no te los mande por email.

El flujo de trabajo no cambió. Sigue sin cambiar. Pero el próximo cambio de política me va a encontrar un poco más preparado para cuando no sea en mi favor.