Fix Ollama Cloud Model maxTokens: Obergrenze ist 16K, nicht der Konfigurationswert

PSA für alle, die bei Produktions-Turns unexpected EOF von Agents sehen: Wenn eure openclaw.json Cloud-Modelleinträge wie { "id": "deepseek-v4-pro:cloud", "maxTokens": 500000 } enthält, ist dieses maxTokens nicht real. Ollama Cloud begrenzt die Ausgabe serverseitig auf 16.384 Token, unabhängig von eurer Konfiguration. Wenn ein Agent versucht, etwas darüber hinaus zu senden, beendet der Upstream die Verbindung mitten im Stream, und ihr seht einen Transportfehler von ollama.com:443. OpenClaw behandelt das als Timeout-Failover und versucht euren Fallback – aber wenn der Fallback ebenfalls ein :cloud-Modell ist, gilt die gleiche Grenze.

Was geholfen hat

• maxTokens bei Cloud-Einträgen korrigieren, damit OpenClaw keine Output-Budgets anfordert, die der Dienst nicht einhält:
  { "id": "deepseek-v4-pro:cloud", "maxTokens": 14000 }
{ "id": "kimi-k2.6:cloud", "maxTokens": 14000 }
  14k statt 16k – etwas Spielraum, da Modelle manchmal direkt am Limit seltsam reagieren.
• Große strukturierte Ausgaben umstrukturieren (lange JSONs, mehrteilige Inhalte), sodass ein Abschnitt pro Turn ausgegeben wird, anstatt alles in einem Stapel zu verarbeiten. Bleibt unter der Grenze und Wiederholungen sind sauberer.
• Schwere Agents direkt an einen Anbieter leiten über einen Pro-Agent-Modell-Override in agents.list[], statt über :cloud. Agents mit kleinen Ausgaben bleiben auf Ollama Cloud. Einmalige Einrichtung:
  openclaw onboard --auth-choice deepseek-api-key
  Dann in agents.list die benötigten überschreiben:
  "list": [ { "id": "your-agent", "model": "deepseek/deepseek-v4-pro" } ]
  Kompromiss: Abrechnung pro Token statt Pauschalgebühr, aber beschränkt auf Agents, die Spielraum benötigen.

Fazit

Wenn eure Agents mitten in langen Ausgaben fehlschlagen und ihr die offensichtlichen Dinge geprüft habt, schaut euch das tatsächliche Output-Limit eures Anbieters an, bevor ihr euch im OpenClaw-Bug-Kaninchenbau verliert. Die Fehlermeldung ist nutzlos und das Konfigurationsfeld verrät nicht, dass es serverseitig überschrieben wird.