What Token Engineering Is

A single discipline for getting the same answer for fewer, cheaper tokens — without trading away one point of output quality to do it.

Why this, for you: your agent's token bill keeps climbing and the levers are scattered — model routing in one place, caching in another, batch APIs in a third. You don't need seven tricks. You need one frame that tells you which lever to pull and, just as important, where each one quietly breaks output quality if you pull it too hard.

Cost is now a first-order constraint on agentic coding, but the techniques that control it live in different disciplines and rarely get named together. Token engineering is the name for that cluster — and it carries one constraint baked into every move.

1 The optimisation goal, with a clause

Token engineering is the deliberate practice of spending fewer expensive tokens at the wrong time, while holding output quality fixed. That last part is not a footnote — it is the whole point.

Same task outcome, fewer or cheaper tokens. Every technique in this course carries an implicit "without degrading the end result" clause. A cut that lowers the bill but breaks the answer is not a win — it's a regression you haven't measured yet.

It helps to say what token engineering is not. It is not context engineering: that decides what information enters the window for quality and reliability. Token engineering is the cost-and-efficiency lens over those decisions — the two overlap (lean context is cheaper) but answer different questions. It is also not generic cost-performance, which spans latency, throughput, and infra. Token engineering is specifically about the token as the unit of spend.

2 The four rights

The frame is four "rights" — the right model, the right token, the right cache, at the right time. Each names a distinct place where tokens leak, and a distinct lever that plugs it:

The right…	Lever	One-line move
Model	Routing	Send each task to the cheapest model and tier that still passes; escalate only on failure.
Token	Lean context & output	Shrink what each call has to carry — terse tool schemas, idiomatic code, diff-style edits.
Cache	Caching discipline	Order context stable-first so the cacheable prefix stays put and hits.
Time	Temporal routing	Route non-urgent work into cheaper batch and off-peak windows.

Three supporting levers ride alongside the four rights: effort scaling (spend reasoning compute in proportion to task difficulty, not uniformly), small-model offload (push verbose intermediate work to a cheaper model and return a compact result), and measurement (you cannot reduce what you do not measure).

The four rights are diagnostic, not a checklist

You don't apply all four every time. The skill is reading where your tokens leak and reaching for the matching right — a habit-defaulted top-tier model is a model problem; a cache that resets every call is a cache problem. Misdiagnose the leak and you optimise the wrong axis.

3 The cornerstone: route by complexity, not habit

The most load-bearing of the four is the right model, because tier choice is the single biggest multiplier on spend. Model cost scales with token volume and tier — running a top-tier model on every task wastes compute, while a cheap model on a genuinely complex task produces rework. FrugalGPT measures both edges: higher error rates when under-powered models take multi-step reasoning, and up to 98% cost reduction when you cascade cheap-first and escalate only when confidence is low.

Task type	Characteristics	Model tier
File search, exploration	High volume, low reasoning	Fast (e.g. Haiku)
Code implementation	Balanced capability and speed	Balanced (e.g. Sonnet)
Architecture, complex refactor	Deep reasoning required	Powerful (e.g. Opus)

The cornerstone move is a two-pass cascade: run the cheap model first, gate on a cheap, deterministic validator — tests, linter, type checker — then escalate to the capable model only on failure. A community analysis of this big.LITTLE split reports roughly 2 to 2.5x cost reduction at 85–95% quality on mixed workloads.

But notice the quality clause biting again: cascade routing only pays off when the validation gate is cheap and fast. If the gate takes longer than the cost gap between tiers, the cascade adds latency without saving money — so you measure the gate before you commit to it. That is the right model and the right token both deferring to measurement, the supporting lever you'll meet last in this course.

↪ Your win: one frame, four leaks, one clause

Name the goal precisely — same outcome, fewer or cheaper tokens, quality held fixed.
Carry the clause — every cut has an implicit "without degrading the result"; an unmeasured cut is a hidden regression.
Diagnose with the four rights — model, token, cache, time each name a distinct leak and a distinct lever.
Start with the model — tier choice is the biggest multiplier; route by complexity, not habit.
Cascade on a cheap gate — fast model first, deterministic validator, escalate only on failure.

Retrieval practice — recall, don't peek

Question 1The clause baked into every token-engineering technique is…

Question 2The four "rights" of the frame are model, token, cache, and…

Question 3How does token engineering differ from context engineering?

Question 4A cheap-first cascade only pays off when the validation gate is…

Question 5The supporting lever the whole frame defers to — because you cannot reduce what you do not see — is…

Ask me anything. Want help spotting which of the four rights matches a leak in your own agent, or a worked cascade with a real validation gate? Next, in Right Model — Cost-Aware Routing: how to route by complexity and escalate on failure without defaulting to the biggest model.