Routing thinking_level by Task in Gemini 3.5 Flash — Re-measuring My Token Spend

Split Tasks Into Three Tiers and Assign Level Automatically

Picking the level by hand every time doesn't last. So I sorted my tasks into three tiers and let a router assign the level. The axis is "how expensive is the rework if the model gets it wrong."

Tier 1: Cheap to Miss (fixed low)

Formatting, renaming, boilerplate generation, adding comments. Things I can eyeball on the spot and catch in a second if wrong. Speed dominates the experience here, so I keep thinking minimal.

Tier 2: Annoying to Fix by Hand (middle)

Small refactors across multiple files, adding tests, tidying type definitions. The zone where low needs a fix half the time and high is overkill. I set an explicit middle thinking_budget (around 512 tokens) to dampen the swing.

Tier 3: Expensive to Walk Back (fixed high)

Architectural boundaries, state-management decisions, changes touching data integrity. Skimp on thinking tokens here and implementation proceeds on a wrong premise — burning dozens of times more in the end.

In code, the three tiers look like this:

from google import genai
from google.genai import types
 
client = genai.Client()
 
# task type -> thinking profile
PROFILES = {
    "format":      {"level": "low"},
    "rename":      {"level": "low"},
    "boilerplate": {"level": "low"},
    "refactor":    {"budget": 512},   # middle: set by token count
    "test":        {"budget": 512},
    "design":      {"level": "high"},
    "state":       {"level": "high"},
    "data-model":  {"level": "high"},
}
 
def build_config(task_type: str) -> types.GenerateContentConfig:
    profile = PROFILES.get(task_type, {"level": "low"})  # unknown -> safe low
    if "budget" in profile:
        thinking = types.ThinkingConfig(thinking_budget=profile["budget"])
    else:
        thinking = types.ThinkingConfig(thinking_level=profile["level"])
    return types.GenerateContentConfig(thinking_config=thinking)
 
def run(task_type: str, prompt: str) -> str:
    response = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=prompt,
        config=build_config(task_type),
    )
    return response.text

If you use Antigravity's editor alone, you don't even need the SDK — just nudging "the default for light operations" toward low in the workflow settings already helps. The SDK matters when the task type is known in advance, like scheduled runs or an auto-publishing pipeline. In my case that's the larger share, so I lean on the router approach.

Pitfalls I Hit in Production

Two things stayed invisible during measurement and only surfaced once it was running.

First, mishandling thought_signatures in a multi-turn agent loop breaks the continuity of reasoning on later turns. In the Gemini 3 line, thinking state returns as a signature you're meant to feed back into the next request. Writing a router that switches level dynamically means rebuilding the config object each turn, and it's easy to forget to carry the signature through. The symptom is agent accuracy drifting down slowly, and it took me a while to trace. For sessions that continue a conversation, I now stack the full response (signature included) into history and swap only the config.

Second, pushing Tier 1 too far toward low occasionally produced a "fix one spot when asked to fix several" miss. Even in formatting, minimal thinking starts to matter when the targets are scattered widely. As a fix, I added a branch: if a Tier 1 task is judged to "span three or more files," that run alone is promoted to the Tier 2 budget. One exception that bumps a fixed profile up a notch by input size was enough to stabilize it.

Editor Alone vs. SDK — Where to Put the Routing

When you're working interactively in Antigravity's editor, switching level per operation isn't practical. Here I keep it to a single move — nudging "the default for light operations" toward low in the workflow settings — and bump up to high by hand only where I hesitate.

For work where the task type is fixed ahead of time, like scheduled runs or auto-publishing, a router assigning it mechanically is steadier. I lean all my recurring jobs toward the latter, and in interactive sessions I barely think about routing at all.

Same thinking_level, but whether that decision lives on the editor side or in code changes how the whole thing feels to operate. If you touch things by hand a lot, start from the editor default; if you automate heavily, start from the router. Either entry point eases you in without friction.

The Setup I Settled On

In the end, nudging Tier 1 — which dominated my daily agent runs — toward low brought total thinking tokens down by roughly 40% by feel. Meanwhile, protecting Tier 3 with high actually reduced design-level rework. My total bill went down while the felt quality went up — a rare both-ways win.

My rule when I'm unsure: "if this output were wrong, how many seconds until I'd notice?" If I'd catch it in seconds, low; if it takes minutes and the rework is heavy, high. Keeping that one sentence in the back of my mind makes the level choice almost mechanical.

The numbers shift with every model update, so don't take the values here on faith — pick three of your own representative tasks and measure them at low and high first. Fifteen minutes of measurement should keep your monthly spend lighter for a long time afterward. Thanks for reading.