La API de Claude comienza a soportar CORS, haciendo posibles las aplicaciones del lado del cliente

• Anthropic habilitó soporte de CORS para su API JSON
  • Es decir, ahora se puede llamar directamente al LLM Claude desde el navegador del usuario
• Esta función estaba escondida en el PR "anthropic-sdk-typescript: add support for browser usage"
  • Al revisar más a fondo, los cambios al SDK de TypeScript de Anthropic para ese código muestran la nueva funcionalidad de la API JSON
• Se puede habilitar el soporte de CORS para la API de Anthropic agregando el siguiente encabezado HTTP:
  anthropic-dangerous-direct-browser-access: true
• Al agregar este encabezado, se pueden hacer llamadas directamente a los modelos de Anthropic desde el navegador
• Anthropic había sido reacio a agregar esta función porque, si incluyes la API key en el código del cliente, cualquier usuario que pueda acceder a ese sitio puede robarla y hacer solicitudes por su cuenta
• Aun así, hay algunos casos de uso razonables para esta función
  • Puede servir para herramientas internas de una empresa expuestas a usuarios de confianza
  • O también se puede implementar el patrón "BYOK (Bring Your Own Key)" para que los usuarios proporcionen su propia key y la usen en una app del lado del cliente

Haiku - ejemplo de app del lado del cliente

• La página Haiku, creada como una prueba rápida, es un ejemplo de app del lado del cliente que necesita soporte de CORS
• Es una app sencilla que pide acceso a la webcam, solicita una API key de Anthropic (y la guarda en localStorage del navegador), toma una foto y la convierte en un haiku usando el modelo Haiku
• Antes había que ejecutar un proxy propio en Vercel para agregar soporte de CORS a la API de Anthropic
• Ahora la app fue actualizada para enviar el nuevo encabezado y puede comunicarse directamente con Anthropic sin proxy

fetch("https://api.anthropic.com/v1/messages";, {  
  method: "POST",  
  headers: {  
    "x-api-key": apiKey,  
    "anthropic-version": "2023-06-01",   
    "content-type": "application/json",  
    "anthropic-dangerous-direct-browser-access": "true",  
  },  
  body: JSON.stringify({  
    model: "claude-3-haiku-20240307",  
    max_tokens: 1024,  
    messages: [  
      {  
        role: "user",  
        content: [  
          { type: "text", text: "Return a haiku about how great pelicans are" },  
        ],  
      },  
    ],  
  }),  
})  
  .then((response) => response.json())  
  .then((data) => {  
    const haiku = data.content[0].text;  
    alert(haiku);  
  });  

[xguru]

Comentarios de Hacker News

• Personalmente me gusta crear apps web donde el usuario trae su propia clave

  • Este enfoque combina la comodidad de distribuir un ejecutable con las ventajas del código abierto
  • He desarrollado dos apps web
    • una app de transcripción y traducción en tiempo real que usa entrada de micrófono
    • una app que traduce subtítulos SRT a varios idiomas
  • Dos razones principales para elegir el modelo de "trae tu propia clave"
    • Bajo mantenimiento: ya mantengo mucho software y no quiero mantener proyectos paralelos
    • Bajo costo: puedo distribuir la app sin anuncios y mantener bajos los costos operativos
  • Se pueden crear y compartir herramientas útiles minimizando la carga de mantenimiento y el costo para el usuario

• En situaciones donde el usuario trae su propia clave, no es un problema

  • El trabajo se hace del lado del cliente, y mientras el dispositivo o el sitio web no se vean comprometidos, está bien
  • Sin embargo, si el desarrollador usa claves de producción del lado del cliente, la superficie de ataque puede aumentar
  • Puede que hagan esto por conveniencia y rendimiento, sin considerar la seguridad

• No entiendo por qué no soportan JWT

  • Supabase es un buen ejemplo de acceso seguro del lado del cliente

• Anthropic y todos los proveedores de IA deberían implementar la función "Iniciar sesión con ___"

  • Deberían permitir que los usuarios confíen en sus propios recursos de IA
  • A la mayoría de los usuarios les resulta molesto generar y cargar claves API, y no pueden gestionarlas de forma segura

• Cuando el usuario trae su propia clave, OAuth es una mejor solución

  • Algunos desarrolladores pueden terminar hardcodeando la clave real en el frontend y meterse en problemas
  • OAuth es una solución más segura

• Puede servir para desarrollo interno, pero no para apps orientadas a usuarios