#Main model to use for orchestrator

1 messages · Page 1 of 1 (latest)

fluid void
#

I want to interact with one agent which will delegate tasks to other agents, or occasionally take one-off tasks on its own. What is the best model to use currently? Local or premier model? If premier, which one?

torn wrenBOT
#

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

river folioBOT
unborn slateBOT
#

Let me verify the FAQ path, then I’ll answer with the current docs-backed guidance.

#

For that pattern, I’d use a premier cloud model as the orchestrator.

Short version:

  • Main/orchestrator agent: strongest latest-gen hosted model you can afford
  • Sub-agents / routine work: cheaper fallback or cheaper sub-agent model
  • Local models: fine for experimenting, but I would not make them the primary delegating/orchestrating agent unless you have very strong hardware and can tolerate worse tool use / context / reliability

That matches the docs pretty closely:

  • for tool-enabled agents, prioritize strength over cost
  • use a cheaper model for routine chat/summaries/sub-agents
  • local models are usually not the best default for this kind of work

Docs:

#

For the exact premier model/provider right now, ask in #models. That answer changes fast, and the community there will be more current than anything static I can say here.

If you want, I can also suggest a practical setup for:

  1. one premium orchestrator,
  2. one cheaper worker model,
  3. fallback ordering.
fluid void
#

That would be helpful. Also, just to note, I have a powerful Mac Studio with 64 GB of RAM, so I would like to utilize that for perhaps browsing and parsing HTML and summarization

unborn slateBOT
#

I’m going to sanity-check the local-model and node docs, then I’ll give you a concrete setup.

#

Yep, with that hardware I’d go hybrid.

What I’d do:

  1. Use a premier hosted model for the main/orchestrator agent

    • this is the part doing delegation, tool selection, error recovery, longer-context reasoning
    • I still would not make a single 64 GB Mac Studio the primary orchestrator model

  2. Use the Mac Studio for tools

    • browser work
    • HTML fetch / parsing
    • screenshots / page inspection
    • local exec / automation
    • this is a great use of the machine

  3. Optionally use a local model on the Mac Studio for low-stakes worker tasks

    • summarization
#
  • extraction
    • classification / chunking
    • maybe draft transforms
    • but keep a hosted fallback for anything important or tool-heavy

So the practical setup is:

  • Primary model: strongest hosted model you have access to
  • Sub-agent model: cheaper hosted model, or local model for summarization/extraction workers
  • Mac Studio role: node/browser/automation box, and maybe local LM Studio box

Why I’m saying that:

  • the docs recommend the strongest latest-gen model for tool-enabled agents
  • local models are still generally weaker for orchestration and prompt-injection resistance
  • the local-model docs are pretty blunt that true “best local” agent performance wants much more than one good desktop

For your exact use case, I’d spend the Mac Studio’s power on execution, not on being the “boss brain”.

#

Good pattern:

  • orchestrator: premium hosted
  • HTML/page workers: local or cheaper hosted
  • browser/exec: Mac Studio node

Useful docs:

If you want, next I can sketch a concrete configuration layout for:

  • premium orchestrator
  • local LM Studio worker