Eine KI-Anfrage ist nur der Anfang.

Bevor das Modell läuft

Der Nutzer liefert einen Prompt und einen Alias wie cheap, fast oder smart. Der Produktionsserver prüft Authentifizierung, Workspace-Besitz und Berechtigung, bevor er den Task akzeptiert. Anbieter-Modell-IDs und Geheimnisse bleiben hinter dieser Grenze — der freundliche Alias ist das einzige Modellvokabular, das der Client je braucht, weil die Zuordnung zu einem echten Anbietermodell Konfiguration ist, nicht Vertrag.

Ein dauerhafter Task-Datensatz gibt der Anfrage eine Identität, bevor die Hintergrundausführung beginnt. Diese Identität verknüpft Einreichung, Worker, Nutzungsdatensätze und Ergebnis. Sie gibt dem Nutzer auch eine Möglichkeit, die Arbeit wiederzufinden, nachdem er wegnavigiert ist.

Die Reihenfolge zählt: Teure Arbeit startet erst, wenn billige Prüfungen bestanden sind. Authentifizierung, Besitz und Berechtigung zu verifizieren, bevor irgendetwas eingereiht wird, hält unauthentifizierte oder unbezahlte Anfragen davon ab, je einen Anbieter zu erreichen — und macht den Fehlschlag für den Nutzer erklärbar. Der KI-Modul-Guide dokumentiert, wo diese Prüfungen leben; der Workspace-Grenzen-Post erklärt, warum Besitz serverseitig abgeleitet wird, statt ihn vom Client zu übernehmen.

Entscheide, wessen Schlüssel und wessen Limits

Ein KI-Feature ist eine Ausgabenentscheidung. supastack lässt Workspaces eigene Anbieter-Schlüssel mitbringen — verschlüsselt gespeichert, niemals Clients ausgesetzt — oder auf Plattform-Schlüsseln laufen, und setzt Budgets pro Workspace gegen einen Modell-Preiskatalog durch. Wie auch immer deine Implementierung aussieht, die Fragen bleiben dieselben: Wer zahlt, und wo wird das Limit durchgesetzt?

Durchsetzung gehört in den Server-Workflow, nicht in eine browserseitige Schätzung. Ein Budget, das erst nach der Generierung geprüft wird, dokumentiert nur die Überschreitung; vor dem Dispatch geprüft, verhindert es sie. Anbieter-Schlüssel einrichten deckt die Konfigurationsseite ab.

Die Ausführung explizit machen

Trigger.dev führt den Workflow ai.generate aus. Der fähigkeitsbewusste Router wählt ein Modell anhand der konfigurierten Richtlinie und der Anforderungen der Anfrage. Behandle diese Richtlinie als operativen Input: Ein nicht verfügbarer Alias sollte im UI nicht als funktionierende Auswahl erscheinen.

Ein Netzwerkausfall während der Einreichung kann den Client unsicher lassen, ob die Arbeit eingereiht wurde. Der Produktionspfad nutzt einen task-bezogenen Idempotenzschlüssel und eine gespeicherte Einreichung, damit die Wiederherstellung die ursprüngliche Anfrage wiederverwendet. Nach jedem Timeout eine neue Task einzureichen, riskiert doppelte Arbeit und doppelte Kosten.

Dauerhaftigkeit ist auch das, was das UI einfach hält: Der Screen liest den Task-Status und rendert ihn, statt Retries zu orchestrieren. Wenn Generierung Modellaufrufe, Tool-Schritte oder Zeitpläne umspannt, ist es der explizite Workflow-Vertrag — enqueue, status, cancel —, der „in Bearbeitung“ ehrlich hält.

Nenne die Fehlermodi beim Namen

Zwischen Anfrage und Ergebnis liegt eine konkrete, endliche Menge von Dingen, die schiefgehen. Entwirf für jedes beim Namen statt für „Fehler“ im Abstrakten — jeder Task sollte in einem erklärbaren Zustand enden: eingereiht, laufend, mit Grund fehlgeschlagen oder mit Ergebnis abgeschlossen. Task-Recovery ist die Referenz des Kits für die Wiederherstellungsseite.

Die Anforderung darunter ist, dass kein Zustand lügen darf. Ein Spinner, der die Arbeit überlebt, oder eine Erfolgsmeldung für einen Task, der nie lief, ist ein Support-Ticket und ein Abrechnungsstreit, die nur darauf warten, zu passieren.

• Timeout bei der Einreichung — über die gespeicherte Einreichung und den task-bezogenen Idempotenzschlüssel wiederherstellen, statt neu einzureihen.
• Anbieter mitten im Task fehlgeschlagen — den Task mit einem Grund als fehlgeschlagen markieren, den das UI zeigen kann.
• Budget erschöpft — vor dem Dispatch ablehnen, nicht nach der Ausgabe.
• Nutzer wegnavigiert — der dauerhafte Datensatz und die Recovery-URL stellen Status und Ergebnis wieder her.

Nachverfolgen, was passiert ist

Generierung produziert mehr als Text. Die Anwendung zeichnet Nutzung und ein Task-Ergebnis auf, und das UI liest den Status über die authentifizierte API. Der Nutzungsdatensatz ist es, der das Budget durchsetzbar macht — er wird geschrieben, bevor das Ergebnis zurückgegeben wird, nicht hinterher geschätzt.

Die Abschluss-E-Mail ist ein separater Schritt mit eigenen Zustellungsdatensätzen. Eine erfolgreiche Modellantwort belegt nicht, dass eine E-Mail zugestellt wurde. Diese Ergebnisse getrennt zu halten macht Fehlschläge leichter zu erklären und zu wiederholen, ohne das Modell unnötig erneut laufen zu lassen.

Das Ergebnis braucht außerdem ein Zuhause, zu dem der Nutzer zurückkehren kann: eine Task-Seite, eine Verlaufsliste, eine Recovery-URL in der Abschluss-E-Mail. Eine Generierung, die nur in einer flüchtigen Benachrichtigung existiert, ist Arbeit, die du ein zweites Mal liefern musst.

Jede Grenze verifizieren

Nutze deterministische Fake-Adapter, um zuerst die Entscheidungen der Anwendung zu testen: verweigerter Zugang, deaktivierte Aliase, doppelte Einreichungen, Ergebnis-Wiederherstellung und generische Fehler. Diese Tests sollten ohne Anbieter-Zugangsdaten laufen.

Nutze dann den explizit opt-in Anbieter-Smoke-Prozess für echte Integrationen. Er verlangt die dokumentierte Sandbox-Konfiguration und eine Freigabe für externe Aufrufe. Diese Unterscheidung hält die gewöhnliche Entwicklung schnell und macht Produktionsnachweise konkret und nachvollziehbar.

Halte diese Trennung stabil, während sich das Produkt ändert: deterministische Abdeckung nahe jeder Grenzentscheidung, damit ein Anbieterwechsel, eine Router-Policy-Änderung oder ein neuer Alias einen Test scheitern lässt statt einen Kunden.

Häufige Fragen zu KI-Features in SaaS

Ein paar Fragen kommen in jedem Gespräch darüber auf, KI hinter eine Paywall zu stellen.

• Wo sollte die Autorisierung für KI-Features passieren? — Bevor irgendetwas eingereiht wird: authentifizieren, Workspace auflösen, Berechtigung prüfen, dann den Task erstellen. Prüfungen nach der Generierung dokumentieren nur Missbrauch.
• Brauche ich Bring-your-own-Key-Support? — Wenn deine Kunden eigene Anbieterbeziehungen haben, ja: Sie entscheidet, wer zahlt und wem Rate-Limits gehören. Speichere Schlüssel verschlüsselt und halte sie von Clients fern — der KI-Konfigurations-Guide beschreibt das Modell.
• Wie verhindere ich, dass Retries doppelt abrechnen? — Begrenze den Idempotenzschlüssel auf den Task und verwende die gespeicherte Einreichung bei der Wiederherstellung wieder, damit ein Timeout keinen zweiten abrechenbaren Lauf erzeugt.
• Welche Nutzungsdaten sollte ich aufzeichnen? — Pro Task: Modell, verbrauchte Einheiten, Kosten gegen den Preiskatalog und der Workspace — genug, um Budgets durchzusetzen und Ausgabenfragen zu beantworten, ohne Jobs erneut laufen zu lassen.
• Wann gehört Generierung in einen Hintergrund-Job? — Immer dann, wenn sie eine Anfrage überleben kann. Modell-Latenz, Retries und mehrstufige Arbeit sprechen für dauerhafte Ausführung; nur sofortige, billige Aufrufe gehören inline.