AnythingLLM Max Tokens: Abgeschnittene Antworten beheben

Bricht eine lange AnythingLLM-Antwort mitten im Satz ab, prüfe zuerst, ob Max Tokens diese Ausgabe begrenzt hat. Ein größeres Kontextfenster oder ein längeres Proxy-Timeout sind keine gleichwertigen Lösungen. Entscheidend sind das tatsächlich übermittelte Ausgabebudget, der finish_reason der Modell-API und ein erneuter Test mit nur einer geänderten Variable. Bewahre die ursprüngliche Konfiguration auf.

Wähle die Korrektur anhand des Abschlussgrunds

Dass auf dem Bildschirm kein Text mehr erscheint, ist ein Symptom, keine Diagnose. Bei OpenAI Chat Completions bedeutet length, dass das im Request angegebene Tokenlimit erreicht wurde. stop kann ein natürliches Ende oder eine vorgegebene Stoppsequenz bedeuten. tool_calls steht für einen Werkzeugaufruf, nicht für eine fertige abschließende Antwort. Prüfe bei kompatiblen APIs zusätzlich das Verhalten des jeweiligen Servers.

Vorliegender Hinweis	Zuerst prüfen	Nächster Schritt
Die Modell-API liefert finish_reason=length, das wirksame Ausgabebudget ist nachvollziehbar	Ausgabelimit	Eingabe beibehalten und nur ein unterstütztes Ausgabebudget ändern
Der Server meldet ausdrücklich zu großen Kontext; dieselbe Aufgabe funktioniert mit weniger Verlauf oder abgerufenen Textstellen	Kontextbelastung	Eingabe reduzieren und das echte Modellfenster prüfen, statt nur mehr Ausgabe zu erlauben
Timeout, Verbindungsabbruch, Abbruch durch den Client oder ein Stream ohne sichtbaren Abschlussgrund	Verbindung, Abbruch oder Streaming-Kompatibilität	Zeitstempel abgleichen und die beendende Schicht finden; ein fehlendes Feld allein beweist keinen Netzwerkfehler
Die Antwort liefert stop, enthält aber nicht alle Abschnitte oder Nummern	Anweisungen, Stoppsequenzen und Vollständigkeit	Fehlende Inhalte prüfen: Ein reguläres Ende ist nicht gleichbedeutend mit einer erledigten Aufgabe

Das Ausgabebudget begrenzt, wie viel eine Anfrage generieren darf. Das Kontextfenster betrifft die Kontextmenge, die das Modell verarbeiten kann. Verlauf, Systemanweisungen und abgerufene Dokumentpassagen können Teil der Eingabe sein: Der Generic-OpenAI-Adapter von AnythingLLM setzt diese Bestandteile zusammen. Eine kurze Frage kann deshalb eine große Anfrage erzeugen. Ein höherer Fensterwert in der Oberfläche vergrößert nicht die Fähigkeiten des serverseitigen Modells.

Ein Nutzer in Issue #6703 berichtete, zunächst Reverse-Proxy- und WebSocket-Timeouts untersucht zu haben, obwohl ein Ausgabelimit die Ursache war. Dieser einzelne Erfahrungsbericht spricht für die Reihenfolge der Prüfungen, beweist aber nicht dieselbe Ursache in deiner Installation.

Sichere die Konfiguration und identifiziere das tatsächlich verwendete Modell

Notiere den Ausgangszustand, bevor du etwas änderst. Halte AnythingLLM-Version, Desktop oder Self-Hosting, globalen Anbieter, Anbieter und Modell im Arbeitsbereich und Chat, Agent-Nutzung sowie Kontext- und Ausgabewerte fest. Verberge Schlüssel in Screenshots. Lösche für diesen Versuch weder den ursprünglichen Arbeitsbereich noch Unterhaltungen oder indexierte Dokumente.

Öffne in Settings die LLM-Anbieterkonfiguration und stelle sicher, dass der Test wirklich Generic OpenAI verwendet. Laut offizieller Anleitung müssen sowohl API-Funktionen als auch Inferenzantworten OpenAI-kompatibel sein. Läuft die Anfrage über einen anderen Anbieter, konfigurierst du diesen Weg nicht durch Änderungen an Generic OpenAI.

Der am 2026-10-16 gelesene offizielle Oberflächencode enthält folgende Felder:

Feld	Was du überprüfen solltest
Base URL, API Key, Selected Model	Die bisher funktionierende Adresse, den zugehörigen Schlüssel und die exakte Modellkennung; nicht vom Anzeigenamen auf die Kennung schließen
Model context window	Die konfigurierte Kontextkapazität, nicht das Budget der Antwort
Max Tokens	Das Generierungsbudget, getrennt vom Kontextwert

Speichere die Änderung und öffne die Einstellungen erneut, um ihre Übernahme zu prüfen. Hast du autorisierten Zugriff auf ausgehende Requests, kontrolliere auch den tatsächlichen model-Wert und das Ausgabelimit-Feld. Ein Screenshot belegt die Anzeige, nicht den Empfang beim Server. Teste normalen Chat und Agenten getrennt: Das Desktop-v1.16.2-Changelog dokumentiert eine Korrektur für bei Generic-OpenAI-Agent-Streams ignorierte max tokens.

Verwendest du bereits BetterToken, gleiche hier Adresse, Schlüssel und Modell mit der Chat-Completions-Anleitung ab; sie dient zur Konfigurationsprüfung, garantiert aber weder sämtliche AnythingLLM-Funktionen noch das Entfallen von Ausgabelimits.

Unterscheide Null, Parameternamen und Versionsverhalten

0 bedeutet nicht unbegrenzte Ausgabe. Laut Desktop-v1.17.0-Changelog kann Generic OpenAI mit 0 das Feld max_tokens aus der Anfrage weglassen. Dann greifen die Standardwerte und Grenzen des Servers. Ein ausdrücklich gesetztes positives Budget, das das Modell unterstützt, ist für einen nachvollziehbaren Vergleich meist geeigneter.

Im am 2026-10-16 gelesenen Adaptercode stammt der Ausgabewert aus GENERIC_OPEN_AI_MAX_TOKENS, der Kontextwert aus GENERIC_OPEN_AI_MODEL_TOKEN_LIMIT. Standardmäßig heißt das Ausgabefeld max_tokens; mit GENERIC_OPEN_AI_MODEL_MAX_TOKEN_KEY lässt sich ein anderer Name wählen. Das beschreibt den untersuchten Code, nicht garantiert identische Optionen in jeder installierten Version.

Benenne Parameter kompatibler APIs nicht pauschal um. Die aktuelle OpenAI-Referenz beschreibt max_completion_tokens: Dieses Budget umfasst sichtbare Ausgabe und Reasoning-Tokens. Wenig sichtbarer Text kann daher trotzdem ein ausgeschöpftes Budget bedeuten. Prüfe das von deinem Backend und Modell unterstützte Feld und ändere die entsprechende Einstellung nur bei Unterstützung durch deine Version.

Nutze auf Desktop die Oberfläche statt einer .env-Änderung aus einem kopierten Beispiel: Die offizielle Konfigurationsanleitung beschränkt diese Anweisungen auf Self-Hosting und Docker. In v1.17.0 änderte sich außerdem das Speichern von Arbeitsbereichseinstellungen. Prüfe die übernommenen Werte durch erneutes Öffnen, statt in jeder Version denselben Speicherknopf zu erwarten.

Wo du finish_reason und den tatsächlichen Verbrauch findest

Vorrang hat die Antwort der Modell-API an AnythingLLM. Prüfe bei nicht gestreamten Chat Completions choices[0].finish_reason und zurückgegebenes usage. Suche bei einem Stream den Chunk mit dem Abschlussgrund und kontrolliere, ob die vollständige Abschlusssequenz des Backends angekommen ist. Ein leeres Feld im ersten Chunk ist kein Endstatus. Siehe die offiziellen Antwortdefinitionen.

Öffne in der Weboberfläche das Network-Panel der Browser-Entwicklertools, aktiviere das Beibehalten des Protokolls und reproduziere den Fehler einmal. Notiere Zeit, Status und Antwort des Chat-Requests. Das zeigt die Strecke Browser–AnythingLLM, nicht unbedingt die ursprüngliche Antwort des Modelldienstes.

Der am 2026-10-16 gelesene Generic-OpenAI-Stream-Handler wandelt einen nicht leeren Abschlussgrund in AnythingLLMs eigene Nachricht mit close: true um, statt ihn unverändert an die Oberfläche weiterzugeben. Fehlen Verbrauchsdaten des Anbieters, enthält der Code außerdem eine Schätzung anhand gezählter Text-Chunks. Eine abgeschlossene Anzeige und eine Tokenzahl beweisen deshalb weder Vollständigkeit noch ein exakt erreichtes Budget.

Hole den ursprünglichen Grund und Verbrauch aus Modelldienst-Protokollen oder Request-Details, auf die du zugreifen darfst. Andernfalls gib dem Betreiber Zeitstempel und Kennung der Anfrage. Das Desktop-v1.16.2-Changelog beschreibt den Zugriff auf Protokolle und Speicher über die Versionsmarkierung oben im Fenster. Der Zugriff auf den Ordner bedeutet jedoch nicht, dass jede Version das ursprüngliche Abschlussfeld protokolliert.

Bei Streaming kann der Endverbrauch fehlen: OpenAI weist darauf hin, dass Unterbrechung oder Abbruch den letzten usage-Chunk verhindern können. Notiere dann „nicht verfügbar“, nicht null oder einen Verbrauch von null Tokens. Eine App-Schätzung ist kein Ersatz für Abrechnungsdaten.

Vergleiche kurze und lange Antworten mit gesicherter Ausgangskonfiguration

Fixiere zuerst den Anfrageweg und ändere dann die geforderte Antwortlänge. Nutze einen Testarbeitsbereich ohne angehängte Wissensdokumente. Wähle denselben Anbieter und dasselbe Modell und halte Systemprompt, Temperatur, Ausgabebudget und weitere Einstellungen konstant. Beginne jeden Test mit einem leeren Chat, damit der zweite nicht den ersten übernimmt. Teste zunächst normalen Chat ohne Agenten und Werkzeuge.

Kurzer Test A:

Nenne 3 Empfehlungen für die Verwaltung von Projektdokumentation. Schreibe jeweils 2–3 Sätze. Setze nach Abschluss [END] in eine eigene Zeile.

Langer Test B:

Nenne 20 Empfehlungen für die Verwaltung von Projektdokumentation. Schreibe jeweils 2–3 Sätze. Setze nach Abschluss [END] in eine eigene Zeile.

Sende die Nachricht und lasse die Generierung enden, ohne Stop zu drücken oder die Seite neu zu laden. Bei Timeout oder Abbruch notiere den Zeitpunkt, statt fortlaufend neue Versuche zu starten. Kopiere die vollständig angezeigten Antworten nach A.txt und B.txt. Erfasse zusätzlich Zeit, Modell, wirksames Budget, Abschlussgrund, ob usage vom Anbieter stammt, sowie das letzte nummerierte Element und [END]. Diese Zahlen definieren eine Testaufgabe, keine Modellgrenzen oder garantierten Antwortlängen.

Ist A vollständig und B nicht, zeigt das zunächst nur eine Schwierigkeit bei langer Ausgabe; Max Tokens ist damit noch nicht als Ursache bewiesen. Liefert B length, behalte seinen exakten Prompt und alle übrigen Einstellungen bei. Erhöhe nur das Budget auf einen expliziten, serverseitig zulässigen Wert und starte C in einem leeren Chat. Speichere C.txt. Alle 20 vollständigen Punkte, die Endmarkierung und ein Abschluss ohne length stützen die Wirksamkeit dieser Änderung in diesem Fall.

Funktioniert B bereits, erhöhe das Budget nicht unnötig. Vergleiche dieselbe reale Aufgabe im ursprünglichen und in einem leeren Chat bei gleichem Ausgabewert. Untersuche den Kontext, wenn das Problem zusammen mit Verlauf oder abgerufenen Passagen auftritt. Stelle nicht mehr benötigte Testwerte zurück und behalte die ursprünglichen Aufzeichnungen. Tests mit kostenpflichtigen APIs können reguläre Anfragekosten verursachen.

Korrigiere die belegte Ursache statt alle Schalter gleichzeitig

Ausgabelimit bestätigt: Budget ändern und übermitteltes Feld prüfen

Erhöhe nur das Budget des tatsächlich verwendeten Anfragewegs innerhalb der Modellgrenzen. Ändert sich die Anzeige, nicht aber der Request, prüfe Anbieterauswahl, Speicherung, Version und Unterschiede zwischen Chat und Agent. Ein größeres Kontextfenster repariert keine Ausgabeeinstellung, die nie beim Server ankam.

Kontext zu groß: Eingabe reduzieren, Aufgabe und Budget beibehalten

Wiederhole zuerst dieselbe lange Aufgabe in einem leeren Chat. Reduziere anschließend separat abgerufene Passagen oder unnötigen Verlauf. Meldet der Server ausdrücklich ein Kontextlimit, konfiguriere die tatsächliche Modellkapazität. Eine größere Zahl erweitert sie nicht. Ohne explizite Fehlermeldung bleibt eine Verbesserung im leeren Chat ein Hinweis auf eine noch zu prüfende Kontexthypothese.

Verbindungs- oder Streamfehler: Abbruchstelle vor Timeout-Änderungen finden

Vergleiche Browser-, AnythingLLM- und API-Protokolle desselben Zeitraums. Suche Abbrüche, Timeouts und geschlossene Verbindungen. Hat die API vollständig geantwortet, der Browser aber nur einen Teil empfangen, untersuche Transportweg und Darstellung dazwischen. Ist bereits die API gescheitert, bearbeite zuerst deren Fehler. Ändere das Timeout einer Schicht nur, wenn die Protokolle auf sie hinweisen.

Bei Self-Hosting oder Docker können Administratoren Streaming separat testen. Die offizielle Konfiguration bietet GENERIC_OPENAI_STREAMING_DISABLED="true" ausschließlich für Generic OpenAI; starte nach der Änderung den betreffenden Dienst oder Container neu. Führe denselben langen Prompt bei sonst identischen Bedingungen aus, stelle danach den alten Wert wieder her und starte erneut. Erfolg ohne Streaming grenzt die Suche auf streamingbezogene Wege ein, beweist aber keine Schuld des Proxys. Führe diese .env-Änderung nicht auf Desktop aus.

Prüfe den Erfolg und liefere bei weiterem Fehler verwertbare Daten

Eine längere Antwort allein genügt nicht. Prüfe alle geforderten Abschnitte oder Nummern, einen vollständigen letzten Satz und die Endmarkierung. Gleiche Abschlussgrund und Verbindungsprotokolle ab, um eine erneute Kürzung zu erkennen. Weder stop noch [END] ersetzen die Inhaltsprüfung. Wiederhole anschließend auch die reale Aufgabe, die ursprünglich fehlschlug, nicht nur den vereinfachten Kontrolltest.

Bleibt der Fehler, übermittle Version und Bereitstellungsart, Chat oder Agent, Anbieter- und Modellkennungen, bereinigte Einstellungen, Minimalprompt, Unterschiede zwischen A/B/C, Zeitstempel und den verfügbaren ursprünglichen Abschlussgrund. Entferne API-Schlüssel, Authentifizierungsheader und private Dokumentinhalte. Kennzeichne fehlende Felder als nicht verfügbar. Damit beginnt die nächste Untersuchung bei einer konkreten Anfrage statt bei weiteren spekulativen Proxy-Änderungen.