September 11, 2026
ONE CLI, MANY MODELS

An AI CLI is the working harness: it can read the project, follow instructions, propose edits, run commands, and keep a task moving. The model is the brain inside that harness. Those are related, but they are not the same thing.
Codex and Claude Code combine their own agent experience with their respective models. Other tools can connect to several model providers through a routing layer. This gives you choice, but choice only helps when you use it deliberately.
The layers
| Layer | Question it answers |
|---|---|
| Project files | What are we working on? |
| CLI harness | How can the agent inspect, edit, and run this work? |
| Model | How well can it reason through this particular task? |
| Routing layer | Which available model receives the request? |
| Human director | Is this task worth doing, safe, and correct? |
Choose by task, not hype
There is no universal best model. A difficult architecture decision may justify a stronger model. A repetitive file reformat, first-pass exploration, or large routine review may be well suited to a less expensive model.
Think about:
- Task difficulty: Does it require deep reasoning or routine transformation?
- Context size: Must it read a large codebase or research library?
- Tool use: Can it reliably inspect, change, and test through the CLI?
- Cost: Could a long agent loop use far more tokens than a normal chat?
- Reliability: Have you verified its output on this type of work before?
A practical model policy
Start simple. Pick one trusted default agent and learn its behavior. Add a second option only when you have a clear reason: cost, a task where the first tool is weak, a need for a different context window, or a research comparison.
Do not let every task become a model experiment. The project instructions, acceptance criteria, tests, and review process matter more than winning an abstract leaderboard.
Keep the model decision separate from the product decision
Changing models should not change the meaning of the task. Keep the same brief, same project files, and same acceptance criteria when you compare options. Otherwise, you cannot tell whether a better result came from the model, the prompt, the context, or the task quietly changing underneath you.
For important work, write down which model or agent produced a material output. This is especially useful when a research or coding result needs later review. You are not trying to create paperwork; you are preserving enough provenance to understand why one result looks different from another.
Keep costs visible
Agent work can be longer than chat work. An agent may read files, try commands, repair errors, and continue for many turns. Treat API-based usage as a business cost: use spending limits, inspect the task before letting it run for a long time, and stop when the work is no longer productive.
Practical exercise
Choose one routine task, such as summarizing a folder or reviewing a Markdown spec. Use your normal agent first. If you later test another model, keep the same instructions and compare: accuracy, completeness, time, cost, and how much correction you needed.
Check your understanding
1. What is the difference between a CLI harness and a model? 2. What task traits affect model choice? 3. Why should you start with one trusted default? 4. Why can agent costs differ from normal chat costs?
ARTICLE DISCUSSION
JOIN THE
CONVERSATION.
Got a question, a take, or a better way to do this? Log in and leave a comment.
