Claude API unterstützt jetzt CORS und ermöglicht clientseitige Anwendungen

• Anthropic hat CORS-Unterstützung für seine JSON API aktiviert
  • Das bedeutet, dass Claude LLM jetzt direkt aus dem Browser des Nutzers aufgerufen werden kann
• Diese Funktion ist im PR „anthropic-sdk-typescript: add support for browser usage“ versteckt
  • Beim genaueren Hinsehen zeigen die Änderungen am Anthropic TypeScript SDK für diesen Code neue JSON-API-Funktionen
• Die CORS-Unterstützung für die Anthropic API lässt sich durch Hinzufügen des folgenden HTTP-Request-Headers aktivieren:
  anthropic-dangerous-direct-browser-access: true
• Mit diesem Header können Aufrufe an Anthropic-Modelle direkt aus dem Browser erfolgen
• Anthropic war bislang zurückhaltend mit der Einführung dieser Funktion, weil bei Einbettung des API-Schlüssels in Client-Code jeder Nutzer mit Zugriff auf die Seite den API-Schlüssel stehlen und auf eigene Rechnung Anfragen stellen kann
• Trotzdem gibt es einige sinnvolle Use Cases für diese Funktion
  • Für interne Unternehmens-Tools, die nur vertrauenswürdigen Nutzern zugänglich sind, ist das in Ordnung
  • Oder man kann das Muster „BYOK (Bring Your Own Key)“ umsetzen, bei dem Nutzer ihren eigenen Schlüssel für die Verwendung in der clientseitigen App bereitstellen

Haiku - Beispiel für eine clientseitige App

• Die schnell gebaute Haiku-Seite ist ein Beispiel für eine clientseitige App, die CORS-Unterstützung benötigt
• Die App fragt den Zugriff auf die Webcam sowie einen Anthropic-API-Schlüssel an (der im localStorage des Browsers gespeichert wird), macht anschließend ein Foto und verwandelt es mit dem Haiku-Modell in ein Haiku
• Zuvor musste dafür ein eigener Proxy auf Vercel betrieben werden, um der Anthropic API CORS-Unterstützung hinzuzufügen
• Jetzt wurde die App so aktualisiert, dass sie den neuen Header sendet und ohne Proxy direkt mit Anthropic kommunizieren kann

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]

Hacker-News-Kommentare

• Ich mag persönlich Web-Apps, bei denen Nutzer ihren eigenen Key mitbringen.

  • Dieser Ansatz kombiniert den Komfort der Verteilung einer ausführbaren Anwendung mit den Vorteilen von Open Source.
  • Ich habe zwei solche Web-Apps entwickelt.
    • Eine Echtzeit-Transkriptions- und Übersetzungs-App mit Mikrofoneingabe
    • Eine App, die SRT-Untertitel in verschiedene Sprachen übersetzt
  • Es gibt zwei Hauptgründe, mich für das Modell „Nutzer bringt eigenen Key mit“ zu entscheiden.
    • Geringer Wartungsaufwand: Ich warte bereits viel Software und möchte kein Side-Project mitwarten müssen.
    • Niedrige Kosten: Ich kann die App ohne Werbung bereitstellen und die Betriebskosten niedrig halten.
  • So kann man nützliche Tools entwickeln und teilen, während Wartungsaufwand und Kosten für die Nutzer minimal bleiben.

• In Fällen, in denen Nutzer ihren eigenen Key mitbringen, ist das kein Problem.

  • Die Verarbeitung findet clientseitig statt, und solange das Gerät oder die Website nicht kompromittiert wird, ist das in Ordnung.
  • Wenn Entwickler jedoch Produktions-Keys clientseitig verwenden, kann sich die Angriffsfläche vergrößern.
  • Aus Gründen der Bequemlichkeit und Performance könnte das ohne ausreichende Sicherheitsüberlegungen geschehen.

• Ich verstehe nicht, warum JWT nicht unterstützt wird.

  • Supabase ist ein gutes Beispiel für sicheren clientseitigen Zugriff.

• Anthropic und alle AI-Anbieter sollten eine Funktion „Login with ___“ implementieren.

  • Nutzer sollten ihren eigenen AI-Ressourcen vertrauen können.
  • Die meisten Nutzer empfinden es als umständlich, API-Keys zu erzeugen und zu laden, und können sie nicht sicher verwalten.

• Wenn Nutzer ihren eigenen Key mitbringen, ist OAuth die bessere Lösung.

  • Manche Entwickler könnten den echten Key im Frontend hart kodieren und dadurch in Schwierigkeiten geraten.
  • OAuth ist die sicherere Lösung.

• Für interne Entwicklung kann das geeignet sein, aber nicht für Apps für Endnutzer.