Pixel 10 and the on-device model as a platform feature

Google announced the Pixel 10 line this week with Tensor G5, the first Tensor chip fabricated by TSMC rather than Samsung.

the fab change#

Tensor's history has been a story of good ideas hampered by a manufacturing process that trailed the competition. Thermal throttling, modem power draw, and sustained-performance deficits against Snapdragon and Apple silicon were consistently traceable to process node rather than architecture.

Moving to TSMC's 3nm addresses that directly. Early efficiency numbers look substantially better, which for a phone matters more than peak performance — nobody runs a benchmark all day, everybody runs a battery.

The strategic significance: Google's silicon ambition was always about controlling the ML acceleration path for on-device inference. That only works if the chip is competitive on the fundamentals, and for four generations it was not.

the developer surface#

The more relevant announcement is that Gemini Nano is exposed to third-party apps through ML Kit's GenAI APIs and the newer on-device inference paths.

val summarizer = Summarization.getClient(
    SummarizerOptions.builder(context)
        .setInputType(InputType.ARTICLE)
        .setOutputType(OutputType.ONE_BULLET)
        .build()
)
val result = summarizer.runInference(text).await()

The available primitives — summarization, proofreading, rewriting, image description — are deliberately narrow. That is a reasonable choice: a small on-device model is reliable within a bounded task and unreliable outside it, and shipping a constrained API prevents developers from discovering that the hard way.

The economics are the same as Apple's Foundation Models framework: free, private, offline, no rate limits. For app features that were not worth a server bill, that changes the calculation entirely.

the convergence#

Apple and Google have now independently arrived at the same architecture:

• A small model on device, exposed to third-party apps through a constrained system API.
• A larger model in the cloud for anything the small one cannot handle.
• A routing decision the OS makes, mostly invisible to the app.
• Privacy positioning built on the on-device path.

That is going to be the standard shape of mobile AI. Which means the useful developer skill is not "call an LLM API" but "decompose a feature so the on-device model handles the common case."

Concretely: design your feature so the 3B model handles 90% of inputs and the remaining 10% escalates. The 90% is free, instant, and offline. The 10% costs money and needs a network. Getting that split right is where the engineering is.

the caveat#

On-device models are small and they will stay small, because the constraint is memory and thermal budget in a phone, and those improve slowly. A 3B model in 2027 will be better than a 3B model today, but it will still be a 3B model.

Do not design a feature that requires frontier reasoning and hope the device catches up. It will not. Design for the envelope you have, and escalate explicitly.