Half My Tasks Went to Pro — and So Did Only 61% of the Tokens

Putting both routers on the same scale

I encoded the rule I had actually been using: screens, API routes, libraries, and config to Pro; components and data to Flash.

import json
tasks = json.load(open("tasks.json"))      # output of the script above
TOTAL = sum(t["ctx"] for t in tasks)
 
def task_class(path):
    if "/app/" in path and path.endswith(("page.tsx", "route.ts", "layout.tsx")):
        return "route"          # screens and API implementation
    if "/components/" in path:
        return "component"
    if "/lib/" in path or "/config/" in path:
        return "lib"
    if "/i18n/" in path or "/generated/" in path:
        return "data"
    return "other"
 
PRO_CLASSES = {"route", "lib"}   # the naive "reasoning work goes to the big model" rule
 
pro = [t for t in tasks if task_class(t["file"]) in PRO_CLASSES]
pro_n, pro_tok = len(pro), sum(t["ctx"] for t in pro)
print(f"[class] Pro {pro_n}/{len(tasks)} = {pro_n/len(tasks)*100:.1f}%"
      f" | tokens {pro_tok/TOTAL*100:.1f}%")
 
# If the same number of tasks were picked by size, how many tokens would that capture?
by_size = sorted(tasks, key=lambda t: -t["ctx"])[:pro_n]
print(f"[size ] same count {pro_n}: tokens {sum(t['ctx'] for t in by_size)/TOTAL*100:.1f}%"
      f"  (threshold = {by_size[-1]['ctx']:,})")

The output:

route      n= 27  tokens=125,968 ( 57.1%)  median= 3,017
component  n= 22  tokens= 50,433 ( 22.9%)  median= 2,265
lib        n=  5  tokens=  8,308 (  3.8%)  median= 1,571
data       n=  4  tokens=    691 (  0.3%)  median=   204
other      n=  9  tokens= 35,156 ( 15.9%)  median= 4,573

[class router] Pro tasks 32/67 = 47.8% | Pro tokens 134,276/220,556 = 60.9%
[size  router] same task count 32: tokens 84.6%  (threshold = 2,711 tokens)

Task type sends 47.8% of the work to Pro and 60.9% of the tokens. Picking the same 32 tasks by size captures 84.6%. Twenty-four points of difference, purely from the choice of axis.

Two views of where that gap lives:

tasks under 2,000 tokens inside the class router's Pro bucket: 12/32 (13,835 tokens = 6.3%)
tasks over 5,000 tokens the class router drops to Flash: 6 (40,775 tokens)
    7,915  src/app/[locale]/support/SupportClient.tsx
    7,610  src/app/sitemap.ts
    7,559  src/components/layout/Header.tsx
    6,227  src/app/[locale]/HomeClient.tsx

Twelve of the 32 tasks I was sending to Pro — nearly 40% — sit under 2,000 tokens, and together they account for 6.3% of the total. Upgrading them changes almost nothing about cost.

Meanwhile sitemap.ts and Header.tsx were landing on Flash. My taxonomy files them under "other" and "component" respectively, and both exceed 7,500 tokens. What their names and locations implied about weight and what they actually cost had drifted apart.

I don't think task type is the wrong axis. Quality requirements really do track type. But cost tracks volume, and I had been asking one rule to carry both jobs.

What one step of the threshold actually moves

Routing by size raises the obvious question of where to put the line. I swept it.

       T   Pro tasks    task%    token%
   1,000       45   67.2%     95.4%
   2,000       36   53.7%     88.8%
   3,000       29   43.3%     80.8%
   4,000       20   29.9%     67.0%
   5,000       15   22.4%     56.6%
   6,000       11   16.4%     46.2%
   8,000        4    6.0%     22.9%
  10,000        2    3.0%     15.4%
  15,000        1    1.5%     10.5%
  20,000        1    1.5%     10.5%

A "step" of the threshold means something completely different depending on where you are standing.

Down in the low range, cutting a lot of tasks barely moves the tokens — small tasks simply do not carry volume. Move from 6,000 to 8,000 and task share falls by only 10.4 points while token share drops 23.3.

I caught myself about to push the threshold downward on the theory that sending more tasks to Pro would raise quality. Seen from the cost side, that is spending money in the region where spending does the least.

How many hops you read changes what the threshold means

After settling on a threshold, something else surfaced: the context of a task depends on how far the dependency walk goes.

I re-measured the same 67 tasks from zero hops (the file alone) to three.

hops=0  total= 115,102  p50=  1,446  p90=   3,767  max=   8,188  >=6,000:  2 (3.0%)   65ms
hops=1  total= 220,556  p50=  2,311  p90=   7,579  max=  23,119  >=6,000: 11 (16.4%)   9ms
hops=2  total= 226,694  p50=  2,311  p90=   7,696  max=  25,058  >=6,000: 11 (16.4%)  18ms
hops=3  total= 226,694  p50=  2,311  p90=   7,696  max=  25,058  >=6,000: 11 (16.4%)  19ms

This is where my expectation broke. I assumed context would keep inflating the wider you let the agent read. It doesn't.

Going from zero to one hop nearly doubles the total, from 115,102 to 220,556, and the number of tasks above a 6,000-token line jumps from 2 (3.0%) to 11 (16.4%). But one hop to two adds only 2.8%, and two to three adds nothing at all. At this size, the dependency graph closes by the second hop.

In other words, the only step where "how much to read" moves cost is the first one. When you are setting a routing threshold, there is no need to carefully count two hops out. What you must not do is leave the direct-import question vague while tuning the threshold, because then two things are wobbling at once.

The break-even on retries is lower than it feels

The other half of the conversation is fallback: try the fast model, escalate to the larger one when it falls short. Handling most of the volume cheaply sounds appealing.

The easy thing to miss is that an escalated task is billed twice. The fast model's input is already spent, and the larger model's cost stacks on top.

Treating one Flash input token as 1 and Pro as R times that, here is the sweep over retry rate e:

def cost(T, R, e=0.0, biased=False):
    pro = [t for t in tasks if t["ctx"] >= T]
    fla = [t for t in tasks if t["ctx"] < T]
    c = sum(t["ctx"] for t in pro) * R + sum(t["ctx"] for t in fla)
    if e > 0 and fla:
        k = max(1, round(len(fla) * e))
        # biased=True assumes retries concentrate on the larger tasks
        pick = sorted(fla, key=lambda t: -t["ctx"])[:k] if biased else \
               sorted(fla, key=lambda t: t["file"])[:k]
        c += sum(t["ctx"] for t in pick) * R   # Flash already paid; add the Pro pass
    return c

At R = 10 with a threshold of 6,000, relative to sending everything to Pro:

Past a 10% retry rate the size router's advantage is gone. A binary search puts the crossing at 9.8%.

"One retry in ten is cheap enough" is a sentence I would have said out loud. It turns out to be exactly the point where the savings break even. And since failures naturally cluster on the larger tasks rather than the small ones, an estimate built on a uniform assumption leans optimistic — which is why the table above uses the biased case.

The bigger surprise was how little the price ratio moves that crossing.

Making the larger model four times more expensive shifts the break-even from 8.0% to 9.8%. I had believed that a wider price gap makes routing skill matter more. The opposite held. What dominates is not the price ratio but the shape of the context distribution. As long as that shape holds, a pricing change does not force you to redraw the threshold.

Put differently: measuring my own repository told me more than studying the price sheet did.

Three things that tripped me up while measuring

Each of these quietly distorts the result.

Only the first pass is slow. In the hop comparison above, zero hops took 65ms while one hop took 9ms. That inversion is the tokenizer encoding every file on the first walk and hitting the cache afterwards. If you care about timing, measure each hop in a separate process. I missed this at first and spent a minute staring at the impossible conclusion that reading more made things faster.

An unresolved alias passes silently as zero dependencies. If a path alias like @/ fails to resolve, the file is recorded as having no dependencies and a large task gets scored as a small one. The workaround is simple: eyeball the files reporting deps=0 once. In my case about/page.tsx genuinely has none and still weighs 8,188 tokens — large on its own rather than mis-measured.

External packages are not counted. The script only sums what resolves locally. If your production setup lets the agent read into node_modules, the meaning of the threshold changes entirely. I'd recommend recording what you included in the measurement right next to the threshold itself.

What to hand the auto-selection helper

Turning the measurements into a selection function, the point is to keep the quality axis (type) and the cost axis (volume) separate instead of using one as a proxy for the other.

# Derive the threshold from your own repository's distribution.
# 6_000 below is the point that held 16.4% of tasks and 46.2% of tokens in the sweep.
CTX_THRESHOLD = 6_000
QUALITY_CRITICAL = {"route", "lib"}   # type informs the quality decision only
 
def select_model(task_path: str, ctx_tokens: int, retry: int = 0) -> str:
    """Return a key from the models collection. Check field names against your SDK build."""
    if retry > 0:
        return "pro"                       # retries always go to the larger model
    if ctx_tokens >= CTX_THRESHOLD:
        return "pro"                       # where the cost concentrates
    if task_class(task_path) in QUALITY_CRITICAL and ctx_tokens >= 2_000:
        return "pro"                       # high quality bar and enough volume to matter
    return "flash"

The extra ctx_tokens >= 2_000 clause exists because of what the measurement showed: 40% of the Pro bucket sat under 2,000 tokens. Even when you want the larger model for quality reasons, if the volume is noise, you can hold that judgment.

The piece I would not skip in production is logging the retry rate. Once you know the break-even sits near 10%, a router without that number is a router nobody can evaluate.

import csv, time, pathlib
 
LEDGER = pathlib.Path.home() / ".antigravity_routing.csv"
 
def log_route(task_path, ctx_tokens, model, retry, ok):
    new = not LEDGER.exists()
    with LEDGER.open("a", newline="") as fh:
        w = csv.writer(fh)
        if new:
            w.writerow(["ts", "task", "ctx_tokens", "model", "retry", "ok"])
        w.writerow([int(time.time()), task_path, ctx_tokens, model, retry, int(ok)])

Counting the share of rows with retry > 0 once a week is enough; I added one line to an existing Sunday job. If it stays above 10%, the signal is not to raise the threshold but to look again at what you are asking Flash to do.

An order of operations

Changing everything at once makes it impossible to attribute the result afterwards. The order I used:

1. Measure. Run the script against your repository and get the median, p90, maximum, and the share held by the top fifth
2. Place a provisional threshold. Build the sweep table and pick just below the point where tokens-per-task-point turns steep (6,000 in my case)
3. Add the selection function, but for the first week or two only record its decision without switching models
4. Read the log, check the retry rate and the density around the threshold, then switch
5. Re-measure monthly. As files accumulate, the threshold's meaning drifts

Skipping step 3 is tempting — I felt it too. Recording first is what lets you later separate "the model changed" from "the distribution changed."

Where to start

This began with a small event: a configuration format changed. If that were all it was, you would swap the syntax and move on. But having a place to write down what the choice is based on turned out to be an invitation to put numbers where I had been running on instinct.

Start by pointing the measurement script at your own repository and looking at the spread between the median and the maximum. If it sits around 2x, routing has little to win and the threshold is not worth agonizing over. If it opens up to 10x, the same savings I found are sitting in your repository too.

Thank you for reading. I'd be curious what your own numbers look like.