Feature Request: Choose the Execution Provider When Creating a Kanban Task

[malys]

Summary

When creating a Kanban task, it should be possible to immediately select which AI provider will execute the work.

For example:

• Claude
• Codex
• Gemini
• OpenAI
• Local Agent
• Custom Provider

This would avoid creating the task first and then modifying the associated session.

Current Behavior

1. Create a Kanban task.
2. A chat/session is created using the default configuration.
3. User must manually adjust settings afterward (when possible).

Expected Behavior

During task creation:

New Task

Title:
[________________]

Provider:
[ Codex ▼ ]

Model:
[ Auto ▼ ]

Reasoning:
[ Medium ▼ ]

Agent:
[ Developer ▼ ]

Dynamic Configuration

Providers, models, and effort levels should be loaded dynamically.

Examples:

Provider
- Claude
- Codex
- Gemini
- OpenAI
- ...

Model
- Auto
- Sonnet
- Opus
- Codex Sol
- Codex Terra
- GPT-5
- ...

Reasoning
- Low
- Medium
- High
- Maximum
- ...

The UI should not hardcode specific values since available options can change between releases.

Task Templates

Allow task templates such as:

Bug Fix
→ Codex
→ High Effort

Documentation
→ Claude Sonnet
→ Medium Effort

Architecture Review
→ Claude Opus
→ High Effort

Kanban Visibility

Display execution settings directly on the card:

[Codex]
[Terra]
[High]

or

[Claude]
[Opus]

Benefits

• Faster workflow.
• Better cost control.
• Better model selection based on task type.
• No need to edit the session after task creation.
• Makes delegated and autonomous workflows easier to manage.

Priority

High

Use Case

As a user, I want to select the execution

[Lexus2016]

Thanks — this is a good request, and it splits into four parts that have very different answers. Taking them one at a time.

1. Model / reasoning / agent at creation time — already shipped

This landed in v7.13.0 (#76 → PR #78, plus #79 → PR #80). The Kanban create-task modal already carries Mode, Agent, Model, Engine (API / Subscription), Bot, Turns and Effort, and those dials are read off the task row on every run — so they stay editable after the task has a session, which was the "modify the associated session afterwards" pain you describe. If you are on ≥ 7.13.0 and do not see them, that is a bug and I would like a screenshot.

2. Settings visible on the card — fixed, PR #85

Your "Kanban Visibility" section was genuinely missing, and the existing badge was worse than missing: the card rendered sess_model only, so it was blank on a task that had never run, and wrong for any task assigned to a bot (a bot's model overrides the session's inside the runner). PR #85 replaces it with the chain the runner actually resolves:

model  = bot.model || session.model || task.model || 'sonnet'
effort = task.effort      (rendered only when not "auto")
engine = task.run_engine  (rendered only when "subscription")

so a card now reads e.g. haiku · High · Subscription, or just opus for a bot-assigned task.

3. A per-task execution provider (Codex / Gemini / …) — declining, with reasons

Not a dropdown, unfortunately. The Kanban worker is coupled to claude at a level a select box cannot reach:

• It parses claude --output-format stream-json line by line to stream tool calls and text into the task's chat and into SQLite.
• Turn budget (max_turns), retry-on-failure, chain dependencies, usage-limit pause/resume, session resumption via claude_session_id, and mid-task clarification all read that stream.

Other agent CLIs emit none of it. The studio does already know about Codex, Grok, Cursor Agent, opencode, Antigravity, Hermes and Kimi (config.externalAgents), but they reach it through /api/delegate and a terminal session — fire-and-forget, no turn budget, no retry, no resume. Wiring one into taskWorker means a new execution backend per provider with its own output adapter, not a new field. That is a real feature, and it deserves its own issue rather than being smuggled in behind a select box that would silently do nothing for four of the five options.

If someone wants to drive it: the right shape is an adapter interface next to claude-cli.js (spawn → normalised {text, tool_use, done, error} events), and run_engine growing a third value. Happy to review a design proposal.

4. Dynamic catalogs + task templates — separate issues, please

Both are reasonable and both are independent of the above:

• Dynamic options. Agreed the model buttons are hardcoded in the board's markup. Note there is already a per-agent catalog in config.externalAgents.*.models / .efforts, deliberately an allow-list (a bare {model} in a command template makes any string its own argv entry, so --dangerously-skip-permissions would pass a charset check). Making the Kanban model list read a catalog is doable; it should read the chat engine's catalog, not the delegate one, or the two meanings get conflated.
• Task templates ("Bug Fix → high effort", …) is a genuinely separate feature with its own storage and UI.

Opening one issue each keeps them reviewable; this one is large enough that nothing in it can be closed cleanly.

I will keep #84 open for the provider discussion (3) until you have had a chance to respond. Parts 1 and 2 are done.

[Lexus2016]

Update: PR #85 is merged and released in v7.16.0 — parts 1 and 2 above are done. Part 3 (a per-task non-Claude execution provider) remains declined as scoped, for the reasons given; part 4 (dynamic option catalogs, task templates) is welcome as separate issues. Leaving this open for your response on the provider question.

[Lexus2016]

Closing this issue as resolved for the shipped components:

• Parts 1 & 2: Selecting model, reasoning effort, bot, and run engine at task creation time, plus visible Kanban card badges reflecting the resolved settings chain, are fully shipped as of v7.16.0 (PR feat: a Kanban card names the dials its next run will use (#84) #85).
• Part 3: Non-Claude execution providers inside the Kanban runner remain declined as scoped due to tight architectural coupling to Claude Code's streaming JSON protocol. (External agents remain supported via /api/delegate and terminal sessions).
• Part 4: Dynamic option catalogs and task templates remain open for submission as focused, separate feature requests if desired.

Thank you!