Suscripción de Claude Code vs API: acceso y facturación

Pro o Max son candidatos razonables para una persona que trabaja de forma interactiva, ya usa Claude y quiere Claude Code dentro del cupo del plan. Team o Enterprise encajan mejor en organizaciones que necesitan asientos, facturación centralizada, membresía y políticas administradas. Anthropic Console, Bedrock, Google Cloud o Microsoft Foundry son apropiados cuando el uso debe cobrarse por tokens mediante una identidad de organización o nube e integrarse en un circuito propio de control de costes.

No es una comparación de calidad del modelo: el mismo flujo de programación puede cambiar el pagador, la credencial, las funciones disponibles y dónde se contabiliza el gasto. El cupo de una suscripción no es crédito de API, y una API key en la shell puede tener prioridad sobre el inicio de sesión de la suscripción. Antes del piloto registra en `/status` la credencial activa, pagador, organización, modelo, fuente de políticas y responsable del presupuesto; de lo contrario el equipo puede probar un circuito y pagar otro.

• Una persona, sesiones interactivas y gasto previsible de suscripción → empieza con Pro o Max.
• Equipo, web + Code, asientos y controles de administración → evalúa Team o Enterprise.
• CI, flujos de servicio, IAM de nube o contabilidad granular de tokens → evalúa Console o un proveedor cloud.
• Modo mixto → define prioridad de credenciales y presupuestos separados antes del lanzamiento.

Claude Code admite varias rutas de credenciales. La documentación actual describe credenciales de proveedores cloud, bearer token, `ANTHROPIC_API_KEY`, helpers, tokens OAuth, perfiles de Anthropic e inicio de sesión por suscripción con distinta prioridad. Tener una suscripción activa no garantiza que una sesión concreta de terminal la utilice: una API key de entorno puede interceptar las solicitudes. Guarda un recibo sin secretos con método de login, etiqueta de organización, fuente de credencial, proveedor, modelo y timestamp.

Haz una prueba negativa con una cuenta desechable: entra por la suscripción, verifica `/status`, añade después una credencial de prueba sintética o muy limitada en un entorno controlado y confirma que el operador puede ver el cambio de pagador antes de la primera ejecución material. Nunca copies claves en tickets o logs. Para producción usa vault, identidad de corta duración o IAM del proveedor cuando sea compatible, y prueba la revocación por separado.

En Pro, Max, Team y Enterprise el uso está ligado a los límites del plan y puede compartirse con otras superficies de Claude. En Console o un proveedor cloud, las solicitudes se cobran por consumo de tokens en la organización o cuenta de facturación correspondiente. La estimación local del coste de una sesión es útil para diagnosticar uso de API, pero Anthropic señala Console como fuente autoritativa de facturación; para un usuario de suscripción, esa misma cifra no es la factura de la sesión.

Compara coste por tarea aceptada, no prompts o tokens aislados. Registra tareas terminadas, minutos de revisión, reintentos, comportamiento de caché, cargas de contexto grandes, sesiones paralelas e interrupciones por límites. Una suscripción puede ser mejor para un flujo estable human-in-the-loop; la API, para intensidad variable controlada o chargeback. Ninguna opción gana sin el mismo conjunto de tareas y el coste completo de revisión.

• Recibo de suscripción → nivel, estado del cupo, ventana de reset, configuración de usage credits y artefacto aceptado.
• Recibo de API → proveedor, workspace, uso de tokens, fuente autoritativa de factura y estado del presupuesto.
• Contexto compartido → incluye relecturas del repositorio y cache misses.
• Finalización desconocida → revisa estado de git y side effects antes de reintentar.

Una sesión interactiva de desarrollo y un job de CI sin supervisión tienen riesgos diferentes. En una sesión local de suscripción, una persona puede confirmar una acción, ver un límite y corregir contexto. La ejecución headless necesita autenticación adecuada para máquinas, tiempo máximo, controles de concurrencia, política de red, alcance estrecho de repositorio, checks deterministas y kill switch. No lleves un login personal a un runner compartido solo porque ya está pagado.

Antes de automatizar clasifica la tarea: revisión read-only, propuesta de patch, reparación de tests o acción externa. Cada clase recibe permisos, presupuesto y aprobación separados. Facturar por API o cloud facilita el metering, pero no demuestra una authority segura; una suscripción no impide automatización útil, aunque la elegibilidad y los términos deben comprobarse para el mecanismo concreto. Mantén merge, deploy y operaciones destructivas detrás de un gate independiente.

Team y Enterprise combinan Claude web y Claude Code con membresía de organización y facturación centralizada; Enterprise añade superficies más fuertes de identidad, cumplimiento y políticas administradas. Console ofrece una organización orientada a API, límites de gasto por workspace y roles para Claude Code o desarrollo más amplio. Los proveedores cloud añaden su IAM, regiones, procurement y consolas de costes. Son modelos operativos distintos, no solo formas distintas de pasar una tarjeta.

Construye un RACI: quién invita o elimina developers, quién autoriza modelos, quién fija managed settings, quién ve uso por usuario, quién aprueba usage credits o aumentos de presupuesto y quién investiga credential drift. Prueba joiner, mover y leaver con un usuario sintético. Login SSO, retirada de asiento, revocación de API key, credencial cacheada y acceso al repositorio deben ser evidencias separadas.

Elige 12–20 tareas representativas: bug fix, cambio multiarchivo, generación de tests, explicación del repositorio, investigación de dependencias y rechazo por falta de evidencia. La primera semana ejecútalas en el circuito de suscripción candidato; la segunda, mediante Console o el proveedor cloud elegido con la misma clase de modelo, instrucciones, snapshot del repositorio, permisos y rúbrica de revisión. Antes de cada sesión captura la credencial activa; después guarda diff, checks, resultado aceptado, interrupción y fuente de facturación.

Añade una trampa de crossover: deja a propósito una variable de API de prueba inactiva en la máquina y exige que el operador la detecte antes de ejecutar. Añade evento de límite, expiración de credencial, techo de presupuesto y developer revocado. El piloto solo pasa si la atribución del pagador es reproducible, una tarea crítica termina o falla de forma cerrada, y finanzas puede reconciliar el uso local con el dashboard autoritativo. No uses promedios del vendor como pronóstico para tu equipo.

• Freeze → commit, conjunto de tareas, política, clase de modelo y criterios de aceptación.
• Observe → credencial, pagador, tokens/cupo, tool calls y estado de finalización.
• Review → corrección, regresiones, corrección humana y calidad de evidencia.
• Reconcile → estimación local frente al plan o dashboard de facturación.
• Decide → el circuito más simple que supera los gates de calidad, authority y presupuesto.

Migrar entre suscripción, Console y un proveedor cloud cambia credenciales, responsable de facturación, analytics y a veces superficies de producto disponibles. Crea un manifiesto para settings, CLAUDE.md, servidores MCP, hooks, plugins, selección de modelo, variables de entorno y fuentes de políticas. No exportes secretos: restáuralos desde el vault o IAM de destino. Tras el cambio verifica `/status`, tools permitidas, límite del repositorio, destino de telemetría y una tarea canary.

El rollback restaura la ruta de autenticación aprobada anterior, deshabilita la credencial nueva, detiene jobs sin supervisión y reconcilia el uso pendiente. En un modelo mixto etiqueta el routing de workloads explícitamente: por ejemplo, trabajo interactivo local mediante un seat de organización y CI mediante identidad cloud. Prohíbe fallback silencioso entre pagadores. Hace falta review tras cambios de plan, prioridad de credenciales, disponibilidad de modelos, precio, managed policy o integración de facturación.