Ein Fintech-Client rief mich Ende 2023 an, echte Panik in seiner Stimme, weil sein Dev-Team sechs Wochen damit verbracht hatte, eine Streaming-Chat-Oberfläche auf OpenAIs API zu bauen und sie funktionierte immer noch nicht auf Mobile Safari. Race Conditions. Token-Chunking-Probleme. Die UI würde mitten in einer Antwort einfrieren. Sechs Wochen. Ich sah mir ihre Codebasis an und es war genau das, was man erwarten würde: eine handgerollte ReadableStream-Implementierung, eine maßgeschneiderte State-Management-Schicht für die Streaming-Tokens, Retry-Logik kopiert von einer drei Jahre alten Stack-Overflow-Antwort. Das Ding hielt zusammen mit Klebeband.
Ich habe den Kern davon mit dem Vercel AI SDK in etwa zwei Tagen neu geschrieben. Streaming funktionierte. Mobile Safari funktionierte. Der Client hörte auf anzurufen.
Das ist kein Pitch. Das ist nur, was passiert ist. Und deshalb möchte ich durchgehen, was dieses SDK wirklich tut, wo es dir wirklich Zeit spart und wo du immer noch auf Mauern treffen wirst.
Was das Vercel AI SDK eigentlich ist
Menschen hören „Vercel AI SDK" und nehmen an, es ist in Vercel-Infrastruktur gesperrt. Das ist es nicht. Du kannst es auf jedem Node.js-Server ausführen, einschließlich deinem eigenen VPS, Railway, Render, überall. Was es eigentlich ist: eine TypeScript-Bibliothek, die die unangenehmsten Teile des Aufbaus von LLM-gestützten Features in eine Web-App abstrahiert.
Es gibt zwei Hauptpakete, auf die du zugreifen wirst. ai ist die Core Runtime. @ai-sdk/openai (oder @ai-sdk/anthropic, @ai-sdk/google, etc.) sind die Provider-Adapter. Das SDK nutzt eine einheitliche Schnittstelle, sodass der Wechsel von GPT-4o zu Claude 3.5 Sonnet in den meisten Fällen wirklich eine Einzeiler-Änderung ist. Ich habe das getestet. Es funktioniert.
Die Core Primitives
Drei Dinge bilden das Herz des SDK:
streamTextstreamt eine Textantwort Token für Token, ideal für Chat-InterfacesgenerateTextwartet auf die vollständige Antwort, gut für Hintergrund-Jobs oder wenn du keine Streaming-UX brauchstgenerateObjectgibt strukturiertes JSON zurück, das gegen ein Zod-Schema validiert wird – das ist der Punkt, an dem es richtig interessant wird
streamText ist das, was die meisten Leute zuerst wollen. Es kümmert sich um die ReadableStream-Installationen, die Kodierung und das Chunking. Dieser sechswöchige Fintech-Albtraum, den ich erwähnt habe? Das ist genau das, was streamText vom ersten Tag an gelöst hätte.
Die Einrichtung Ohne den Verstand zu Verlieren
Angenommen, du bist auf Next.js 14 oder 15 mit dem App Router (was du wahrscheinlich bist, wenn du das 2025 liest), ist die Einrichtung wirklich schnell.
- Installiere die Pakete:
npm install ai @ai-sdk/openai - Erstelle einen Route Handler unter
app/api/chat/route.ts - Importiere
streamTextund deinen Provider, übergebe dein Modell und die Messages, gib das Ergebnis alsStreamingTextResponsezurück - Auf dem Client nutze den
useChatHook aus demai/reactPackage
Das war's. Du wirst in unter einer Stunde einen funktionierenden Streaming Chat haben, wenn du Next.js einigermaßen beherrschst. Der useChat Hook verwaltet das Message Array, den Loading State, die Input Field Bindung und die Streaming Updates. Du schreibst nichts davon selbst.
Was ich sofort zu jedem Production Setup hinzufügen würde: einen ordentlichen System Prompt, Rate Limiting (ich verwende Upstash dafür, ihr Redis-gestützter Rate Limiter funktioniert perfekt mit Edge Functions), und eine Art Token Usage Logging. Das SDK stellt Usage Daten auf dem Response Objekt bereit, sodass du Prompt Tokens und Completion Tokens ohne zusätzliche API Calls in deine Datenbank loggen kannst.
generateObject Ist das Feature, das du verschläfst
Ehrlich gesagt: streamText bekommt alle Aufmerksamkeit, aber generateObject ist das, das verändert hat, wie ich AI Features architekturiere.
Die Idee ist einfach. Du definierst ein Zod Schema, übergibst es generateObject, und das SDK instruiert das Modell, JSON zurückzugeben, das dem Schema entspricht. Du bekommst ein typed Object zurück, keine String, den du parsen und beten musst.
Seahawk hatte letztes Jahr ein Projekt für ein Immobilienverwaltungsunternehmen. Sie wollten strukturierte Daten aus hochgeladenen Mietverträgen extrahieren, Mieternamen, Mietbeträge, Break Clauses, Verlängerungsdaten. Der alte Ansatz hätte gelautet: das Modell prompten, Text zurückbekommen, einen Regex Parser schreiben, weinen. Mit generateObject definierten wir ein LeaseSchema mit Zod, und das Modell gab bei jedem Durchlauf saubere typed Daten zurück. Wir pushten extrahierte Mietverträge innerhalb einer Woche in eine Postgres Tabelle.
Das, das Menschen verwirrt: nicht alle Modelle unterstützen Structured Output gleich gut. GPT-4o und Claude 3.5 Sonnet handhaben es zuverlässig. Einige kleinere oder ältere Modelle werden Fields halluzinieren oder das Schema komplett ignorieren. Halte dich für diese Anwendung an die Flagship Modelle, zumindest bis du deinen Use Case validiert hast.
Tool Calling: Wo die echte Kraft liegt
Wenn generateObject untergenutzt ist, wird Tool Calling aktiv missverstanden. Die meisten Entwickler denken, „Tool Calling" bedeutet, dass die KI im Internet browsen oder Code ausführen kann. Manchmal tut sie das. Aber in der Praxis sind Tools nur Funktionen, die du definierst und die das Modell während einer Antwort aufrufen kann.
Wie man darüber denkt
Sagen wir, du baust einen Support-Bot für ein SaaS-Produkt. Der Benutzer fragt „Welchen Abonnementplan habe ich aktuell?". Das kann das Modell nicht wissen. Aber du kannst ein getUserSubscription-Tool definieren, das eine Benutzer-ID nimmt und die Plan-Daten aus deiner Datenbank zurückgibt. Das Modell erkennt die Absicht, ruft das Tool auf, erhält die Daten zurück und bezieht sie in die Antwort ein. Der Benutzer sieht nur eine kohärente Antwort.
Der tools-Parameter des SDK auf streamText und generateText nimmt ein Objekt, bei dem jeder Schlüssel ein Tool-Name ist und jeder Wert eine description (die das Modell nutzt, um zu entscheiden, wann es aufgerufen wird), ein parameters-Schema (wieder Zod) und eine execute-Funktion hat. Die execute-Funktion läuft serverseitig, sicher, weg vom Client.
Ich habe Multi-Step-Agents auf diese Weise gebaut. Das SDK unterstützt maxSteps, sodass das Modell Tool-Aufrufe verketten kann – ein Tool aufrufen, das Ergebnis nutzen, ein anderes Tool aufrufen, alles zusammenführen, antworten. Es ist keine Magie. Du musst dich trotzdem sorgfältig um deine Tool-Beschreibungen und deinen System-Prompt kümmern. Aber die Verkabelung wird dir abgenommen.
Middleware, Wrapping und das Pipeline-Modell
Eine Sache, die ich erst bei tieferem Lesen der Dokumentation schätzte: Das SDK hat ein Middleware-Konzept, das dir erlaubt, Modell-Aufrufe zu wrappen, um Logging, Caching oder benutzerdefiniertes Verhalten hinzuzufügen, ohne deinen eigentlichen Feature-Code zu berühren.
wrapLanguageModel nimmt ein Modell und ein Middleware-Objekt. Du kannst Anfragen abfangen, bevor sie die API treffen, Parameter modifizieren, Responses cachen. Ich habe das bei einem Content-Generation-Tool genutzt, das wir für einen Publisher bauten – ihr Use-Case hatte viele wiederholte Prompts (dieselbe Artikel-Zusammenfassung wurde mehrmals am Tag angefordert), und wir haben Responses in Redis mit der Middleware-Layer gecacht. Die Kosten sind im ersten Monat um etwa 35% gesunken.
Das ist die Art von Sache, die du normalerweise umständlich um deine API-Aufrufe herum anbringen würdest. Sie als First-Class-Konzept im SDK zu haben bedeutet, dass sie zusammensetzbar und testbar ist.
Was es nicht tut (Sei ehrlich zu dir selbst)
Okay. Lass mich dir etwas Schmerz ersparen.
Das SDK übernimmt nicht die Speicherverwaltung oder die Verlaufshistorie längerer Konversationen für dich. useChat behält das Message-Array im Client-State, aber sobald der Nutzer aktualisiert, ist es weg. Wenn du persistente Konversationen brauchst, musst du das selbst bauen. Postgres oder MongoDB für die Nachrichtenspeicherung, beim Mount abrufen, um den Chat neu zu laden – nichts davon wird bereitgestellt. Das ist tatsächlich das richtige Verhalten. Das SDK sollte nicht deine Datenschicht besitzen. Aber Anfänger erwarten das oft.
Es behandelt auch multimodale Eingaben nicht nativ auf eine Weise, die die ganze Komplexität abstrahiert. Du kannst Bild-URLs im Messages-Array übergeben und Modelle wie GPT-4o werden sie prima verarbeiten, aber einen ordentlichen Image-Upload-Flow mit Vorschau, Kompression und Speicherung zu bauen, ist immer noch deine Aufgabe. Ich nutze Uploadthing dafür, wenn ich auf Next.js arbeite, dauert etwa 30 Minuten zum Einbinden.
RAG (retrieval-augmented generation) ist auch nicht enthalten. Es gibt keine eingebaute Vektorsuche, keine Embedding-Pipeline, keine Chunking-Logik. Dafür greifst du zu etwas wie pgvector auf Postgres oder einen dedizierten Service wie Pinecone. Das SDK übernimmt den LLM-Call. Den Rest der Retrieval-Architektur musst du selbst bauen.
Bereitstellung: Vercel vs. überall sonst
Ja, das SDK funktioniert am besten auf Vercel. StreamingTextResponse funktioniert mit Vercels Edge Runtime sofort, und Cold Starts bei Edge Functions sind viel niedriger als bei serverlosen Node.js-Funktionen. Wenn deine Chat-Antworten langsam wirken, spielt die Latenz bis zum ersten Token eine große Rolle, und Edge reduziert das.
Aber ich habe es auf Railway (Node.js, nicht Edge) deployed und es funktioniert einwandfrei. Du nutzt einfach Response mit korrekten Streaming-Headern statt der Vercel-spezifischen Helfer, und das SDK dokumentiert das. Lass dich von „Vercel AI SDK" nicht denken, dass du gebunden bist.
Eine Sache, die ich wirklich empfehlen würde: Halte deine AI-Route-Handler dünn. Mach nicht Datenbankabfragen, Authentifizierungschecks und LLM-Calls alle in einer Funktion. Middleware (Next.js-Middleware, nicht die SDK-Middleware) sollte Auth vor der Anfrage handeln, bevor sie überhaupt deine AI-Route erreicht. Hält die Dinge schnell, hält die Dinge debuggbar.
FAQ
Ist das Vercel AI SDK kostenlos nutzbar?
Das SDK selbst ist Open Source und kostenlos. Du zahlst für die zugrundeliegenden Model-APIs – OpenAI, Anthropic, Google, wen auch immer du aufrufst. Diese Kosten musst du selbst verwalten. Das SDK schlägt nichts auf.
Kann ich es mit anderen Modellen als OpenAI verwenden?
Ja, und das ist einer seiner echten Stärken. Es gibt offizielle Adapter für Anthropic, Google (Gemini), Mistral, Groq, Cohere und mehr. Die Community hat auch Adapter für Ollama gebaut, falls du lokale Modelle ausführen möchtest. Die einheitliche Schnittstelle bedeutet, dass dein Feature-Code sich nicht ändert, wenn du den Provider wechselst.
Funktioniert es mit React Server Components?
Teilweise. generateText und generateObject können in Server Components ohne Probleme ausgeführt werden – es sind einfach asynchrone Funktionen. streamText mit dem useChat Hook benötigt Client-seitigen State, also lebt dieser Teil in einer Client Component. Das ist Standard-Next.js-Architektur und sollte dir keine Probleme bereiten, wenn du die Grenze verstehst.
Wie gehe ich mit Fehlern um, wenn die API ausfällt?
Das SDK wirft typisierte Fehler, die du fangen und behandeln kannst. In der Praxis umhülle ich meine LLM-Aufrufe mit einem try/catch und gebe eine freundliche Fallback-Nachricht zurück, anstatt den Stream-Fehler als kaputte Teilantwort bis zur UI durchblubbern zu lassen. Die SDK-Dokumentation zum Fehlerhandling behandelt die Fehlertypen im Detail und lohnt sich, vor dem Go-Live zu lesen.
Wie sieht es mit dem Token-Limit aus?
Das SDK verwaltet Context-Window-Limits nicht für dich. Wenn du ein langlaufendes Gespräch aufbaust und die Nachrichtenverlauf nicht kürzt, wirst du das Context-Window des Modells erreichen und bekommst einen Fehler. Eine einfache Lösung: Behalte die letzten N Nachrichten (ich nehme normalerweise 20) plus einen angehefteten System-Prompt. Für die meisten Chat-Anwendungen ausreichend.
---
Schau, das Vercel AI SDK ist kein Wunder. Es ist eine gut durchdachte Abstraktion über etwas wirklich mühsame Rohrleitungen. Es handhabt Streaming korrekt, es gibt dir typisierte strukturierte Ausgaben, es macht Tool-Aufrufe zugänglich und es funktioniert über Provider hinweg. Für 80% der AI-Feature-Arbeiten, die ich übernehme, ist es der richtige Ausgangspunkt.
Der Fintech-Kunde ist übrigens zwei Wochen nach meinem Rewrite mit dem erneuerten Chat live gegangen. Keine Probleme auf Mobile Safari. Keine Race Conditions. Sechs Wochen wurden zwei Tage. Manchmal ist die richtige Abstraktion eine Menge wert.
Weiterführende Lektüre: Headless vs WordPress Sicherheit 2026: warum Next.js und Astro, Headless und Astro.