API do Claude passa a oferecer suporte a CORS, viabilizando aplicações no lado do cliente

• A Anthropic ativou o suporte a CORS para a API JSON
  • Ou seja, agora é possível chamar diretamente o LLM Claude a partir do navegador do usuário
• Esse recurso está escondido no PR "anthropic-sdk-typescript: add support for browser usage"
  • Investigando mais a fundo, as mudanças no SDK TypeScript da Anthropic para esse código mostram uma nova funcionalidade da API JSON
• É possível ativar o suporte a CORS para a API da Anthropic adicionando o seguinte cabeçalho HTTP:
  anthropic-dangerous-direct-browser-access: true
• Ao adicionar esse cabeçalho, é possível fazer chamadas diretamente aos modelos da Anthropic a partir do navegador
• A Anthropic vinha relutando em adicionar esse recurso porque, se a chave de API for incluída no código do cliente, qualquer pessoa com acesso ao site pode roubá-la e fazer requisições em seu lugar
• Ainda assim, existem alguns casos de uso razoáveis para esse recurso
  • Pode ser adequado para ferramentas internas de empresas expostas a usuários confiáveis
  • Ou também é possível implementar o padrão "BYOK (Bring Your Own Key)", no qual o usuário fornece sua própria chave para uso em um app no lado do cliente

Haiku - exemplo de app no lado do cliente

• A página Haiku, criada de forma simples, é um exemplo de app no lado do cliente que precisa de suporte a CORS
• É um app simples que pede acesso à webcam, solicita a chave de API da Anthropic (armazenando-a no localStorage do navegador), tira uma foto e a transforma em um haicai usando o modelo Haiku
• Antes, era necessário executar um proxy próprio na Vercel para adicionar suporte a CORS à API da Anthropic
• Agora o app foi atualizado para enviar o novo cabeçalho e pode se comunicar diretamente com a Anthropic sem 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]

Opiniões do Hacker News

• Pessoalmente, gosto de criar apps web em que o usuário traz a própria chave

  • Essa abordagem combina a conveniência da distribuição via executável com as vantagens do código aberto
  • Já desenvolvi dois apps web
    • Um app de transcrição e tradução em tempo real usando entrada de microfone
    • Um app que traduz legendas SRT para vários idiomas
  • Dois motivos principais para escolher o modelo de “traga sua própria chave”
    • Baixa manutenção: já mantenho muito software e não quero ter que manter também projetos paralelos
    • Baixo custo: dá para distribuir o app sem anúncios e manter baixos os custos operacionais
  • Dá para criar e compartilhar ferramentas úteis minimizando a carga de manutenção e o custo para o usuário

• Quando o usuário traz a própria chave, isso não chega a ser um problema

  • O processamento acontece no lado do cliente e, a menos que o dispositivo ou o site seja comprometido, tudo bem
  • Porém, se o desenvolvedor usar chaves de produção no lado do cliente, a superfície de ataque pode aumentar
  • Por conveniência e desempenho, pode acabar fazendo isso sem considerar a segurança

• Não entendo por que não oferecem suporte a JWT

  • O Supabase é um bom exemplo de acesso seguro pelo lado do cliente

• A Anthropic e todos os fornecedores de IA deveriam implementar a funcionalidade “Entrar com ___”

  • Isso deveria permitir que os usuários confiassem em usar seus próprios recursos de IA
  • A maioria dos usuários acha trabalhoso gerar e carregar chaves de API, além de não conseguir gerenciá-las com segurança

• Quando o usuário traz a própria chave, OAuth é uma solução melhor

  • Alguns desenvolvedores podem acabar colocando a chave real direto no frontend e se complicar
  • OAuth é uma solução mais segura

• Pode servir para desenvolvimento interno, mas não é adequado para apps voltados ao usuário