每项任务的成本：使用轻量级分类器在 Gemini 模型和思考级别之间进行路由

每个 token 的 API 价格持续下降，但自主编码智能体的工程账单却不断攀升。每百万 token 的价格已不再是决定生产经济效益的关键指标。如今占主导地位的指标是每项成功任务的成本：将每次循环迭代、工具调用、重试和内部思考轮次的总支出，除以通过验证的任务数量。Per-token API prices keep falling, yet engineering bills for autonomous coding agents keep climbing. Price per million tokens isn't the metric that actually governs production economics anymore. The dominating metric is now cost per successful task: total spend across every loop iteration, tool call, retry and internal thinking pass divided by the number of tasks that pass verification.

当智能体在其运行框架中为每个微小决策都调用高思考推理配置时，你就为轻量级配置已经能够准确回答的问题，付出了深度推理的代价。为避免这种不必要的开销，可以考虑添加一个轻量级路由层，在常规决策到达昂贵的推理模型之前将其拦截。这正是将 TypeSafe 的 Jev 分类器接入 Google Antigravity 模型调用前端的出发点。Jev 并非逐个 token 生成文本，而是一种专为高吞吐量决策流水线设计的结构化输出分类器，它会在一次前向传播中评估结构化分类原语：从列表中选择一个选项（Choice）、给出数值分数（Score），或返回 Noul；后者会为二元命题提供一个 0 到 1 之间的概率。When an agent calls a high-thinking reasoning configuration for every micro-decision in its harness, you're paying deep-reasoning prices for questions a lightweight configuration already answers accurately. To prevent this unnecessary overhead, consider adding a lightweight routing layer that can intercept routine decisions before they ever reach an expensive reasoning model.

That is the premise behind wiring TypeSafe's Jev classifier in front of Google Antigravity's model calls. Rather than generating text token by token, Jev—a specialized structured-output classifier designed for high-throughput decision pipelines—evaluates structured classification primitives in a single forward pass: a Choice from a list, a numeric Score or a Noul, which returns a 0 to 1 probability for a binary statement.

为了充分披露，Google 与 TypeSafe 并无合作关系，本文也不代表 Google 认可 TypeSafe 或其产品。这里以 Jev 为轻量级分类器的一个示例；同样的路由模式也可以使用其他分类器构建，包括 Google 原生分类器。例如，「开始使用判别式模型」Codelab 展示了如何在你自己的 Google Cloud 项目中，将同类分类器运行在 Google DeepMind 的开放权重模型 DiffusionGemma 上。For full disclosure, Google has no partnership with TypeSafe, and this article is not an endorsement of TypeSafe or its products. Jev is used here as one example of a lightweight classifier, and the same routing pattern can be built with other classifiers, including Google-native ones. The Getting started with discriminative models codelab, for example, runs the same kind of classifier on DiffusionGemma, Google DeepMind's open-weights model, in your own Google Cloud project.

我们使用 Gemini 和 Jev 的在线 API 运行了一项包含 50 道题、自动评分的编码智能体基准测试，以验证一个几乎免费的分类器能否为每项任务选择价格最低且仍能正确完成任务的模型。以下是我们的发现：We ran a 50-question, auto-graded, coding-agent benchmark against live Gemini and Jev APIs to test whether a near-free classifier can route each task to the cheapest model that still gets it right. Here's what we learned:

1. 基于正则表达式和 token 长度的测试框架路由器，在未见过的智能体任务上会彻底失效1. Regex and token-length harness routers collapse on unseen agent tasks

让 Jev 分派编码任务的一种天真做法，是只问一个宽泛的 Choice 问题：简单还是复杂。我们首次用 16 个编码代理任务进行测试时，Jev 几乎把所有任务都分派到了简单类别，即使有些任务需要追踪 LRU 缓存或进行模幂运算也是如此。TypeSafe 的文档明确警告不要采用这种反模式。如果一个问题需要权衡多个因素或作出元判断，就应将其拆解为原子检查。The naive way to ask Jev to route a coding task is a single broad Choice question: simple or complex. When we tested that first on 16 coding-agent tasks, Jev routed nearly everything to simple, even tasks requiring an LRU cache trace or modular exponentiation. TypeSafe's documentation warns against this exact anti-pattern. If a question weighs multiple factors or requires a meta-judgment, decompose it into an atomic check.

当我们用一个原子的 Noul 问题替换宽泛的 Choice 问题后，区分问题立刻得到了解决。这个问题是：回答它是否需要执行多个连续的计算、模拟步骤或逻辑推理，而非一次直接查找、格式检查或一步分类？When we replaced the broad Choice question with one atomic Noul question, it fixed the separation immediately. The question was: does answering this require performing more than one sequential calculation, simulation step or logical deduction, rather than a single direct lookup, format check or one-step classification?

def call_jev(question_text):
    body = {
        "state": question_text,
        "model": "jev-latest",
        "questions": {
            "multi_step": {
                "type": "noul",
                "instructions": (
                    "Answering this requires performing more than one "
                    "sequential calculation, simulation step, or logical "
                    "deduction, rather than a single direct lookup, format "
                    "check, or one-step classification."
                ),
            }
        },
    }
    # Send the request above to the classifier's API.
    # response.answers["multi_step"].noul is the probability used to route.

在最初的 16 项任务中，Jev 在首次运行时有 13 项、第二轮时有 14 项与我们手工标注的难度判断一致。许多工程团队会问，既然他们可以用 Python 编写零成本的正则表达式和提示词长度启发式规则，匹配 sequence、modulo 和 race condition 等词，或将任何超过 35 个单词的提示词升级处理，那他们是否真的需要分类器 API。On those initial 16 tasks, Jev routed 13 of 16 in agreement with our hand-labeled difficulty on the first run and 14 of 16 on the second pass. Many engineering teams ask whether they even need a classifier API when they can write a zero-cost regex and prompt-length heuristic in Python, matching words like sequence, modulo and race condition or escalating any prompt over 35 words.

在用于编写这些确切规则的 16 道开发题中，本地启发式方法答对了 15 道，得分为 93.8%。为了检验该启发式方法在面对真实代码代理流量时是否依然有效，我们将其代码原封不动地冻结，并新增了 34 道未见过的留出任务，涵盖七类代码代理任务：事实提取、架构验证、短文本分类、单跳代码检查、状态模拟轨迹、数学或逻辑推理链，以及细微的语言语义错误。On the 16 development questions used to write those exact rules, the local heuristic scored 15 of 16, or 93.8%. To test whether that heuristic survived contact with realistic coding-agent traffic, we froze its code without changing a character and added 34 unseen held-out tasks across seven coding-agent buckets: fact extraction, schema validation, short classification, single-hop code checks, state simulation traces, math or logic chains and subtle language-semantics bugs.

在34道留出题上，冻结的启发式方法准确率下降了23.2个百分点，降至70.6%。一些真实且简单的任务，例如从 Kubernetes YAML 清单中提取端口、从统一格式的 git diff 标头中提取文件路径，或从 Python traceback 中提取行号，文本长度都超过了35个词，因此触发了误报升级。相反，一些简洁的多步代码追踪任务，例如跨多次调用的可变默认参数、Python 字典键对 {1: "a", True: "b", 1.0: "c"} 的哈希处理，以及 C 语言的短路求值，并不包含启发式方法硬编码的谜题关键词，因此被错误地分流到了简单任务路径。Jev 对全部34项未见过的任务都做出了判断，结果一致率为100.0%（34项中34项），在完整测试套件中达到50项中的48项，即96.0%。On the 34 held-out questions, the frozen heuristic dropped 23.2 percentage points to 70.6%. Realistic simple tasks such as extracting a port from a Kubernetes YAML manifest, a file path from a unified git diff header or a line number from a Python traceback exceeded 35 words and triggered false escalations. Conversely, concise multi-step code traces such as mutable default arguments across calls, Python dictionary key hashing on {1: "a", True: "b", 1.0: "c"} and C short-circuit evaluation lacked the heuristic's hardcoded puzzle words and were falsely routed to the simple path. Jev classified all 34 unseen tasks with 100.0% agreement, 34 of 34, reaching 48 of 50, or 96.0%, across the full suite.

2. MaxOutputTokens 是上限，不是思考预算调节旋钮2. MaxOutputTokens is a ceiling, not a thinking-budget dial

构建快速通道路由器时，一个常见的错误是认为，给推理模型设置较低的 maxOutputTokens 上限，就能让它在简单任务上少花算力。我们的 50 道题数据说明了这种假设为何不成立。A common mistake when building a fast-path router is assuming that setting a low maxOutputTokens cap on a reasoning model will make it spend less on easy tasks. Our 50-question data shows why that assumption fails.

当我们在将 thinkingConfig 保持为 API 默认值的情况下，对比 maxOutputTokens=300 的 gemini-3.8-flash 和 maxOutputTokens=4096 的 gemini-3.8-flash 时，这两种配置在 Jev 标记为 SIMPLE 的 27 项任务上消耗的思考 token 几乎完全相同：When we compared gemini-3.8-flash with maxOutputTokens=300 against gemini-3.8-flash with maxOutputTokens=4096 while leaving thinkingConfig at the API default, both configurations spent almost identical thinking tokens on the 27 tasks Jev labeled SIMPLE:

注意：这些数值反映的是在一组示例测试套件上进行单次运行的实验测量结果；实际延迟、令牌数量和计费成本会因提示词长度、上下文缓存和生产负载而异。Note: Figures reflect single-run experimental measurements on a sample test suite; actual latencies, token counts, and billed costs will vary based on prompt length, context caching, and production load.

将模型的输出限制在 300 个 token，并没有让简单任务省下任何钱。这个上限只是一个天花板，而简单任务的回答从来都远没有达到它。在简单任务上，设置上限的版本实际上比不设上限的版本稍微贵一些。这个上限唯一造成的影响，就是让 25 个难题中的 7 个无法完成。其中 6 题里，模型还在推理时就耗尽了输出空间，最终没有给出答案。第 7 题中，模型压缩了推理过程以适应限制，按时完成了回答，但答案错了。Capping the model's output at 300 tokens didn't save any money on easy tasks. The cap is only a ceiling, and easy answers never came close to it. On the easy tasks, the capped version actually cost slightly more than the uncapped one. All the cap did was break 7 of the 25 hard tasks. On six of them, the model ran out of room while still reasoning and never gave an answer. On the seventh, it squeezed its reasoning to fit, finished on time and got the answer wrong.

因此，一个将简单任务交给受限模型、将困难任务交给普通 Flash 的 Jev 路由器，50 道题全都答对了。但它的成本仍略高于跳过路由器、所有任务都使用普通 Flash，而且速度更慢。如果你的廉价选项并没有真正让模型在处理简单任务时少思考，那么再好的路由器也省不了钱——哪怕它完美无缺，而且完全免费。So a Jev router that sends easy tasks to the capped model and hard ones to normal Flash got all 50 right. It still cost slightly more than skipping the router and using normal Flash for everything, and it was slower. If your cheap option doesn't actually make the model think less on easy tasks, no router can save you money. Not even a perfect one that costs nothing.

3. 将 Jev 与不使用路由器的最强配置进行基准测试3. Benchmark Jev against the strongest setup without a router

减少思考成本，显而易见的方法就是让模型少思考。于是我们用两个更轻量的选项进行了第二轮测试：默认完全不思考的 Flash-Lite，以及将思考级别设为低的 Gemini 3.8 Flash。我们把这些结果加入同一个结果文件，并按问题逐一匹配。The obvious way to spend less on thinking is to ask the model to think less. So we ran a second round of tests with two lighter options: Flash-Lite, which doesn't think at all by default, and Gemini 3.8 Flash with its thinking level set to low. We added those results to the same results file, matched question by question.

关于耗时的说明。路由器处理每项任务所花的大部分时间都耗在 Flash-Lite 和 Flash 调用上；我们测量这两者时，使用的运行过程和时间窗口与纯 Flash 基线相同，因此它们之间的速度比较是公平的。Jev 自身做出决策所花的时间只占总耗时的一小部分，且来自第一轮。与默认 Flash 或 Pro 的速度比较混合了两轮数据，因此应将其视为近似值。A note on timing. Most of the router's time per task is spent in Flash-Lite and Flash calls, which we measured in the same run and time window as the plain Flash baseline, so the speed comparison between them is fair. Jev's own decision is a small share of the total and comes from the first round. Speed comparisons against default Flash or Pro mix the two rounds, so read those as approximate.

注：这些数据反映的是在一组样例测试套件上单次运行的实验测量结果；实际延迟、令牌数量和计费成本会因提示长度、上下文缓存和生产负载而有所不同。Note: Figures reflect single-run experimental measurements on a sample test suite; actual latencies, token counts, and billed costs will vary based on prompt length, context caching, and production load.

7 个类别的细分结果展示了 gemini-3.5-flash-lite 和启发式路由器在哪些任务上出错，以及 Router Jev: Flash-Lite to 3.8 LOW 如何恢复到 100% 的准确率：The 7-bucket breakdown shows where gemini-3.5-flash-lite and the heuristic router missed tasks and how Router Jev: Flash-Lite to 3.8 LOW recovered 100% accuracy:

不使用路由器时，表现最强的配置是将 Gemini 3.8 Flash 设为低思考模式。它解决了全部 50 项任务。这就是路由器必须超越的成绩。The strongest setup without a router was Gemini 3.8 Flash on low thinking. It solved all 50 tasks. That's the number a router had to beat.

Jev 路由器表现更好。它会先把每项任务都交给 Flash-Lite 处理，只将 Jev 标记为复杂的任务升级处理。它还解决了全部 50 项任务；与对所有任务都使用低思考级别相比，它有助于降低成本和响应时间。对于这么短的提示词，每项任务的成本差异很小，因此对交互式智能体来说，缩短等待时间的好处更大。The Jev router beat it. It sends every task to Flash-Lite first and escalates only what Jev flags as complex. It also solved all 50 tasks, and it can help reduce both cost and response time compared with running low thinking on everything. On prompts this short the cost difference per task is small, so for an interactive agent the shorter wait is the bigger benefit.

其奏效的原因。Flash-Lite 能在半秒内回答每个简单任务，但在 25 个难题中有 6 个没答出来。Jev 以很高的置信度将这 6 个任务都标记为复杂任务，并将它们升级处理。这样一来，它的成本就接近完美路由器所能达到的水平。Why it works. On its own, Flash-Lite answered every simple task in half a second but missed 6 of the 25 hard ones. Jev flagged all 6 as complex with high confidence and escalated them. That brought its cost close to what a perfect router would achieve.

关键词启发式方案成本更低，但只是因为它判断错了。它把 5 个难任务交给了 Flash-Lite，其中 2 个失败，最终 50 个任务中答对了 48 个。The keyword heuristic was cheaper, but only because it got things wrong. It sent 5 hard tasks to Flash-Lite, and 2 of them failed, for 48 of 50.

在这里升级到更高强度的设置并不划算。将困难任务路由到使用默认思考模式的 Flash，比所有任务都使用默认思考模式更便宜。不过，这仍比所有任务都使用低思考模式更贵，而低思考模式已经解决了全部 50 个任务。只有当低设置开始失败时，升级到更高强度的目标才有意义。Escalating to a heavier setting didn't pay here. Routing hard tasks to Flash on default thinking was cheaper than running default thinking everywhere. It still cost more than running low thinking on everything, which already solved all 50. A heavier escalation target only makes sense when the low setting starts failing.

限制：每种设置运行一次，共 50 条提示，难度由人工指定，并采用简单的自动评分。Limits: one run per setup, 50 prompts with hand-assigned difficulty and simple automatic grading.

4. 每个 token 的价格并不能说明全部情况4. Price per token doesn't tell the whole story

我们的结果中有两点，只有看透表象之后才会显现。Two things in our results only show up once you look past it.

路由和缓存的作用方向彼此相反。我们的测试提示词都是简短、独立的任务；对于这类任务，Jev 路由器有助于同时降低成本和响应时间。实际的编程代理往往并非如此。它们每轮都会发送同一大块上下文，例如代码库地图和工具定义。Agent Platform Context Caching 会存储这部分内容，让你在重复发送时节省 75% 到 90% 的费用。问题在于，缓存只能属于一个模型。如果你的代理每轮都在 Flash-Lite 和 Flash 之间切换，就只能保留两份缓存，或者放弃折扣。实际做法是：将日志解析或架构检查这类简短、独立的任务交给路由器处理；而长时间、上下文密集的对话则始终使用同一个模型。Routing and caching pull in opposite directions. Our test prompts were short, standalone tasks, and on those the Jev router helped reduce both cost and response time. Real coding agents often look different. They send the same big block of context on every turn, such as a map of the repository and the tool definitions. Agent Platform Context Caching stores that block so you pay 75% to 90% less to resend it. The catch is that a cache belongs to one model. If your agent switches between Flash-Lite and Flash from turn to turn, it either keeps two caches or loses the discount. The practical split: route short, self-contained tasks like log parsing or schema checks, and keep long, context-heavy turns on one model.

根据工作负载选择匹配的模型。Gemini 3.1 Pro 专为深度、多步骤推理而打造，并会将同样的推理深度用于每个请求，包括那些并不需要这种能力的简短查询。对于主要由快速检查和信息提取构成的工作负载，Flash 配置更合适；Pro 则最好留给需要其深度推理能力的任务。不同的模型配置还可以针对与安全相关的提示采用不同的安全设置。在我们的测试中，Pro 配置拒绝了两个简短的代码安全审查提示，而 Flash 回答了它们。如果你的智能体会执行安全审查，请在计划使用的配置上测试这些提示。Match the model to the workload. Gemini 3.1 Pro is built for deep, multi-step reasoning, and it brings that same depth to every request, including short lookups that don't need it. For a workload made mostly of quick checks and extractions, a Flash configuration is the better fit, and Pro is best saved for the tasks that need its reasoning depth. Model configurations can also apply different safety settings to security-related prompts. In our run, the Pro configuration declined two short code-security review prompts that Flash answered. If your agent performs security reviews, test those prompts on the configuration you plan to use.

每项成功任务的成本需要采用正确的分母Cost per successful task needs the right denominator

构建路由器的其他方式。Jev 是实现快速分类器的一种方法，但并非唯一选择。“使用判别式模型入门”代码实验会在 DiffusionGemma（Google DeepMind 的开放权重模型）上运行相同的 Choice、Score 和 Noul 问题；该模型托管在 Compute Engine GPU 虚拟机上，或托管在你自己的 Google Cloud 项目中的 Cloud Run 上。一个开源服务器在模型前端提供相同的 API，因此本文中的路由代码只需更换端点即可。我们的结果来自 Jev，因此切换之前，请在自己的任务上测量准确率和延迟，并记住，自托管模型按 GPU 小时计费，而不是按 token 计费。Other ways to build the router. Jev is one way to get a fast classifier, but not the only one. The Getting started with discriminative models codelab runs the same Choice, Score and Noul questions on DiffusionGemma, Google DeepMind's open-weights model, hosted on a Compute Engine GPU VM or on Cloud Run in your own Google Cloud project. An open-source server exposes the same API in front of it, so the routing code in this article only needs a different endpoint. Our results come from Jev, so measure accuracy and latency on your own tasks before switching, and keep in mind that a self-hosted model is billed by the GPU-hour rather than by the token.

综合来看，这些结果给出了三条实用规则。Taken together, the results give three practical rules.

构建路由器之前，先使用低思考级别的 Flash。它完成了全部 50 项任务，成本也比默认设置低得多。降低输出令牌上限并不能替代这一做法，因为这不会减少模型在简单任务上的思考量。直接设置思考级别：thinkingLevel: "LOW"。Start with Flash on low thinking before you build a router. It solved all 50 tasks and cost considerably less than the default setting. Lowering the output token limit is not a substitute, because it doesn't reduce how much the model thinks on easy tasks. Set the thinking level directly, with thinkingLevel: "LOW".

使用 Jev 路由简短、独立的任务。将简单任务交给 Flash-Lite，难题交给低思考模式下的 Flash。针对每个因素，每次只向 Jev 提出一个简单的是非问题。在我们的测试中，与所有任务都使用低思考模式下的 Flash 相比，这种做法有助于降低成本、缩短响应时间，效果也接近完美路由器。对于上下文很长、信息量很大的轮次，继续使用同一个模型，以便缓存持续生效。对于高吞吐量的数据仓库工作负载，Jeff Nelson 的 BigQuery 与 Cloud Run 级联模式也采用了同样的思路。Use Jev to route short, standalone tasks. Send simple tasks to Flash-Lite and hard ones to Flash on low thinking. Ask Jev one simple yes-or-no question per factor. In our test, this helped reduce cost and response time compared with running Flash on low thinking for everything, and came close to what a perfect router would achieve. Keep long, context-heavy turns on a single model so caching keeps working. For high-volume warehouse workloads, Jeff Nelson's BigQuery and Cloud Run cascade pattern applies the same idea.

衡量你的智能体实际花费了多少。将智能体的跟踪记录和思考 token 数量发送到 Cloud Logging 和 BigQuery，这样你就能看出哪些任务推高了开支，并发现会增加开支的截断或重试情况。基准测试代码将在开源审查后发布。Measure what your agent actually spends. Send your agent's traces and thinking-token counts to Cloud Logging and BigQuery, so you can see which tasks drive your spend and catch truncation or retries that inflate it. The benchmark code will be published after open-source review.

总之，运行智能体最具成本效益的方式，是为每项任务匹配最合适的模型。先用轻量配置运行快速模型，你往往会发现它已经足以完成任务。然后加入一个小巧且几乎免费的分类器（如 Jev），只把困难任务交给更强的模型，并且提出简单的“是或否”问题，而不是一个宽泛的问题。评估每种方案时，应看它正确完成每项任务的成本，而不是每个 token 的成本。In summary, the most cost-effective way to run an agent is to match each task to the model that fits it. Start with a fast model on a light setting. You'll often find it already gets the job done. Then add a small, almost free classifier like Jev to send only the hard tasks to a stronger model, and ask simple yes-or-no questions rather than one broad one. Judge every option by what it costs per task done right, not per token.