claude-sonnet — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited claude-sonnet (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
What it is: claude-sonnet is the routing decision for a model provider's balanced middle tier — the default lane for ordinary implementation work that sits between the frontier reasoning tier and the fast/cheap tier on both cost and capability.
Mental model: A model roster is a tiered ladder. The middle rung is the default — routing starts here and moves only with evidence: up to the frontier tier when a task proves too hard, down to the fast tier when a task proves mechanical. Most work clears the middle rung at lower cost and latency than the top.
Why it exists: Without an explicit "default lane," routing collapses into one of two bad habits — sending everything to the smartest model (overpaying) or chasing the cheapest (underperforming on real coding work). A named balanced tier anchors the roster: it is where work goes unless there is a specific reason to escalate or drop.
What it is NOT: It is not the tier for the hardest reasoning (that earns the frontier tier) nor for high-volume mechanical work (that drops to the fast tier or a script). It is not a quality compromise — for well-specified feature work it is the correct choice, not a budget concession.
Adjacent concepts: the frontier reasoning tier (escalation target for hard tasks); the fast/cheap tier (drop target for mechanical/high-volume work); cost-aware delegation (the policy that decides which way to move off the default); loop architecture (the harness the model runs inside).
One-line analogy: The balanced tier is the experienced generalist who handles the bulk of the caseload well — you escalate to the specialist only for the genuinely hard case and hand the routine paperwork to the assistant.
Common misconception: That the middle tier is "the cheaper compromise you settle for." It is not a compromise — it is the default, chosen affirmatively because most implementation work does not need the frontier tier's ceiling and is poorly served by the fast tier's limits.
xhigh/max effort settings the balanced tier lacksA roster without a named default collapses into one of two failures: routing everything to the smartest model (over-paying) or chasing the cheapest (under-performing on real coding work). The balanced tier exists to be that default — chosen affirmatively, not as a budget concession — so that routing becomes a question of evidence to move off the default rather than a guess about which model is "good enough." Movement is two-directional and asymmetric: escalation upward is triggered by task hardness or a need for the effort ceiling the balanced tier cannot reach; de-escalation downward is triggered by mechanical or high-volume signals. Treating those as the same decision is the error this skill guards against. The one place the cost intuition genuinely inverts — the 1M-context subscription billing caveat — is called out explicitly because "the balanced tier is always cheaper" is a rule of thumb with a real exception.
Sonnet is the default lane — route here unless a task gives a specific reason to move off it:
Escalate up to the frontier tier (claude-opus) when the task is hard: architecture and tradeoff design, intermittent multi-system debugging, security reasoning, or long-horizon autonomy that needs the Opus-only effort ceiling. Drop down to the fast tier (claude-haiku) — or a script — for mechanical, high-volume, or latency-dominated work. The default-lane test: is there a specific reason this is too hard, or too mechanical, for the middle tier? If neither, it stays on Sonnet.
| Dimension | Sonnet (balanced tier) | Decision relevance |
|---|---|---|
| Context window | 1M tokens | Same window as the frontier tier — a large-context task does not force an Opus escalation on window size |
| Pricing tier | Middle: ~60% of frontier input cost, ~3× the fast tier | The cost case for the default lane |
| Max output | 64K tokens (half the frontier tier; stream above ~16K) | Long generations feasible but smaller ceiling than Opus |
| Thinking | Adaptive thinking (fixed budgets deprecated) | Control depth via effort, not token budgets |
| Effort ceiling | Supported, but xhigh/max are Opus-only — Sonnet caps below them | The capability gap that defines when to escalate: if a task needs the top effort settings, it needs Opus |
| Effort default | Defaults to high (current gen) | Set effort explicitly (e.g. low/medium) on chat/classification to control latency and cost |
| Prompt-cache minimum | 2048-token prefix (lower than the frontier tier's 4096) | A mid-size shared prefix that caches on Sonnet may silently not cache on Opus |
Concrete model IDs, exact prices, and context numbers change with each release. Read them live from the provider's models API / pricing docs (or theclaude-apireference) before quoting. Current verified facts:references/model-facts.md.
The 1M window carries no long-context per-token premium at GA on the first-party API. But the tradeoff inverts in one specific case on flat subscription runners: the 1M-context entitlement is included for the frontier tier on a MAX-style subscription, while the balanced tier's 1M-context mode routes to per-token API billing. So "Sonnet is always cheaper than Opus" is true for standard-window work but can be false for the 1M-context tier specifically, where the frontier tier may be the entitlement-included option and the balanced tier the metered one. When cost discipline matters and a task needs the full 1M window, check which tier is entitlement-included on your runner before assuming the middle tier is cheaper. See references/model-facts.md.
Strengths: best cost/quality balance for implementation work; same 1M context window as the frontier tier; fast turnaround; the right default for feature work, tests, and well-specified multi-step code.
Weaknesses: below the frontier tier's reasoning ceiling and lacks its top effort settings (xhigh/max), so it under-performs on the hardest debugging/architecture/security tasks; smaller 64K output ceiling; still more expensive and slower than the fast tier for mechanical/high-volume work; the 1M-context billing caveat can make it the metered option on subscription runners.
Before concluding "route this to Sonnet," confirm:
claude-opus).claude-haiku or a script).references/model-facts.md, not from memory.| Situation | Route to | Why |
|---|---|---|
| Architecture, hard/intermittent multi-system debugging, security reasoning, long-horizon autonomy | claude-opus | These need the frontier reasoning ceiling and the Opus-only xhigh/max effort settings |
| Transcription, polling, format conversion, high-volume classification, small-diff review | claude-haiku (or a script) | Mechanical/high-volume work is cheaper and fast enough on the fast tier; the implementation lane is wasted there |
| Deterministic, repeatable file processing / bulk rename | a script | No model is the right executor for work a script does identically |
| Designing the loop / supervisor / checkpoint the model runs inside | autonomous-loop-patterns | That is loop architecture, not model-tier selection |
| Writing the Claude API request (thinking, effort, streaming syntax) | claude-api reference | That is call-site syntax, not the routing decision |
references/model-facts.md — verified current-generation Sonnet facts (ID, context, pricing, the 1M-context billing caveat) with sourcesclaude-opus — the frontier tier this skill escalates up toclaude-haiku — the fast/cheap tier this skill drops down to<!-- skill-graph-context:start (generated — do not edit by hand) -->
Classification
agent-ops (also: ai-engineering)trueagent/modelsNot for
claude-opusclaude-haikuRelated skills
claude-opus, claude-haikuclaude-opus, claude-haiku, autonomous-loop-patterns, agent-engineering, tool-call-strategyConcept
Grounding
hybridskills/agent-ops/claude-sonnet/references/model-facts.mdKeywords
when to use Claude Sonnet, balanced implementation model, default coding model tier, Sonnet vs Opus cost, Sonnet vs Haiku, feature work model, test writing model, cheaper than Opus, 1M context billing caveat, default agent model lane<!-- skill-graph-context:end -->
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.