Google Patents a System That Picks Between On-Device and Cloud AI in Real Time
Every time an AI feature runs on your phone, something has to decide whether to use the chip in your pocket or a server farm miles away. Google has filed a patent for a system that makes that call dynamically, scoring both options against real-world conditions before committing.
How Google's model-picker decides where your AI runs
Ever noticed that some AI features on your phone feel slower when your battery is dying or your Wi-Fi cuts out? That tension between running AI locally on your device versus sending the request to a remote server is real, and right now most apps just pick one approach and stick with it.
Google's patent describes a system that scores both options every time you send an input. It looks at conditions like your connection quality, device battery, the complexity of what you're asking, and the capabilities of each model, then picks the better one for that specific moment. If your phone is plugged in and you're on fast Wi-Fi, the calculation might land differently than if you're on the subway with 8% battery.
The goal is simple: you get the best result under whatever conditions currently exist, without having to think about it.
… determining, for each respective machine learning model of the client-side machine learning model and the server-side machine learning model, a corresponding capability value based on the plurality of attribute values …
Translation: The system calculates how well both the local phone model and the remote cloud model can handle the task right now.
How capability scores determine which AI gets the job
The system works by computing what the patent calls a capability value for each candidate model before any processing happens. Think of it like a quick score card: before routing your request, the device figures out how well the on-device model and the server-side model would each handle it right now.
That score is built from a set of attribute values, a collection of measurable conditions tied to both options. These could include:
- Network latency and bandwidth (how fast data can reach the server)
- Device battery level and available compute (how much the phone can handle locally)
- Model accuracy or output quality for the specific type of input
- Privacy or data-routing requirements
Once both capability values are calculated, the system picks the preferred model and sends the input there. The selection logic runs at runtime, meaning it happens fresh each time rather than being set once at install.
The claim is deliberately broad: it covers any client device, any server device, and any two machine-learning models compared this way. The mechanism for weighting attributes is not pinned to one specific algorithm, which is either the patent's strength or its weakness depending on how you read it.
… selecting, from the client-side machine learning model and the server-side machine learning model and based on the corresponding capability values thereof, a preferred machine learning model for processing the input data …
Translation: It then picks the best option between the device and the cloud to process your request.
What this means for AI running on your phone vs. Google's servers
For users, this is about AI features that adapt to your actual situation rather than defaulting to whichever approach an engineer hardcoded at build time. A transcription feature that always hits a server might be fast at home but sluggish and battery-draining on a train. A smarter router would pick the on-device model in that scenario automatically.
Google's steady investment in on-device AI makes this filing fit a clear pattern. As more AI features ship to phones, the tradeoff between local speed and server-side accuracy becomes a real product problem. A dynamic scoring layer would let Google (or Android app developers) handle that tradeoff per-request rather than per-product-launch, which is a quieter but genuinely useful shift.
That makes this Google's 46th filing we've tracked since May in our on-device AI privacy watchlist, extending a run that includes applications for on-device image generation and local facial recognition.
Claim 1 is wide. It covers any device obtaining input, computing capability scores for a local and a remote model, and routing based on those scores. There is no requirement about what the models do, what the attributes measure, or how the scoring formula works. That breadth is meaningful: if granted as written, it could cover a large swath of edge-AI routing decisions, not just Google's own implementation.
In practice, the patent office will likely push back on that width. Prior art in load-balancing and adaptive-bitrate streaming (which does something structurally similar for video) exists, and the claim does not describe anything inventive about the scoring method itself. The novelty argument rests on applying a known optimization pattern to ML model selection specifically.
If the claim survives examination intact, it is the kind of broad infrastructure patent that matters more to a legal team than to a product team. Developers building hybrid on-device and cloud AI features would be the ones paying attention.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
5 drawing sheets from US 2026/0267773 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →