← Back to Blog

Gemini 3.7 Flash Is a Reminder: Your AI Product Needs a Model Routing Policy

Dhaval Bhatt
A luminous AI workflow splitting through a routing junction toward three different model cores on a dark violet background

Google released Gemini 3.7 Flash yesterday—just three weeks after releasing Gemini 3.6 Flash.

The newer model is positioned as more capable for coding and agents. Its introductory API price is also half the original 3.6 Flash price per million tokens through the end of 2026.

That is good news for builders. It is also a warning.

If your AI product is hardwired to one model, every major release becomes an emergency migration decision. If the model is embedded across prompts, workflows, and business rules, switching can break quality in ways the pricing page will never show you.

The better question is not, “Which model should power my product?”

It is, “Which model should handle each kind of work—and what happens when that model is too expensive, too slow, or unavailable?”

That is a model routing policy.

One model is rarely best for every customer task

Founders often choose the strongest model they can afford, connect it to the product, and move on. That is reasonable for an early prototype. It becomes expensive and fragile in production.

Your product probably does several different jobs:

  • classify an incoming request;
  • extract fields from a document;
  • retrieve relevant context;
  • draft a response;
  • reason through an unusual case;
  • call a tool;
  • explain a recommendation to a customer.

These jobs do not need the same level of intelligence.

A low-cost model may handle routine classification reliably. A stronger model may be justified for ambiguous cases where the output affects money, compliance, or a customer relationship. Some actions should not route to another model at all. They should route to a person.

This is where domain expertise matters. A general builder sees API calls. You know which decisions are routine, which exceptions are dangerous, and where a confident wrong answer creates real damage.

That judgment becomes the routing logic.

Faster model releases make hardwiring more expensive

Gemini 3.6 Flash launched on July 21 at $1.50 per million input tokens and $7.50 per million output tokens. On August 13, Google introduced 3.7 Flash at an introductory price of $0.75 per million input tokens and $3.75 per million output tokens through December 31.

Google also reported stronger results for 3.7 Flash across several coding, document, and workflow benchmarks. Those numbers are useful signals. They are not proof that the model will perform your customer’s job better.

Your own evals still decide that.

But the three-week release gap shows why model choice should be treated as a changeable policy, not permanent product architecture. Capability, price, latency, and availability can move before your roadmap meeting happens.

The market is already building around this reality. Cloudflare’s AI Gateway supports dynamic routes that choose models based on conditions, enforce quotas and budgets, split traffic for tests, and fall back when a request fails. Naïve, an agent infrastructure startup, told TechCrunch that inference optimization is one of its fastest-growing areas of demand and that it is building a model router to send tasks to more efficient models.

You do not need enterprise infrastructure on day one. You do need the same operating idea: separate the customer job from the model that happens to perform it today.

Write the policy before you build the router

Start with one high-value workflow. List the steps your product performs and give each step a routing rule.

A practical first version can fit in a spreadsheet:

TaskDefault routeEscalation ruleHuman checkpoint
Classify requestFast, low-cost modelConfidence below thresholdNo
Extract required fieldsEfficient modelMissing or conflicting fieldsReview exception
Draft recommendationBalanced modelHigh-risk categoryRequired
Explain unusual caseStrong reasoning modelUnsupported evidenceRequired

For every task, define five things:

  1. Quality bar: What must be true for the output to be useful?
  2. Default route: What is the least expensive model that reliably clears that bar?
  3. Escalation trigger: What uncertainty, risk, or complexity sends the task elsewhere?
  4. Fallback: What happens if the preferred model errors or times out?
  5. Stop condition: When must the system pause and ask a person?

Notice that the policy starts with the work, not a provider name.

“Use Model X everywhere” is a vendor choice. “Use the lowest-cost route that passes the underwriting classification eval, then escalate conflicting evidence for expert review” is a product rule.

The second one can survive the next launch.

Route with evidence, not benchmark excitement

A routing policy only works if you can test it.

Build a small eval set for each important route. Include normal cases, edge cases, past failures, and examples where the correct action is to stop. Then compare candidate models on four measures:

  • task success;
  • cost per completed task;
  • response time;
  • escalation or failure rate.

Do not optimize token price in isolation. A cheaper model that needs three retries, creates more support work, or misses important exceptions may cost more at the business level.

Run new models against the same cases before changing traffic. If the candidate passes, send it a small percentage of low-risk requests. Watch real outcomes. Expand only when the evidence holds.

This gives you a controlled way to benefit from fast-moving models without turning customers into the test set.

Your moat is the decision system

Models will keep getting better. Prices will keep moving. New providers will appear. That is not a reason to delay your product.

It is a reason to build the durable layer in the right place.

Your moat is not the name in the API call. It is the system that knows:

  • what the customer is trying to accomplish;
  • which evidence matters;
  • what “good” looks like;
  • when a cheaper route is safe;
  • when a stronger route is worth the cost;
  • when automation must stop.

That system comes from domain experience, customer feedback, and disciplined testing. The models compete underneath it.

Gemini 3.7 Flash may be the right default for part of your product. Three weeks from now, something else may be better. A routing policy lets you take advantage of that progress without rebuilding the business around every release.

If you want help turning a workflow you understand into a focused AI product, a testable model strategy, and a 12-week launch plan, book a strategy call. That is the work we do inside AI Product Accelerator.

Sources