[Feature]: Native Local Decision Layer for Agent Routing & Runtime Control

Product or interface

CLI - interactive TUI

Use case and problem

I want the CLI to feel much faster and smarter at runtime by reducing how often the main model is used for small repeated routing decisions.

Right now, the main model may end up spending time on many control-plane decisions around a task, not just the actual hard reasoning. Examples include:

• understanding user intent
• deciding whether old context is needed
• deciding whether to look at history, memory, logs, files, web, or Git
• deciding which tools / MCPs / Skills are relevant
• deciding whether a subagent should be created
• deciding whether work can run in parallel
• deciding whether a tool result is useful, duplicate, noisy, or needs verification
• deciding whether to continue, retry, verify, compact, wait, or escalate
• deciding how a new queued user message should affect the running task

Some of these decisions truly need the main model, but many are repeated bounded decisions with a small set of valid outcomes.

The current limitation is that as the CLI grows in tools, Skills, MCPs, subagents, memory, and context sources, more runtime decisions may get pushed upward into expensive model reasoning even when the harness could handle many of them locally.

I do not think using a separate external router model is the best solution, because that just adds another model call, network hop, dependency, and failure point.

What I am trying to suggest is a native local decision layer inside the CLI/runtime itself, so the main model is used mainly for actual intelligence and hard reasoning, while the harness handles more of the repeated routing and control decisions on its own.

In short: the main problem is not only model speed, but that too many small runtime decisions may still depend on the main model when they could be handled more cheaply and consistently inside the core CLI.

Desired behavior

I would like MiniMax Code to add a native local decision layer inside the core agent harness.

The idea is simple:

User request
→ fast local harness decisions
→ prepare only the right context/tools/skills
→ call the main model when real reasoning is required
→ tools/subagents execute
→ local harness decides routine next steps
→ call the main model again only when necessary

This should not use another remote model or API. It should be built directly into the runtime so there is no extra network round-trip.

Examples of decisions this layer could handle:

• Intent: CHAT / CODE / DEBUG / RESEARCH / CONTINUE
• Context: HISTORY / MEMORY / FILES / LOGS / WEB / NONE
• File search: EXACT / SEMANTIC / SYMBOL / IMPORT_GRAPH / RECENT
• Capability routing: TOOL / MCP / SKILL / SUBAGENT / NONE
• Tool results: KEEP / DROP / DUPLICATE / VERIFY / RETRY
• Subagents: PARALLEL / WAIT / DUPLICATE / CANCEL
• Queue messages: MERGE / STEER / INTERRUPT / NEXT_TURN
• Compaction: NONE / TRIM / CHECKPOINT / FULL_COMPACT
• Execution: CONTINUE / VERIFY / WAIT / CALL_MAIN_MODEL

Example:

Before:

User
→ main model decides intent
→ main model decides what context to search
→ main model chooses tools
→ tool runs
→ main model decides what to do next
→ another tool
→ main model again

After:

User
→ native local router identifies intent/context/capabilities
→ main model receives only what is relevant
→ tool/subagents run
→ native router handles obvious routing/deduplication/retry/queue decisions
→ main model is called only when actual intelligence is needed

Important requirements:

• no external router model
• no additional network request
• extremely low local overhead
• current behavior remains the fallback
• uncertain decisions immediately fall back to the main model
• permissions and safety remain authoritative
• local routing must never invent arbitrary commands, code, paths or tool arguments
• each decision domain should be independently testable
• skipped model calls and token/context savings should be measurable

The goal is not to replace the main model.

The goal is to let the model focus on reasoning while the harness handles routine routing, scheduling and context-management decisions itself.

Platform

Multiple platforms

Alternatives and additional context

I first considered using a separate very fast router model for these decisions, but that creates its own overhead:

CLI runtime
→ network call
→ router model
→ response
→ main model

That adds latency, another dependency, another failure point, and another model/API request.

The more interesting solution is to make this part of the MiniMax Code harness itself:

runtime state
→ local decision
→ execute locally when safe
→ main model only when real reasoning is required

I also would not suggest one giant opaque classifier.

A better design would be a shared local decision framework with many small, typed decision domains, each independently testable and able to fall back to the main model.

For example:

intent:
CHAT / CODE / DEBUG / RESEARCH / CONTINUE / OTHER

context:
NONE / HISTORY / MEMORY / FILES / LOGS / MULTIPLE

retrieval:
EXACT / SEMANTIC / SYMBOL / IMPORT_GRAPH / RECENT / ESCALATE

result:
KEEP / DROP / DUPLICATE / VERIFY / ESCALATE

queue:
STEER / MERGE / INTERRUPT / NEXT_TURN / ESCALATE

execution:
CONTINUE / WAIT / VERIFY / CALL_MAIN_MODEL

The goal is not to reduce model intelligence.

The goal is to stop spending expensive model reasoning on control-plane decisions the harness can already make reliably itself.

I think this could become a fundamental runtime improvement as MiniMax Code grows in tools, MCPs, Skills, Plugins, memory, context sources, subagents and workflows.

The issue names no files, tests, or runtime entry points, so begin by locating the CLI agent harness and its existing routing and control flow. Define the decision domains and fallback boundaries before implementation; done would include independently testable local decisions, main-model fallback, preserved safety, and measurements of skipped calls and context savings.