Task-Model Matching

Task-model matching is the practice of selecting the right model for each specific task. The classification is straightforward. High-complexity tasks — debugging across multiple files, architecture refactoring, security analysis, performance optimization — require the Pro model's stronger reasoning. Medium-complexity tasks — implementing a feature from a clear spec, writing tests for existing code, code review — work well with either model. Low-complexity tasks — formatting, renaming, documentation, boilerplate generation — are Flash territory.

The switching cost between models is near zero in Gemini CLI. The --model flag overrides the session default, and profiles make switching a single command. The practical workflow is: start your session with the default model, switch to a heavier model when you hit a complex task, switch back when you return to routine work. The /model command (or the profile system) makes this seamless. The key discipline is recognizing when a task is too complex for your current model — if the model's output quality drops, it is a signal to switch up.

# Task-model matching guide

## Pro model (gemini-2.5-pro)
- Multi-file debugging and root cause analysis
- Architecture design and refactoring
- Security and performance auditing
- Complex test scenarios with multiple dependencies
- Code review of critical paths

## Flash model (gemini-2.5-flash)
- Single-file feature implementation
- Documentation and README writing
- Boilerplate and scaffolding generation
- Simple refactoring (rename, extract function)
- Formatting and style fixes

## Either model
- Writing tests from clear specifications
- Standard code review
- Git operations and commit message generation
- Configuration file updates

1. Classify your common tasks List the 10 tasks you do most frequently with Gemini CLI. Classify each as high, medium, or low complexity. Map each classification to a model.
2. Create matching profiles Build profiles in settings.json that map to your task classifications. Name them descriptively — "debug," "implement," "format" — so switching is intuitive.
3. Monitor quality signals Track when you need to correct or re-prompt the model. If a task type consistently requires corrections with Flash, it belongs in the Pro category. Update your classification based on real data.