How AIClaw Splits Main and Fast Models for Sub-Agent Work

AIClaw is not just a chat wrapper around one model. In the current repository, it lets you configure multiple providers, choose a primary model per agent, and optionally assign a separate fast model for lightweight sub-agent work.

That matters because real agent runs are uneven. Some steps need a stronger model for planning or synthesis. Other steps are small delegated tasks: inspect a few files, try a shell command, summarize one branch of research, or explore a URL. Running every delegated step on the same expensive model is the simple design, but usually not the practical one.

The Problem

When an agent can call sub_agent, the main task and the delegated task often have different cost and latency requirements.

• The parent agent may need the best reasoning model you have.
• The child task may only need a cheaper and faster model.
• You still want both to stay inside the same agent definition and provider setup.

AIClaw addresses that by separating:

• the primary model used by the agent, and
• an optional fast model reserved for lightweight sub-agent execution.

The repository states this directly in the README:

Each provider can define its base URL, API key, and model list. Agents choose a provider model and can optionally define a fast model for lightweight sub-agent tasks.

How The Provider Layer Is Structured

In the current codebase, AIClaw supports multiple provider types, including:

• OpenAI
• OpenAI-compatible APIs
• Qwen
• Kimi / Moonshot
• OpenRouter
• Claude
• Gemini

Those provider definitions live in the backend model layer, and each provider stores:

• a name
• a provider type
• a base URL
• an API key
• a model list

This is not a hardcoded single-vendor path. It is meant to let one deployment route different agents through different model backends while preserving a unified agent workflow.

What The Web Console Exposes

The admin console has a dedicated Providers page for managing model backends, and the Agent form consumes those provider definitions.

Two parts of the UI are especially useful here:

1. The Providers page can fetch remote model lists from the configured provider endpoint.
2. The Agent form lets you choose both a primary model and an optional fast model from the same provider.

The current provider UI merges remote and local model lists, and the agent editor exposes:

• 主模型 / main model
• 快速模型 / fast model

The tooltip for the fast model is explicit: it is the lightweight model used when a sub-agent is invoked with model=fast, and if left empty it falls back to the main model.

How The Runtime Uses The Fast Model

The interesting part is that this is not only a configuration field. The runtime actually switches models during delegated execution.

In internal/agent/subagent.go, AIClaw checks the sub-agent model hint before running the delegated task:

if modelHint == "fast" && ec.ag.FastModelName != "" {
    ec.ag.ModelName = ec.ag.FastModelName
}

So the parent agent can keep its primary model, while the child execution swaps to the fast model only for that delegated run.

That keeps the behavior predictable:

• no extra provider objects are needed just to optimize sub-agent cost
• the parent and child stay within the same agent configuration
• the optimization is explicit instead of hidden behind heuristics

Why This Design Is Practical

This design works well for common agent patterns:

• Deep reasoning in the parent, fast exploration in children
• Expensive final synthesis, cheap parallel research branches
• One provider account, multiple model tiers

For example:

• Set the main model to gpt-4.1, claude-sonnet, or another stronger general model.
• Set the fast model to something like gpt-4o-mini or another lower-latency option from the same provider.
• Let delegated sub_agent tasks use model=fast when they are mostly collecting facts or doing narrow execution.

That gives you a more controllable tradeoff than “always use the big model” or “force every agent to be cheap.”

Why I Picked This Feature

Today’s article is not based on a brand-new release commit. Instead, it is a deeper look at an existing AIClaw capability that is already concrete in the repository and easy to miss if you only skim the README.

Recent drafts already covered runtime plan state, execution logs, skills, and channel session continuity. This provider-and-fast-model path is a different product surface and a useful one if you are designing multi-step agents that need cost control without losing structure.

Practical Workflow In AIClaw

A clean setup looks like this:

1. Add a provider in the Providers page with base URL, API key, and model list.
2. Fetch remote models from that provider when available.
3. Create or edit an agent.
4. Pick the main model for the parent task.
5. Optionally pick a fast model for lightweight sub-agent tasks.
6. Let the agent delegate narrow work through sub_agent.

Because AIClaw keeps sub-agent traces visible in the parent timeline, this remains observable instead of becoming a black box.

Closing

Many agent products talk about orchestration, but the useful details are usually in the runtime tradeoffs. AIClaw’s provider setup plus fast-model override is a good example of a small design choice that improves real-world agent operation: better latency and cost control without splitting your workflow across multiple disconnected agents.

If you are building with AIClaw, this is one of the settings worth using early instead of treating every subtask like it deserves your heaviest model.