LLM-APIs nutzen: Anthropic, OpenAI und OpenRouter

Vom Chatfenster zur API

Wenn du ChatGPT, Claude oder Gemini im Browser nutzt, sprichst du eigentlich schon mit einer API - du bekommst sie nur ueber eine fertige Oberflaeche serviert. Sobald du ein eigenes Skript, ein Tool oder eine Automatisierung bauen willst, die selbststaendig mit einem Sprachmodell redet, brauchst du den direkten Zugang: die LLM-API (Large Language Model API) des jeweiligen Anbieters.

Der Unterschied zur Chat-Oberflaeche ist simpel, aber wichtig: Statt eine Antwort im Browser zu lesen, schickt dein eigener Code eine HTTP-Anfrage an einen Server, bekommt strukturierte Daten (meist JSON) zurueck und kann damit weiterarbeiten - in eine Datenbank schreiben, eine E-Mail generieren, einen Slack-Bot fuettern, was auch immer. Genau dieser Baustein steckt hinter praktisch jedem KI-Feature, das du in Apps und Webseiten siehst.

Dieser Artikel zeigt dir die drei grossen Wege dahin: Anthropic (Claude), OpenAI (GPT) und OpenRouter als Aggregator fuer beide plus viele weitere Anbieter. Die Konzepte - API-Key, Nachrichtenformat, Streaming - sind bei allen drei fast identisch, weil sich ein De-facto-Standard etabliert hat. Wer einen davon verstanden hat, versteht die anderen in fuenf Minuten.

Der API-Key: dein digitaler Ausweis

Bevor du eine einzige Anfrage schicken kannst, brauchst du einen API-Key - eine lange, zufaellige Zeichenkette, die dich (bzw. deinen Account) gegenueber dem Anbieter identifiziert und die Abrechnung zuordnet. Du bekommst ihn im jeweiligen Entwickler-Portal:

• Anthropic: platform.claude.com → Account Settings → API Keys
• OpenAI: platform.openai.com → API Keys
• OpenRouter: openrouter.ai → Keys

Der Key wird bei jeder Anfrage als HTTP-Header mitgeschickt. Wie der Header genau heisst, unterscheidet sich zwischen den Anbietern:

Anthropic verlangt zusaetzlich einen anthropic-version-Header (z.B. 2023-06-01), der die API-Version festlegt - das schuetzt dich davor, dass sich das Antwortformat unter deinem Code aendert, ohne dass du es merkst.

Das Messages-/Chat-Format

Alle drei Anbieter nutzen im Kern dieselbe Idee: Du schickst eine Liste von Nachrichten (messages), jede mit einer Rolle (role) und einem Inhalt (content). Das Modell antwortet mit einer neuen Nachricht in derselben Struktur.

Die ueblichen Rollen:

Ein zentraler Punkt, der Einsteiger oft ueberrascht: Die API ist zustandslos. Das Modell “erinnert” sich nicht von selbst an vorherige Nachrichten. Bei jeder neuen Anfrage schickst du den kompletten bisherigen Verlauf erneut mit - dein eigener Code muss die Historie verwalten und mitschicken. Mehr zu den Grenzen davon steht in Tokens und Kontextfenster.

Beispiel: Anthropic Messages API (curl)

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": "Du bist ein hilfreicher IT-Support-Assistent. Antworte kurz und praezise.",
    "messages": [
      {"role": "user", "content": "Wie leere ich den DNS-Cache unter Windows?"}
    ]
  }'

Beispiel: OpenAI Chat Completions API (curl)

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4.1",
    "messages": [
      {"role": "system", "content": "Du bist ein hilfreicher IT-Support-Assistent. Antworte kurz und praezise."},
      {"role": "user", "content": "Wie leere ich den DNS-Cache unter Windows?"}
    ]
  }'

Der Unterschied springt sofort ins Auge: Bei OpenAI ist system einfach die erste Nachricht in derselben Liste wie user und assistant. Bei Anthropic ist system ein eigenes Feld ausserhalb von messages. Kleine Details wie dieses sind der Hauptgrund, warum Code, der fuer einen Anbieter geschrieben wurde, nicht 1:1 beim anderen laeuft - dazu gleich mehr.

Request und Response im Detail

Eine typische Antwort (Response) liefert nicht nur den reinen Text, sondern ein strukturiertes JSON-Objekt mit Metadaten. Das ist wichtig, weil du daraus auch Kosten, Abbruchgrund und mehr ablesen kannst.

{
  "id": "msg_01XyzAbc123",
  "type": "message",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Oeffne die Eingabeaufforderung als Administrator und fuehre 'ipconfig /flushdns' aus."
    }
  ],
  "model": "claude-sonnet-4-5",
  "stop_reason": "end_turn",
  "usage": {
    "input_tokens": 34,
    "output_tokens": 22
  }
}

Die wichtigsten Felder, die in fast jeder API-Antwort vorkommen:

Streaming: Antworten in Echtzeit empfangen

Standardmaessig wartest du bei einer Anfrage, bis die komplette Antwort fertig generiert ist, bevor du irgendetwas siehst - bei langen Antworten koennen das mehrere Sekunden sein. Streaming loest das: Der Server schickt die Antwort Wort-fuer-Wort (genauer: Token fuer Token) als fortlaufenden Datenstrom, sodass du sie sofort anzeigen kannst, waehrend das Modell noch “schreibt”. Genau das siehst du im ChatGPT- oder Claude-Chatfenster, wenn Text scheibchenweise erscheint.

Technisch laeuft das ueber Server-Sent Events (SSE): Du setzt "stream": true im Request, und die Antwort kommt als Folge einzelner Events statt als ein grosses JSON-Objekt.

// Node.js Beispiel mit der offiziellen Anthropic-SDK
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

const stream = client.messages.stream({
  model: "claude-sonnet-4-5",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Erklaer mir kurz, was RAID 5 ist." }],
});

for await (const event of stream) {
  if (event.type === "content_block_delta" && event.delta.type === "text_delta") {
    process.stdout.write(event.delta.text);
  }
}

Ein rohes SSE-Event ohne SDK sieht in etwa so aus:

event: content_block_delta
data: {"type":"content_block_delta","delta":{"type":"text_delta","text":"RAID"}}

event: content_block_delta
data: {"type":"content_block_delta","delta":{"type":"text_delta","text":" 5"}}

Modellwahl: welches Modell fuer welche Aufgabe

Jeder Anbieter bietet mehrere Modelle in unterschiedlichen Groessen an - grob gesagt eine Abstufung zwischen maximaler Faehigkeit (teuer, langsamer) und Geschwindigkeit/Kosten (guenstiger, schneller, aber weniger tiefgehendes Schlussfolgern). Die genauen Namen und Preise aendern sich staendig (siehe Kasten unten), das Prinzip aber bleibt stabil:

Ein praktischer Trick fuer Produktionscode: Viele Anbieter bieten “Alias”-Modellnamen an (ohne Versionsnummer), die automatisch auf die jeweils aktuelle Version zeigen - praktisch, aber riskant, weil sich das Verhalten deines Codes ohne Vorwarnung aendern kann. Fuer produktive Systeme lohnt sich meist eine konkrete, gepinnte Modellversion statt eines “immer neuesten” Alias.

Unterschiede zwischen den Anbietern

Auf den ersten Blick sehen sich Anthropic- und OpenAI-Anfragen sehr aehnlich - trotzdem gibt es strukturelle Unterschiede, die beim Umstieg von einem zum anderen fuer Kopfzerbrechen sorgen koennen:

Diese Unterschiede sind der Grund, warum viele Entwicklerinnen und Entwickler entweder (a) eine eigene Abstraktionsschicht ueber mehrere Anbieter bauen, (b) ein Framework wie LangChain oder LlamaIndex nutzen, das die Unterschiede kapselt, oder (c) einen Aggregator wie OpenRouter verwenden - dazu jetzt mehr.

OpenRouter: ein API-Schluessel fuer (fast) alles

OpenRouter ist ein Vermittlungsdienst: Du registrierst dich einmal, bekommst einen API-Key, und kannst darueber auf Hunderte von Modellen verschiedenster Anbieter zugreifen - Claude, GPT, Gemini, Llama, Mistral, DeepSeek und viele mehr - ohne bei jedem einzelnen Anbieter ein eigenes Konto und einen eigenen Key zu brauchen.

Der entscheidende technische Kniff: OpenRouter bietet eine OpenAI-kompatible API an. Das heisst, du sprichst technisch immer im OpenAI-Chat-Completions-Format - egal, welches Modell im Hintergrund tatsaechlich antwortet. Du musst also nur eine einzige API-Struktur lernen, um Dutzende Anbieter anzusprechen.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-4.5",
    "messages": [
      {"role": "user", "content": "Was ist der Unterschied zwischen TCP und UDP?"}
    ]
  }'

Der einzige Unterschied zu einer direkten OpenAI-Anfrage: Der model-Wert wird mit einem Anbieter-Praefix versehen (z.B. anthropic/..., google/..., meta-llama/...), damit OpenRouter weiss, an wen die Anfrage im Hintergrund weitergereicht werden soll.

Warum ueberhaupt einen Aggregator nutzen?

Ein weiterer Punkt: Bei OpenRouter laufen Anfragen ueber einen zusaetzlichen Vermittler, bevor sie beim eigentlichen Modell-Anbieter ankommen. Fuer sensible oder personenbezogene Daten lohnt sich deshalb ein Blick in die Datenschutzbedingungen von OpenRouter selbst, zusaetzlich zu denen des jeweiligen Modell-Anbieters - siehe auch KI-Datenschutz-Grundlagen.

Entscheidungshilfe: direkter API-Zugang oder OpenRouter?

Willst du nur EIN Modell fest im Produktivbetrieb einsetzen?
├── Ja, hohes und planbares Volumen
│   → Direkter API-Zugang beim Anbieter (Anthropic/OpenAI/Google)
│     spart den Aufschlag und gibt vollen Feature-Zugriff
│     (z.B. neueste Beta-Features landen zuerst direkt beim Anbieter)
│
├── Nein, ich will mehrere Modelle vergleichen/testen
│   → OpenRouter: ein Key, schneller Modellwechsel per String
│
└── Ich baue ein Tool, das Nutzer ihr eigenes Modell waehlen lassen soll
    → OpenRouter: du musst nicht fuer jeden moeglichen Anbieter
      eigene Integrationscode-Pfade pflegen

Erstes eigenes Beispiel: ein einfacher Chat-Client

Zum Abschluss ein etwas vollstaendigeres Beispiel, das die Grundbausteine kombiniert - eine simple Node.js-Funktion, die eine Frage an Claude schickt und die Antwort zurueckgibt:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY, // niemals hart codieren
});

async function frageAnClaude(frage) {
  const response = await client.messages.create({
    model: "claude-sonnet-4-5",
    max_tokens: 500,
    system: "Antworte auf Deutsch, kurz und technisch praezise.",
    messages: [{ role: "user", content: frage }],
  });

  // content ist ein Array von Bloecken - meist genau einer vom Typ "text"
  const textBlock = response.content.find((b) => b.type === "text");
  return textBlock?.text ?? "";
}

const antwort = await frageAnClaude("Was macht der Befehl 'ipconfig /all'?");
console.log(antwort);

Dieselbe Anfrage laesst sich ohne SDK auch direkt per curl plus jq fuer die JSON-Extraktion abschicken - das erste curl-Beispiel weiter oben zeigt genau diese Struktur.

Kurz zusammengefasst

• Ein API-Key identifiziert dich gegenueber dem Anbieter und wird als Header mitgeschickt - niemals im Code veroeffentlichen.
• Anfragen bestehen aus einer Liste von Nachrichten mit Rollen (system, user, assistant); die API selbst ist zustandslos, der Verlauf muss bei jeder Anfrage mitgeschickt werden.
• Streaming liefert die Antwort haeppchenweise per Server-Sent Events statt als einen Block am Ende - Pflicht bei langen erwarteten Antworten.
• Anthropic und OpenAI folgen demselben Grundprinzip, unterscheiden sich aber in Feldnamen und Struktur (system als eigenes Feld vs. als Nachricht, Content-Bloecke vs. String).
• OpenRouter buendelt viele Anbieter hinter einer einzigen OpenAI-kompatiblen API - praktisch zum Vergleichen und Experimentieren, mit kleinem Preisaufschlag gegenueber dem direkten Zugang.
• Modellnamen und Preise aendern sich staendig - fuer produktiven Code lohnt sich eine gepinnte Version statt eines “immer neuesten” Alias.

Weiterlernen

• Anthropic: Messages API Reference - offizielle API-Referenz mit allen Parametern
• Anthropic: Get started - offizieller Einstieg inkl. erstem API-Call
• OpenAI: API Reference - offizielle Referenz zur Chat Completions API
• OpenRouter: Quickstart - offizieller Einstieg in die OpenRouter-API
• OpenRouter: Models - durchsuchbare Liste aller verfuegbaren Modelle inkl. Preisen

Verwandte Themen: Tokens und Kontextfenster · Tokens und Kosten optimieren · Streaming und strukturierte Outputs · MCP - Model Context Protocol