Feature Request: Dynamic Executor Model Routing with Cost-Aware Escalation

[saikethan27]

It would be useful for LongHorizon-Harness to support multiple executor model tiers and dynamically select between them based on task complexity, risk, and previous execution/audit results.

Currently, different models/backends can be configured for roles such as Manager, Executor, and Auditor. However, the Executor itself could benefit from dynamic routing between a cheaper model and a stronger/more expensive model.

For example:

Manager (Strong Model)
        |
        v
  Analyze next task
        |
   +----+----+
   |         |
 Simple     Complex
   |         |
   v         v
Cheap      Strong
Executor   Executor
   |         |
   +----+----+
        |
        v
   Strong Auditor
        |
   +----+----+
  PASS      FAIL
   |         |
Continue   Retry / Escalate
             |
             v
       Strong Executor

Proposed Behavior

Allow multiple executor tiers to be configured, for example:

[run.roles.executor.cheap]
agent = "codex"
model = "<cheap-model>"

[run.roles.executor.strong]
agent = "claude_code"
model = "<strong-model>"

The Manager could optionally specify the required executor tier when creating the next task:

{
  "next_task": "Refactor the authentication architecture",
  "executor_type": "cli",
  "executor_tier": "strong"
}

For normal tasks:

{
  "next_task": "Add unit tests for the user service",
  "executor_type": "cli",
  "executor_tier": "cheap"
}

Automatic Escalation

In addition to Manager-based routing, it would be valuable to support automatic escalation when the cheaper executor fails verification.

For example:

Cheap Executor
      |
      v
   Auditor
      |
    FAIL
      |
      v
Cheap Executor Retry
      |
      v
   Auditor
      |
    FAIL
      |
      v
Strong Executor

Possible configuration:

[run.executor_routing]
default_tier = "cheap"
escalate_after_failures = 2
escalation_tier = "strong"

This prevents relying entirely on the Manager's ability to predict task difficulty. Most tasks can start with the cheaper model, while difficult tasks naturally escalate when necessary.

Motivation

In long-horizon coding tasks, Executors can consume significantly more tokens than the Manager because they repeatedly:

• Read relevant repository files
• Write/edit code
• Run commands and tests
• Inspect errors
• Iterate on implementations

Using the strongest model for every executor round can therefore become expensive.

A cost-aware architecture could use:

Manager        -> Strong model
Default Exec   -> Cheap model
Complex Exec   -> Strong model
Auditor        -> Strong model

This keeps planning and verification reliable while allowing high-volume implementation work to use cheaper models whenever possible.

It would also enable combinations such as:

Manager         -> Claude Code / strong model
Cheap Executor  -> Codex / cheaper model
Strong Executor -> Claude Code / strong model
Auditor         -> Claude Code / strong model

The routing should ideally be backend-agnostic so users could configure any supported AgentAdapter for each tier.

Questions

1. Is dynamic executor model routing already possible through the current architecture but not documented?
2. Would maintainers be open to adding executor tiers such as cheap / strong?
3. Would automatic escalation based on Auditor failures fit the intended LongHorizon architecture?
4. Should executor-tier selection be made by the Manager, deterministic routing logic, or a combination of both?

I would be interested in contributing this functionality if it aligns with the project's design.

[Upper9527]

Thanks for the thoughtful proposal. We agree that executor tiering and dynamic routing would be valuable for LongHorizon-Harness.

The current architecture is capable of supporting dynamic routing, and this is also one of the areas we plan to work on next. We would be open to an executor-tier design such as cheap and strong, while keeping the routing backend-agnostic so that each tier can use any supported AgentAdapter.

We also believe that automatic escalation based on repeated Auditor failures fits the intended LongHorizon architecture. A reasonable design would be for the Manager to choose the initial executor tier, since it determines the next task and has the context needed to judge which model the task requires. Auditor-driven escalation could then act as a fallback when the initially selected tier repeatedly fails verification.

In other words:

• The Manager selects the initial executor tier.
• The Auditor provides verification signals.
• The harness automatically escalates after repeated failures.

We plan to continue evolving LongHorizon toward stronger multi-agent collective intelligence and Self-Harness capabilities. Contributions in this direction would be very welcome.