Ollama CloudモデルのmaxTokens修正:上限は16K、設定値ではない

本番ターンでunexpected EOFが発生するエージェントがいる方へ:openclaw.jsonに{ "id": "deepseek-v4-pro:cloud", "maxTokens": 500000 }のようなクラウドモデルのエントリがある場合、そのmaxTokensは実際には機能しません。Ollamaクラウドは、設定にかかわらずサーバー側で出力を16,384トークンに制限します。エージェントがそれを超える出力を試みると、上流が途中でソケットを切断し、ollama.com:443からのトランスポートエラーが発生します。OpenClawはこれをタイムアウトとして扱いフォールバックを試みますが、フォールバックも:cloudモデルであれば同じ壁にぶつかります。
対策
- クラウドエントリのmaxTokensを修正して、OpenClawがサービスで利用できない出力予算を要求しないようにする:
{ "id": "deepseek-v4-pro:cloud", "maxTokens": 14000 }
{ "id": "kimi-k2.6:cloud", "maxTokens": 14000 }
14k(16kではありません)— 上限ぎりぎりでモデルが不安定になるのを避けるために余裕を持たせます。 - 大きな構造化出力(長いJSON、複数セクションのコンテンツ)を、一度にまとめて出力するのではなく、ターンごとに1セクションずつ出力するように再構成します。上限を下回り、リトライもスムーズになります。
- 負荷の大きいエージェントを直接プロバイダーにルーティングするには、
agents.list[]でエージェントごとにモデルを上書きし、:cloudを経由しないようにします。小出力のエージェントはOllamaクラウドに残します。一度の設定:
openclaw onboard --auth-choice deepseek-api-key
その後、agents.listで必要なエージェントを上書き:
"list": [ { "id": "your-agent", "model": "deepseek/deepseek-v4-pro" } ]
トレードオフ:定額ではなくトークン課金になりますが、余裕が必要なエージェントに限定できます。
まとめ
エージェントが長い出力の途中で失敗し、明らかな原因を確認したなら、OpenClawのバグを探す前に、プロバイダーの実際の出力上限を確認しましょう。エラーメッセージは役に立たず、設定フィールドもサーバー側で上書きされていることを教えてくれません。
📖 出典全文: r/openclaw
👀 See Also
クロードの不要な要約問題:70%の確率で機能するユーザーの回避策
ユーザーはClaudeが完璧な回答をした後、冗長な要約を追加することに不満を感じている。プロンプトに「要約不要、まとめ不要、終わったら停止」と追加することで、約70%の確率で問題が解決する。

モデル切り替えでOpenClawエージェントコストを80%削減する方法
あるユーザーが14日間にわたりトークン使用量を追跡したところ、支出の67%が、安価なFlashモデルがOpusと同等の品質を発揮するタスクに充てられていることが判明しました。デフォルトをFlashに切り替え、セッション中に/modelを使用することで、月額コストを約170ドルから約35ドルに削減できました。

非コーダーが創業者向けコンテンツマーケティングのための再利用可能なClaudeワークフローを構築した方法
プログラミング未経験の元雑誌編集者が、どのようにして意図せず再現可能なClaudeワークフローを構築し、ソロファウンダーのコンテンツマーケティングに活用しているかを共有する。生の思考を吐き出し、Claudeでプラットフォーム別のフォーマットに再構成する方法。

同一リファクタリングにおいて、ルーティングエージェントのサブタスクを安価なモデルに振り分けることでコストが18ドルから4ドルに削減
開発者は、ルーティン的なサブタスク(lint、リネーム、設定編集など)をDeepSeek V4 ProやTencent Hunyuan Hy3といった安価なモデルに振り分け、複雑な推論にはOpus 4.7を予約することで、エージェントの実行コストを18ドルから4ドルに削減しました。