Routing Content Tasks Between a Small and a Large Model

Before you can route, you need to be honest about what each task actually requires. Content work is not one activity. It is at least four, and they have very different failure modes.

Brief writing requires reading the competitive landscape and deciding what the page should cover to satisfy a search query. Search engines evaluate whether a page matches what the searcher wanted, which is why intent analysis sits at the center of SEO work: as Semrush puts it, Google's ranking systems first establish the intent behind a query before returning results Semrush on search intent. A brief that gets intent wrong produces a page that cannot rank no matter how well it is written.

Auditing requires comparing what exists to what should exist. That is a judgment task. You are reading a page, deciding whether it answers the query, and identifying what is missing. Ahrefs frames technical SEO around removing obstacles that stop search engines from finding, crawling and indexing pages Ahrefs technical SEO guide, and the same logic applies to content audits: the value is in the diagnosis, not the checklist.

Editing sits on a spectrum. Copy-editing for grammar and length is mechanical. Editing for legal, regulatory and brand risk is not. The difference matters enormously for routing.

Production (turning a brief into a draft) is the task most people think of, but it is often the least consequential routing decision, because drafts get reviewed anyway.

Google's documentation describes search as three stages: crawling, indexing and serving Google Search Central. Content work maps onto the middle stage. You are trying to make pages that the index treats as relevant and worth serving, which is why intent and coverage decisions carry so much weight.

A content brief is the classic case where teams under-invest. The brief is upstream of everything: get it wrong and you waste the draft, the edit and the review.

Route to the large model when the brief comes from a gap analysis. If you are asking "the top results cover X and Y but skip Z, what should our page say," that is synthesis across sources with ambiguous boundaries. Small models tend to summarize what is already visible rather than identify the absence. Absence detection is exactly where weaker models fail, and it is the whole point of a gap-driven brief.

Route to the small model when the brief is templated. If your brief format is fixed (target query, intent type, required sections, word count, internal links, entities to mention) and the inputs are a keyword row plus a competitor list, a small model can fill the template. The specification is high, the output is short and structured, and a bad brief is caught in seconds because the fields are visible.

A worked distinction:

Keyword research itself follows a documented pattern: brainstorm, test the SERP, then rank by volume, difficulty and intent Iowa State CALS keyword research guide. That ranking step is arithmetic and belongs on the small model. The "what should this page actually say" step belongs on the large model.

Audits are where routing mistakes get expensive, and where the "cheapest model that works" heuristic fails hardest.

An audit has two halves. The first is mechanical: does the page have a title tag under the character limit, a single H1, descriptive alt text, a canonical tag, no accidental noindex. Google distinguishes crawling directives from indexing directives, and mixing them up is a common failure Straight North technical SEO guide. Checking these against a list is a small-model job. The rules are explicit, the output is a table, and a reviewer can verify each row in seconds.

The second half is interpretive: does the page satisfy the query, does the structure match what the SERP rewards, does it answer the follow-up questions a reader will have. This is where a small model quietly fails. It will produce a confident, plausible audit that misses the actual problem, and because audits are long documents, the false confidence is hard to spot.

The diagnostic signals you feed an audit come from Search Console: impressions, clicks, average position and click-through rate Google Search Console metrics. Read those carefully, because average position is easy to misread. It is the average of the topmost position a page appeared in for each query, averaged across searches SEOTesting on average position, which means a page can rank first for its target query and still show a poor average because it now ranks for hundreds of long-tail queries. An audit that treats a falling average position as a failure will send you fixing something that is not broken SurgeGraph on average position.

Decision rule for audits: if the audit output feeds a client deliverable or a decision about a page with material traffic, use the large model. If the audit is an internal triage step that a human will re-run before acting, a small model with a strict checklist is fine.

Editing splits cleanly along risk.

Low-risk edits are mechanical: trim to a word count, enforce a style rule, convert passive to active, check a meta description against a character limit, normalize heading case. These are fully specified, short-output tasks. Small models handle them well because the failure is instantly visible: the character count is either under the limit or it is not.

High-risk edits involve meaning. Tightening a claim so it stays accurate. Removing a sentence that reads as a guarantee. Adjusting phrasing where a regulated industry restricts what you can say. Flags on packaging and advertising have followed claims that were technically compliant and practically misleading, and the same risk exists in copy. A small model asked to "make this compliant" will make it shorter and more confident, which is the opposite of safe.

A useful test: can a reviewer verify the edit without rereading the source? If yes, small model. If the reviewer has to hold the original claim in their head to check the edit, large model.

Token prices differ by roughly an order of magnitude or more between the cheapest and strongest tiers. Published rate cards show input prices from well under a dollar per million tokens at the low end up to tens of dollars at the frontier, with output prices typically several times the input price BenchLM pricing table and Silicon Data cost per token guide. One million tokens is roughly 750,000 English words, or about 1,500 pages of plain text PE Collective token guide, which is a useful sanity check: most content tasks consume far less than a million tokens.

Worked example. Suppose a team processes 2,000 content tasks a month. Each task sends about 3,000 input tokens and receives about 500 output tokens. That is 6 million input tokens and 1 million output tokens monthly.

Using illustrative rates of $0.10 per million input and $0.40 per million output for the small model, and $2.00 input and $10.00 output for the large model (both drawn from the pattern in the published rate cards above):

The inference difference is $21 a month. The rework difference is $1,600 a month. The large model is roughly four times cheaper overall, and the token bill was never the deciding factor.

Now flip the assumptions to see where the small model wins. Take the same 2,000 tasks but make them mechanical: title variants from a keyword list. Error rate on the small model drops to 2%, and rework takes 1 minute because the reviewer just regenerates.

Now the two are within a dollar of each other, and the small model's advantage is real but small. The lesson: the small model only produces meaningful savings when the task is so well specified that its error rate collapses and the fix is seconds, not minutes.

The general decision rule falls out of this:

Route to the small model when (probability of error × minutes to detect and fix × hourly cost) is less than the price gap between the models. Otherwise route to the large one.

That is the whole calculation. It takes five minutes to run per task type and it will change how you defend your model spend.

This is also what the research literature formalizes. Model routing is treated as a sequential decision problem, and learned routers have been shown to outperform the strongest fixed-model baseline by a relative margin in the mid-teens on quality and cost together LLMRouter paper. You do not need a trained router to get most of the benefit. A written routing table with the arithmetic above gets you most of the way.

Once you have the rule, encode it. A routing table that lives in a document gets ignored; one that lives in code gets used.

ROUTING = {
    "brief_gap_analysis": "large",
    "brief_from_template": "small",
    "audit_mechanical": "small",
    "audit_intent_match": "large",
    "edit_mechanical": "small",
    "edit_legal_or_brand": "large",
}

def route(task_type):
    model = ROUTING.get(task_type)
    if model is None:
        raise ValueError(f"unrouted task: {task_type}")
    return model

The raise matters. An unrouted task should fail loudly rather than silently default to the cheap model, because silent defaults are how a small model ends up writing a client's compliance copy.

Two operational habits make this stick:

Log the routing decision and the outcome. For each task, record which model ran, whether a human changed the output, and how long the review took. After a few hundred tasks you have your own error rates, which are better than any assumption in this article.

Re-audit the table quarterly. Not because models change constantly, but because your task mix changes. A brief type that was templated becomes gap-driven the moment you enter a new market.

If you are running this at scale across multiple model providers, a single API that exposes many models under one key removes the plumbing work of switching between them; Quanta Inference is built for exactly that Quanta Inference. For teams that want the routing and the review handled together, having a specialist build the pipeline with you is often faster than assembling it yourself Quanta.

Defaulting to the cheap model for everything. This is the most expensive mistake in practice, because the failure is invisible. Bad briefs produce mediocre drafts, which produce flat traffic, which nobody traces back to the brief.

Routing by output length instead of by judgment. A 200-word legal edit requires more judgment than a 2,000-word mechanical rewrite. Length is not a proxy for difficulty.

Using a large model for tasks with a deterministic check. If a script can verify the answer, you do not need judgment. You need a script.

Ignoring the recrawl lag when judging audit results. Google notes that crawling can take anywhere from a few days to a few weeks, and re-requesting a crawl does not speed it up Google on recrawling. Teams that audit a page, fix it, and judge the fix the next day will always conclude the fix failed.

Treating vanity metrics as proof the routing worked. Rankings, impressions and link counts are building blocks, not outcomes; revenue and ROI are the outcome The Martech Summit on SEO ROI. If your routing change did not move a business number, it did not do anything.