Feature: Auto-select model and effort level based on task complexity

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39282
2. https://github.com/anthropics/claude-code/issues/27665
3. https://github.com/anthropics/claude-code/issues/34874

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Cowork Scheduled Tasks Use Case

Thanks for this detailed feature request. I'd like to add a complementary use case specific to Cowork scheduled tasks:

Problem

Cowork scheduled tasks that perform lightweight, repetitive monitoring/polling operations (e.g., GitHub issue monitoring, health checks, log analysis) currently consume the same tokens as complex reasoning tasks, since all tasks default to the main model (Sonnet/Opus).

Example: A GitHub issue monitor that runs every 4-6 hours does mostly API polling and simple classification:

• Fetch 50–100 issues via GitHub API (lightweight)
• Classify new comments by author type (bot, staff, user) (lightweight)
• Post auto-replies for common patterns (boilerplate)

This workload doesn't need Sonnet—Haiku would be sufficient and dramatically reduce cost.

Proposed Extension

Add per-task model configuration to create_scheduled_task / update_scheduled_task MCP tools:

create_scheduled_task(
    taskId="github-issue-monitor",
    prompt="...",
    cronExpression="0 9 * * *",
    model="haiku"  # NEW: Allow explicit model override per task
)

Or as a simpler alternative, expose model selection via task-level settings that can be read from a config file or environment variable.

Benefits

• Cost optimization: Lightweight monitoring tasks run on Haiku (≈10% token cost vs. Sonnet)
• No degradation: Haiku's classification/pattern-matching is more than adequate for polling workflows
• User choice: Power users can optimize without affecting other tasks

This would complement your "auto-select" approach by allowing explicit per-task control for known lightweight workloads.

there's no way to automate this via hooks" — I tested exactly this and can confirm it empirically. A UserPromptSubmit hook that rewrites .claude/settings.json does not change the running session's model: the model is fixed for the lifetime of a session. The rewrite only takes effect on the next session start. So a live per-prompt classifier for the main thread isn't reachable from hooks today (which also matches why mid-session switching would be undesirable anyway — it invalidates the prompt cache).

What is reachable without that: route at the seams Claude Code already has — per-subagent model (you can pass it per invocation) and the per-project model in settings.json. I built a small plugin around that idea (calibrate): instead of classifying every prompt, it analyzes the repo once and writes a per-project policy (which tier plans / codes / reviews / explores, with escalation rules for risky paths), then routes phase subagents through it. On one verified run it cut cost 46.8% vs all-Opus — modest sample, but the routing is confirmed against the session logs, not self-reported.

Sharing mostly for the hooks finding, since it comes up whenever someone tries to build the per-prompt version. Happy to compare notes if anyone's going down this path.

+1 for this. We need a way for Claude Code to handle the switching of models based on task difficulty and intent.

yes this will help huge token saving