El mes que Anthropic no respondió: billing, confianza y el costo oculto de depender de APIs de IA

Hay una creencia instalada en la comunidad dev sobre las APIs de IA que está, con todo respeto, bastante incompleta: que son infraestructura confiable. Que podés construir sobre ellas como construís sobre AWS S3 o Stripe. Que si algo sale mal, hay alguien del otro lado que te responde.

No necesariamente.

Un thread de Hacker News con 365 puntos —uno de esos que aparece un martes a la mañana y te arruina la semana— documentó en detalle lo que le pasó a alguien con Anthropic: un mes de tickets sin respuesta, billing que seguía corriendo, y un silencio institucional que no se condice con lo que cuesta usar esas APIs. Leí ese thread tres veces. No porque me sorprendiera. Sino porque yo ya había vivido algo parecido.

Anthropic billing support AI vendor lock-in: el problema que nadie nombra

Viernes. 11pm. Tenía un cliente con un sistema en producción que usaba una API de IA para procesar formularios —nada crítico en teoría, pero crítico en la práctica porque era el flujo principal del negocio. El sistema dejó de funcionar. Sin error explícito en los logs. Sin notificación por mail. Sin banner en el status page.

Silencio.

// Lo que veía en los logs era esto:
// { status: 200, body: { error: null, result: null } }
// Respuesta 200 con body vacío. Elegante manera de morir.

async function procesarFormulario(datos: FormData) {
  const respuesta = await clienteIA.completar({
    modelo: 'el-modelo-de-turno',
    prompt: construirPrompt(datos),
  });

  // El problema: no había validación de respuesta vacía
  // Asumí que si no había error, había resultado
  // Asumí mal
  return respuesta.resultado; // undefined en silencio
}

Passé dos horas debuggeando antes de darme cuenta de que el problema no era mi código. Era la API. Habían hecho un cambio en el formato de respuesta —sin versioning explícito, sin aviso— y mi código simplemente recibía nulls con status 200.

Abrí un ticket de soporte. Esperé.

La respuesta llegó 72 horas después. Un viernes a las 11pm no es un horario donde las empresas de IA tienen guardia. Esto no es una crítica a las personas —es una crítica al modelo de soporte que se vende implícitamente cuando cobrás por llamada de API a precios que no son baratos.

El problema técnico real: construir sobre arena con fundamentos de granito

El issue no es que las APIs fallen. Todo falla. El issue es la asimetría de información y la asimetría de poder.

Cuando construís sobre Stripe, tenés:

• Versionado explícito de API (/v1/, /v2/)
• Deprecation notices con meses de anticipación
• Webhooks con firma verificable
• SLAs documentados
• Soporte con tiempos de respuesta garantizados según tier

Cuando construís sobre APIs de IA hoy, tenás en el mejor caso:

• Versionado de modelo (que no es lo mismo que versionado de API)
• Status pages que a veces reflejan la realidad
• Rate limits que cambian sin mucho aviso
• Billing que corre aunque el servicio esté degradado
• Soporte cuya calidad depende literalmente de cuánto gastás por mes

// Lo que deberías hacer siempre — y que yo no hice esa noche:

interface RespuestaIA {
  resultado: string | null;
  metadata: Record<string, unknown>;
}

function validarRespuestaIA(respuesta: unknown): RespuestaIA {
  // Nunca confíes en el shape de respuesta de una API externa
  // Especialmente de IA donde el schema evoluciona rápido
  if (!respuesta || typeof respuesta !== 'object') {
    throw new Error('Respuesta inválida: no es objeto');
  }

  const r = respuesta as Record<string, unknown>;

  if (!r.resultado && r.resultado !== '') {
    // Loguear con contexto suficiente para debuggear a las 11pm
    console.error('[IA] Respuesta vacía inesperada', {
      timestamp: new Date().toISOString(),
      shape: Object.keys(r),
    });
    throw new Error('Respuesta de IA sin resultado');
  }

  return r as RespuestaIA;
}

// Circuit breaker básico — no es opcional, es infraestructura
class CircuitBreakerIA {
  private fallos = 0;
  private readonly umbralFallos = 3;
  private estado: 'cerrado' | 'abierto' | 'semiabierto' = 'cerrado';
  private ultimoFallo?: Date;

  async ejecutar<T>(fn: () => Promise<T>): Promise<T> {
    if (this.estado === 'abierto') {
      const tiempoEspera = 30_000; // 30 segundos
      const tiempoTranscurrido = Date.now() - (this.ultimoFallo?.getTime() ?? 0);

      if (tiempoTranscurrido < tiempoEspera) {
        // Fallback — no dejés al usuario colgado
        throw new Error('Servicio de IA temporalmente no disponible');
      }

      this.estado = 'semiabierto';
    }

    try {
      const resultado = await fn();
      this.resetear();
      return resultado;
    } catch (error) {
      this.registrarFallo();
      throw error;
    }
  }

  private registrarFallo() {
    this.fallos++;
    this.ultimoFallo = new Date();
    if (this.fallos >= this.umbralFallos) {
      this.estado = 'abierto';
      console.error('[CircuitBreaker] Estado: ABIERTO — demasiados fallos consecutivos');
    }
  }

  private resetear() {
    this.fallos = 0;
    this.estado = 'cerrado';
  }
}

Esto no es sofisticado. Es lo mínimo. Es lo que deberías tener antes de mandar a producción cualquier integración con una API de terceros. Con APIs de IA es más importante todavía porque el modo de fallo silencioso —respuesta vacía con 200— es más común que en APIs más maduras.

Hablo de esto también en el post sobre vibe-coding vs stress-coding: hay una diferencia enorme entre usar IA como herramienta y depender de IA como infraestructura. El primero es potenciarte. El segundo es un contrato que nadie firmó explícitamente.

Los errores que cometés cuando confiás demasiado rápido

1. No modelar el fallback desde el día uno.

Cuando agregás una integración de IA, el happy path es fácil. El 99% del tiempo funciona. El problema es el 1% que ocurre un viernes a las 11pm. ¿Qué hace tu app si la API no responde? ¿Si responde vacío? ¿Si responde con latencia de 30 segundos? Si no tenés respuesta para esas tres preguntas antes de hacer el deploy, no estás listo.

2. Confundir el status page con la realidad.

Los status pages de los vendors de IA son... optimistas. He visto degradación real con status page en verde. Implementá tu propio health check:

// Health check real — no confíes solo en el status page del vendor
async function verificarSaludAPI(): Promise<boolean> {
  try {
    const inicio = Date.now();

    // Llamada de prueba con prompt mínimo y timeout estricto
    const respuesta = await Promise.race([
      clienteIA.completar({
        modelo: 'tu-modelo',
        prompt: 'Respondé solo "ok"',
        maxTokens: 5,
      }),
      new Promise((_, reject) =>
        setTimeout(() => reject(new Error('Timeout')), 5_000)
      ),
    ]);

    const latencia = Date.now() - inicio;

    // Loguear latencia — los cambios de latencia son señal temprana de problemas
    console.info('[HealthCheck] Latencia API IA:', latencia, 'ms');

    return Boolean(respuesta);
  } catch {
    return false;
  }
}

3. No trackear el costo en tiempo real.

El billing de las APIs de IA es por token, y los tokens se acumulan. Si tu app tiene un bug que hace llamadas redundantes, lo descubrís en la factura del mes. Para cuando abrís el ticket, ya gastaste. Implementá alertas de costo antes de que el problema sea billing de varios días sin soporte.

4. Apostar todo a un solo proveedor.

Esto conecta con el trabajo que hago pensando en orquestación. Cuando leí sobre Scion, el testbed de Google para agentes, lo primero que pensé no fue en las capacidades técnicas sino en la pregunta de portabilidad: ¿si cambio de proveedor, cuánto de mi lógica de negocio tengo que reescribir?

La respuesta honesta en la mayoría de los casos: demasiado.

// Abstraer el proveedor desde el principio — lo que debería haber hecho
interface ClienteIA {
  completar(opciones: OpcionesCompletado): Promise<RespuestaIA>;
  calcularCosto(tokens: number): number;
}

// Implementación intercambiable
class ClienteAnthropic implements ClienteIA {
  async completar(opciones: OpcionesCompletado): Promise<RespuestaIA> {
    // implementación específica
  }
  calcularCosto(tokens: number): number { /* ... */ }
}

class ClienteOpenAI implements ClienteIA {
  async completar(opciones: OpcionesCompletado): Promise<RespuestaIA> {
    // implementación específica
  }
  calcularCosto(tokens: number): number { /* ... */ }
}

// Tu lógica de negocio no sabe quién está atrás
class ServicioFormularios {
  constructor(private readonly ia: ClienteIA) {}

  async procesar(datos: FormData) {
    // Esto funciona con cualquier proveedor
    return this.ia.completar({ prompt: construirPrompt(datos) });
  }
}

Es el mismo principio que aplico cuando construyo extensiones de VS Code: la abstracción no es complejidad gratuita, es lo que te permite cambiar las partes que cambian sin romper las que no cambian.

FAQ: Lo que la gente pregunta cuando se quema con APIs de IA

¿Anthropic tiene SLA documentado para sus APIs?

No públicamente, al menos no en los términos en que lo ofrecen otros proveedores de infraestructura como AWS o GCP. Hay compromisos de uptime implícitos pero los términos de soporte dependen del tier de gasto. Si no sabés cuánto tenés que gastar para tener soporte prioritario, probablemente no lo tenés.

¿Es diferente con OpenAI o Google AI?

En general, el problema de soporte es transversal a los vendors de IA. Los más grandes tienen mejor infraestructura de status y más capacidad de soporte, pero la asimetría de poder sigue existiendo: ellos deciden cuándo cambian el modelo, cuándo deprecan una versión, cuándo ajustan los precios. Vos aceptás cuando firmás los ToS.

¿Cómo sabés si tu integración de IA está fallando silenciosamente en producción?

Si no tenés métricas explícitas de: (1) tasa de respuestas vacías, (2) latencia p95, y (3) tasa de errores diferenciada por tipo, no lo sabés. El modo de fallo silencioso —200 con body vacío— no dispara las alertas de error tradicionales. Necesitás validación de schema en la respuesta y métricas de negocio (¿cuántos formularios se procesaron esta hora vs la hora anterior?) para detectarlo.

¿Vale la pena seguir construyendo sobre estas APIs dado el riesgo?

Sí, pero con los ojos abiertos. La pregunta no es si usar APIs de IA sino cómo. La abstracción del proveedor, el circuit breaker, el fallback explícito y el health check propio no son opcionales si estás en producción. Son el costo de entrada real que nadie te dice cuando leés la documentación. Igual que con las métricas de accesibilidad: el número que te muestra el tool y la realidad del usuario son cosas distintas.

¿Cómo estructuro el fallback para no degradar la experiencia de usuario?

Depende del caso de uso, pero el principio es: el usuario nunca debería ver el error interno. Si la IA no responde, ¿podés procesar con una lógica más simple? ¿Podés encolar y procesar después? ¿Podés mostrar un mensaje honesto de "estamos procesando, te avisamos"? Cualquiera de esas opciones es mejor que un 500 genérico o, peor, un resultado silenciosamente vacío.

¿El vendor lock-in de IA es diferente al de otras APIs?

Sí, y en el peor sentido. El lock-in de AWS es técnico pero predecible —migrás los datos y reescribís la infraestructura. El lock-in de IA incluye además el comportamiento del modelo: el mismo prompt puede dar resultados distintos entre proveedores, y tu lógica de negocio a veces está construida alrededor de las idiosincrasias de un modelo específico. Es un lock-in de comportamiento, no solo de API.

Lo que haría diferente (y lo que vos deberías hacer antes del próximo viernes)

Aprobé Análisis II en el cuarto intento. Laburé full time mientras cursaba en la UBA. Llegué a rendir con el traje puesto directo del trabajo. Lo que aprendí de eso no fue solo matemática: aprendí que la cantidad de intentos que necesitás para aprobar algo no dice nada sobre si sos capaz. Dice cuántas veces estás dispuesto a volver.

Con las APIs de IA estamos en el primer intento colectivo. El ecosistema es joven, los contratos de soporte son inmaduros, y los modos de fallo están todavía siendo descubiertos en producción —literalmente en producción de otras personas, un viernes a las 11pm.

Eso no es razón para no construir. Es razón para construir con más cuidado.

Lo que haría diferente:

1. Abstracción del proveedor desde el commit uno — no cuando ya tenés 40 llamadas directas al SDK de Anthropic
2. Circuit breaker y health check propio — el status page del vendor es su versión de la historia, no la tuya
3. Validación estricta de schema en cada respuesta — especialmente si el proveedor no te da garantías de versionado
4. Alertas de costo en tiempo real — antes de que el billing corra por días sin soporte
5. Fallback explícito documentado — si la IA no responde, ¿qué hace el sistema? Si la respuesta es "no sé", no estás listo para producción

Por cierto: la misma atención que ponés en el comportamiento de una API externa la deberías poner en las herramientas que usás día a día. Cuando construí mi extensión de VS Code para certificados SSL, lo hice exactamente porque no quería depender de que alguien más maintuviera una herramienta crítica en mi workflow. El principio es el mismo.

El thread de HN con 365 puntos no es un caso aislado. Es un síntoma. El costo oculto de las APIs de IA no es solo el token price — es el costo de confianza que todavía no terminamos de calcular.

Si estás construyendo algo que importa sobre una de estas APIs, mandame un mensaje. Me interesa saber cómo lo estás resolviendo.

---

Este artículo fue publicado originalmente en juanchi.dev