Ask Knox

Introduction

Model selection is the most direct lever on cost per session. At current pricing, Opus output ($25/1M tokens) runs about 1.7x Sonnet's ($15/1M), and Sonnet runs 3x Haiku's ($5/1M); input pricing follows the same ladder ($5 / $3 / $1 per 1M). If you're routing everything to Opus by default, you're paying a premium on tasks where it makes no difference — and the premium compounds across every subagent you dispatch. (Prices change between model generations; check current rates before hardcoding routing math.)

The discipline of model routing is knowing which 10% of tasks actually benefit from Opus's reasoning depth — and routing everything else to Sonnet.

The Three-Tier Architecture

The key insight is that most coding work is not complex reasoning — it's pattern application. Writing a test for a function, formatting a document, generating a PR description. These are tasks where a smaller model does the same job for far less cost.

Complex reasoning tasks — security audits, architecture decisions, debugging novel problems — do benefit from Opus. The difference is measurable: Knox has compared Sonnet and Opus on security reviews and found real quality gaps. On test writing, the gap is negligible.

Knox's actual routing heuristic: if the task has a well-defined output schema (tests, docs, formatted output), Sonnet. If the task requires novel reasoning with multiple competing considerations (security review, architecture, difficult debugging), Opus. Everything in between: Sonnet, and upgrade if the output quality is visibly insufficient.

Subagent Configuration

Custom subagents are markdown files in .claude/agents/ (project-level) or ~/.claude/agents/ (personal), with YAML frontmatter declaring name, description, tools, and model — the body of the file is the agent's system prompt. When skills dispatch parallel agents, each agent can have its own model and tool set:

The tool restriction is as important as the model routing. A documentation subagent with only Read and Write cannot accidentally run destructive Bash commands — even if Claude's reasoning suggests it would be helpful. The restriction is mechanical.

Knox's audit-swarm dispatches four specialized agents:

Security agent — claude-opus-4-8, tools: Read, Bash(grep:*) — security decisions warrant full reasoning depth
Logic agent — claude-sonnet-4-6, tools: Read, Write — logic review is well-defined
Test agent — claude-sonnet-4-6, tools: Read, Write, Edit, Bash(npm run test:*) — needs test runner access
Architecture agent — claude-opus-4-8, tools: Read — architectural assessment warrants Opus

The tool restrictions enforce that each agent stays in its lane. The security agent can grep but not write. The test agent can run tests but not modify unrelated files. The architecture agent is read-only — it observes and reports, never changes.

Now configure it yourself. Define the named subagents as markdown files in .claude/agents/, each with model and tools in its frontmatter: route the judgment-heavy security work to Opus and the well-defined work to Sonnet, and lock each agent's blast radius with its tools list.

Building a Routing Table

The simplest routing table starts with one decision: "which tasks must have Opus?" Work backwards from there.

Start by listing the tasks that regularly appear in your sessions. For each, ask: "Is the output quality visibly different between Sonnet and Opus?" Test this empirically — run the same task on both models and compare. You'll find the answer is "sometimes" for creative work and "rarely" for structured output.

For Knox's academy workflow, the routing table is:

Lesson authoring → Sonnet (structured output with clear format)
Diagram code → Sonnet (pattern-based React components)
Track registration → Sonnet (mechanical file edits)
Security audit subagent → Opus (judgment-heavy, outcome-critical)
Architecture review → Opus (genuine reasoning required)

The Cost Monitoring Discipline

Model routing is only as good as the feedback loop that calibrates it. Knox tracks cost per session weekly and asks one question: "Which sessions cost significantly more than expected?" Those sessions usually have one of two root causes: an audit skill that dispatched too many Opus agents, or an exploratory session that unexpectedly went deep.

For the audit case, the fix is routing. For the exploratory case, the fix is either routing or switching to a more constrained skill that enforces Sonnet for well-defined subtasks.

The goal is not to minimize cost at the expense of quality — it's to route correctly so that money is spent where it changes outcomes, not where it's wasted on tasks that Sonnet handles perfectly.

What's Next