Context (please read)
I'm an active CodeWhale user, and I've been following the recent v0.8.67 work on multi-provider configuration (#3830, #3861). I wanted to share a use case that feels like a natural next step.
I'm not deeply familiar with the internal architecture or the full roadmap, and I'm relatively new to Rust (though I use LLM-assisted development). I'm open to the possibility of contributing if the feature is well-scoped and I can get some guidance—but realistically, this might be beyond my current skills, so consider this primarily a feature request.
If this is already on the roadmap somewhere, my apologies for the duplicate! If not, I hope it's useful food for thought.
The Use Case
I want to use LM Studio (local models) for quick edits, formatting, and simple queries, while using DeepSeek (or another cloud provider) for complex planning and multi-step reasoning—without manually switching providers mid-session.
Current Behavior
All sub-agents run on whatever provider is currently active in the parent session. I cannot assign different sub-agents to different providers.
LM Studio Integration Note
LM Studio exposes an OpenAI-compatible API endpoint (typically http://localhost:1234/v1). The new custom provider form in #3861 already supports adding OpenAI-compatible endpoints, so LM Studio can be added as a provider. However, it would be great to have LM Studio as a first-class supported provider (like Ollama or DeepSeek) with:
Automatic detection of the local endpoint
Pre-configured defaults
Better UI/UX for local model management
But even without that, the custom provider form should work—the missing piece is per-sub-agent routing.
Desired Behavior
Allow sub-agent definitions to specify a provider (and optionally a model) explicitly:
[subagents.explore]
role = "explorer"
provider = "lm-studio" # local for cheap, fast operations
model = "qwen-2.5-7b" # or whatever model you're running
[subagents.format]
role = "formatter"
provider = "lm-studio" # local for formatting/edits
model = "qwen-2.5-7b"
[subagents.review]
role = "reviewer"
provider = "lm-studio" # local for simple reviews
model = "qwen-2.5-7b"
[subagents.general]
role = "general"
provider = "deepseek" # cloud for complex reasoning
model = "deepseek-v4-flash"
When I call agent_open role="explore", the sub-agent launches on LM Studio. When I call agent_open role="general", it launches on DeepSeek—regardless of the parent's active provider.
Fallback Behavior
If a sub-agent doesn't specify a provider, it inherits the parent's active provider (current behavior). This maintains backward compatibility.
Why This Matters
Cost optimization: free local models for formatting/edits; pay only for cloud when needed
Latency: local models respond instantly for simple work
Privacy: keep file operations and simple edits local (no data sent to cloud)
Composability: one session can use multiple providers without manual switching
No "smart" routing needed: I want explicit assignment, not automatic classification
LM Studio specifically: many users run local models for development and testing
Not a Duplicate Of
Existing [subagents.providers.] profiles (in docs/SUBAGENTS.md) cap concurrency per provider. They don't route different sub-agents to different providers. This is a separate feature.
Relationship to Current Work
This builds directly on:
#3830 (provider/route manager) — makes multi-provider configuration possible
#3861 (custom provider setup) — allows adding LM Studio as an OpenAI-compatible endpoint
The existing custom provider form is sufficient, but first-class LM Studio support would be a nice bonus
Implementation Sketch (for discussion)
Extend SubagentDefinition struct with optional provider and model fields
Modify sub-agent spawn logic to use the specified provider if present
For custom model routes (from #3830), support provider = "custom" or explicit route strings
The runtime would need to maintain multiple provider clients simultaneously (one per active sub-agent)
Optionally: add LM Studio as a built-in provider with automatic endpoint detection
Potential Challenges
Maintaining multiple provider clients with independent auth/state
Ensuring provider clients are properly cleaned up when sub-agents finish
Handling the case where a specified provider isn't configured (graceful fallback or error)
UI/UX for showing which provider each sub-agent is using
Regarding Contribution
I'm open to taking a stab at this if it's well-scoped and I can get some pointers on where to start. However, I'm relatively new to Rust and the CodeWhale codebase, so I'd likely need significant guidance. If this is too complex or there are other priorities, I completely understand—consider this a feature request for the backlog.
I've read the CONTRIBUTING.md guide. I understand this feature likely touches areas like provider client management and auth state, which may be near the "trust-boundary surface." I'm open to this work being broken into smaller, layered PRs or being harvested by a maintainer if that's the preferred path. My primary goal is to see the feature land and to help however I can, whether that's through direct code, testing, or providing feedback on an implementation.
Context (please read)
I'm an active CodeWhale user, and I've been following the recent v0.8.67 work on multi-provider configuration (#3830, #3861). I wanted to share a use case that feels like a natural next step.
I'm not deeply familiar with the internal architecture or the full roadmap, and I'm relatively new to Rust (though I use LLM-assisted development). I'm open to the possibility of contributing if the feature is well-scoped and I can get some guidance—but realistically, this might be beyond my current skills, so consider this primarily a feature request.
If this is already on the roadmap somewhere, my apologies for the duplicate! If not, I hope it's useful food for thought.
The Use Case
I want to use LM Studio (local models) for quick edits, formatting, and simple queries, while using DeepSeek (or another cloud provider) for complex planning and multi-step reasoning—without manually switching providers mid-session.
Current Behavior
All sub-agents run on whatever provider is currently active in the parent session. I cannot assign different sub-agents to different providers.
LM Studio Integration Note
LM Studio exposes an OpenAI-compatible API endpoint (typically http://localhost:1234/v1). The new custom provider form in #3861 already supports adding OpenAI-compatible endpoints, so LM Studio can be added as a provider. However, it would be great to have LM Studio as a first-class supported provider (like Ollama or DeepSeek) with:
But even without that, the custom provider form should work—the missing piece is per-sub-agent routing.
Desired Behavior
Allow sub-agent definitions to specify a provider (and optionally a model) explicitly:
When I call agent_open role="explore", the sub-agent launches on LM Studio. When I call agent_open role="general", it launches on DeepSeek—regardless of the parent's active provider.
Fallback Behavior
If a sub-agent doesn't specify a provider, it inherits the parent's active provider (current behavior). This maintains backward compatibility.
Why This Matters
Not a Duplicate Of
Existing [subagents.providers.] profiles (in docs/SUBAGENTS.md) cap concurrency per provider. They don't route different sub-agents to different providers. This is a separate feature.
Relationship to Current Work
This builds directly on:
Implementation Sketch (for discussion)
Potential Challenges
Regarding Contribution
I'm open to taking a stab at this if it's well-scoped and I can get some pointers on where to start. However, I'm relatively new to Rust and the CodeWhale codebase, so I'd likely need significant guidance. If this is too complex or there are other priorities, I completely understand—consider this a feature request for the backlog.
I've read the CONTRIBUTING.md guide. I understand this feature likely touches areas like provider client management and auth state, which may be near the "trust-boundary surface." I'm open to this work being broken into smaller, layered PRs or being harvested by a maintainer if that's the preferred path. My primary goal is to see the feature land and to help however I can, whether that's through direct code, testing, or providing feedback on an implementation.