#How to set model priorities

1 messages · Page 1 of 1 (latest)

balmy patrol
#

Can I assign one model to light tasks and another to heavy tasks?

Also, what are the criteria for determining whether a task is light or heavy?

Can I add an orchestrator model?

Could you please explain the specifications for using multiple AI models?

limpid mantleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

sudden pewterBOT
#

Yes — but OpenClaw does it by routing, not by an automatic built-in “light/heavy task classifier”.

Supported patterns today:

  • Default + fallbacks: set agents.defaults.model.primary and ordered agents.defaults.model.fallbacks. Fallbacks are mainly for failover/rate-limit/reachability, not “use cheap model first for easy tasks”.
  • Per-agent models: create multiple agents, each with its own agents.list[].model, workspace, auth, and routing. Example: one general/coordinator agent, one coding agent, one cheap summarizer agent.
  • Sub-agents: the main agent can spawn workers. You can set a default sub-agent model with agents.defaults.subagents.model, or per-agent with agents.list[].subagents.model.
  • Cron/job overrides: cron payloads can specify a model per job.
  • Tool-specific models: imageModel, pdfModel, imageGenerationModel, etc. are separate from the normal chat/agent model.
  • Manual switching: /model changes the current session model.

“Light” vs “heavy” is not a fixed OpenClaw threshold. A practical split is:

  • Light: short Q&A, formatting, summaries, classification, simple extraction, low-risk routine chat.
  • Heavy: tool use, code changes, debugging, planning across many files, long context, browser/workflow automation, anything security-sensitive or prompt-injection-prone.

Yes, you can add an orchestrator model. Usually that means making your main/coordinator agent use a strong model, then delegating to sub-agents with different models. The orchestrator decides when to spawn/delegate; OpenClaw doesn’t currently expose a separate magical “orchestrator model” field distinct from an agent/sub-agent model.

Docs:

balmy patrol
#

日本語での説明は可能ですか

sudden pewterBOT
#

もちろんです!日本語で説明します。

結論として、OpenClaw では 軽いタスク用モデル / 重いタスク用モデル を完全自動で振り分ける専用の「軽量・重量判定システム」があるわけではありません。代わりに、エージェント分け・サブエージェント・ジョブごとのモデル指定で使い分けます。

主な方法はこれです:

  1. デフォルトモデル + フォールバック

    • agents.defaults.model.primary に通常使うモデルを設定
    • fallbacks に代替モデルを設定
    • これは主に失敗時・レート制限時の切り替え用で、「軽い作業だから安いモデルへ」という自動分類ではありません。
  2. エージェントごとにモデルを変える

    • 例:
      • メイン/調整役エージェント → 強いモデル
      • 要約用エージェント → 安いモデル
      • コーディング用エージェント → コードに強いモデル
    • agents.list[].model で個別に設定できます。
#
  1. サブエージェントに別モデルを使わせる

    • 長い作業や並列作業をサブエージェントに任せられます。
    • agents.defaults.subagents.model で、サブエージェントの標準モデルを設定できます。
  2. Cron/ジョブごとにモデル指定

    • 定期実行ジョブには個別に model を指定できます。
  3. 画像・PDFなど専用モデル

    • imageModel
    • pdfModel
    • imageGenerationModel
      などは通常の会話モデルとは別に設定できます。

「軽いタスク」と「重いタスク」の目安は:

軽いタスク

  • 短い質問への回答
#
  • 要約
  • 文章の整形
  • 翻訳
  • 簡単な分類
  • 低リスクな日常会話

重いタスク

  • コード修正
  • デバッグ
  • 複数ファイルの調査
  • 長い文脈を読む作業
  • ツールを使う作業
  • ブラウザ操作
  • セキュリティや設定に関わる作業
  • 間違えると困る重要な判断

オーケストレーターモデルについては、はい、近い構成はできます。

#

おすすめは:

  • メインエージェントを「調整役 / orchestrator」として強めのモデルにする
  • 実作業をサブエージェントに振り分ける
  • サブエージェントごとに安いモデル・強いモデル・専門モデルを使い分ける

ただし、OpenClaw に「orchestratorModel」という専用フィールドがあるわけではなく、基本的には メインエージェント + サブエージェント構成で実現します。

参考 docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/multi-agent
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/help/faq-models

balmy patrol
#

メイン+サブのエージェントについてどのような設定ができるのかについてより詳しく教えてください

sudden pewterBOT
#

はい、もう少し具体的に説明します。

OpenClaw の「メイン+サブエージェント」は、大きく分けると 2種類の設計があります。

1. メインエージェント + 同じエージェント内のサブエージェント

これは一番シンプルです。

メインエージェントが普段の会話を担当し、重い作業だけ sessions_spawn でサブエージェントに投げます。

設定できる主な項目:

{
  agents: {
    defaults: {
      model: {
#
        primary: "provider/strong-model",
        fallbacks: ["provider/fallback-model"]
      },
      subagents: {
        model: "provider/cheap-or-worker-model",
        delegationMode: "prefer",
        maxConcurrent: 4,
        runTimeoutSeconds: 900,
        archiveAfterMinutes: 60
      }
    }
  }
}

意味:

#
  • agents.defaults.model.primary → メインエージェントの通常モデル
  • agents.defaults.model.fallbacks → 失敗時の代替モデル
  • agents.defaults.subagents.model → サブエージェントの標準モデル
  • delegationMode: "prefer" → メインに「複雑な作業はサブに任せる」よう促す
  • maxConcurrent → 同時に走れるサブエージェント数
  • runTimeoutSeconds → サブエージェント1回の最大実行時間
  • archiveAfterMinutes → 完了後どれくらいで自動アーカイブするか

注意点として、delegationMode は「強制ルール」ではなく、プロンプト上のガイダンスです。モデルが必ず従う保証ではありません。

2. 複数エージェント構成:メイン / coding / research / summary など

より本格的に分けるなら、複数の agentId を作ります。

例:

#
{
  agents: {
    defaults: {
      subagents: {
        allowAgents: ["coding", "research", "summary"],
        requireAgentId: false
      }
    },
    list: [
      {
        id: "main",
        workspace: "~/.openclaw/workspace-main",
        model: "provider/orchestrator-model",
        subagents: {
          delegationMode: "prefer",
#
          allowAgents: ["coding", "research", "summary"]
        }
      },
      {
        id: "coding",
        workspace: "~/.openclaw/workspace-coding",
        model: "provider/code-model"
      },
      {
        id: "research",
        workspace: "~/.openclaw/workspace-research",
        model: "provider/research-model"
      },
      {
        id: "summary",
#
        workspace: "~/.openclaw/workspace-summary",
        model: "provider/cheap-summary-model"
      }
    ]
  }
}

この構成だと:

  • main → オーケストレーター / 会話の入口
  • coding → コード調査・修正向け
  • research → Web調査・資料整理向け
  • summary → 要約・軽作業向け

というように分担できます。

#

エージェントごとに分けられるもの

複数エージェントでは、かなり多くを分離できます。

  • モデル
  • workspace / AGENTS.md / SOUL.md / USER.md
  • auth profiles
  • session history
  • skills allowlist
  • tools allow/deny
  • channel account binding
  • sub-agent delegation policy

つまり、単にモデルを変えるだけでなく、「性格・権限・記憶・使えるツール」も分けられます。

サブエージェント spawn 時に指定できるもの

実行時には、サブエージェントごとに以下も指定できます:

#
  • agentId → どのエージェントに投げるか
  • model → その実行だけモデルを上書き
  • thinking → thinking レベル
  • runTimeoutSeconds → タイムアウト
  • context: "isolated" | "fork"
    • isolated = 新しい文脈で実行
    • fork = 現在の会話文脈を引き継ぐ
  • thread: true → Discord thread に紐づける
  • mode: "run" | "session"
    • run = 1回だけ
    • session = 継続セッション

オーケストレーター構成について

「メインが判断して、必要なら専門サブに投げる」という形が現実的です。

さらに高度にすると:

#
{
  agents: {
    defaults: {
      subagents: {
        maxSpawnDepth: 2,
        maxChildrenPerAgent: 5,
        maxConcurrent: 8
      }
    }
  }
}

これで、

main → orchestrator sub-agent → worker sub-agents

#

のような2段階構成も可能です。ただしトークン消費が増えるので、最初は main → worker の1段階がおすすめです。

実用的なおすすめ

最初はこれで十分です:

  • メイン:強めのモデル
  • サブエージェント標準:少し安いモデル
  • コーディングや重要作業だけ、明示的に強い専門モデルへ投げる

その後、必要になったら coding / research / summary のように複数エージェント化すると扱いやすいです。

Docs:
https://docs.openclaw.ai/tools/subagents
https://docs.openclaw.ai/concepts/multi-agent
https://docs.openclaw.ai/concepts/models

balmy patrol
#

メイン+サブエージェント構成にした時にメインサブそれぞれにフォールバックモデルをつけることもできますか?

sudden pewterBOT
#

はい、できます。

OpenClaw の model は基本的に 文字列 でも { primary, fallbacks } オブジェクト でも指定できます。なので、メインにもサブにもそれぞれフォールバックを持たせられます。

例:

{
  agents: {
    defaults: {
      // メインエージェントのモデル
      model: {
        primary: "provider/main-strong-model",
        fallbacks: [
          "provider/main-fallback-1",
          "provider/main-fallback-2"
#
        ]
      },

      // サブエージェントの標準モデル
      subagents: {
        model: {
          primary: "provider/sub-cheap-model",
          fallbacks: [
            "provider/sub-fallback-1",
            "provider/sub-fallback-2"
          ]
        }
      }
    }
  }
#
}

この場合:

  • 通常会話・メイン処理 → main-strong-model
  • メインモデルが失敗/制限/利用不可 → main-fallback-*
  • サブエージェント → sub-cheap-model
  • サブモデルが失敗/制限/利用不可 → sub-fallback-*

という流れになります。

複数エージェントに分ける場合も、各エージェント側で個別にできます:

#
{
  agents: {
    list: [
      {
        id: "main",
        model: {
          primary: "provider/orchestrator-model",
          fallbacks: ["provider/orchestrator-fallback"]
        },
        subagents: {
          allowAgents: ["coding", "summary"]
        }
      },
      {
        id: "coding",
#
        model: {
          primary: "provider/code-model",
          fallbacks: ["provider/code-fallback"]
        }
      },
      {
        id: "summary",
        model: {
          primary: "provider/cheap-summary-model",
          fallbacks: ["provider/summary-fallback"]
        }
      }
    ]
  }
}