Edge AI

The argument for running models locally used to be privacy. Here it is more specific and better reasoned: with a smaller model you can work at the full context length and largely stop worrying about compaction, because agentic workloads run locally hit hardware limits quickly. Compaction is the failure mode that quietly degrades long agent runs, when an agent forgets a constraint from forty steps ago or keeps a summary that lost the detail that mattered. Framing local inference as a way to avoid it is a real trade with a stated boundary — not that local models are better, but that capacity to hold the whole problem can beat raw capability on any single step. The threshold claim that local models are now viable for real work is the kind that changes behaviour, and thirty seconds from nothing installed to working makes the experiment nearly free.

Microsoft Build

The specification change that matters is the context window moving from 32,000 tokens to 128,000 for smaller models and up to 256,000 for larger ones, because it changes which problems are solvable without infrastructure. A 32,000-token limit means retrieval, chunking and index management; at 128,000 many tasks fit whole and the workarounds become unnecessary. The deployment range runs from a browser with zero ongoing server cost through local runtimes to one-click hosted endpoints, and the strategically significant detail is interface compatibility — a local model speaking the same protocol as hosted APIs is substitutable without changing application code, which makes placement an operational choice rather than an architectural commitment. That is what makes open weights competitive: not being better, but making switching free.

Google I/O

The case for local inference is made in three clauses representing different kinds of constraint: cost, where a local model removes an API call; availability, where the application works on a flight; and data, where requirements prevent information leaving the device. Only the third changes what is buildable rather than what is affordable. What makes this newly practical is unglamorous — instruction set extensions integrated into the runtime rather than a modelling breakthrough — with around thirty per cent improvement reported in image editing functions. The guidance on fine-tuning inverts the usual advice: adaptation matters most for the smallest models, because their capability budget is already spent and getting them to perform on your problem means spending some of it there. The two examples do the real work, since neither is a cheaper version of a cloud application.

Google I/O

The most consequential sentence here concerns what happens after the demo: sometimes you want a quickly assembled application as a proof of concept, and other times you want it to stick around with real users and persistent data. The security additions are best read as answers to the failure modes that creates — keeping prompts off the client, restricting model access to the application, rate limits preventing a few users consuming everyone's quota, ignoring prompts arriving from the client. Each assumption being corrected is one a rapidly built application makes by default, harmless in a demonstration and consequential the first day it is public. The claim that strong security rules were written by the agent deserves the most scrutiny, because an overly permissive access rule produces no visible symptom — it works fine while allowing access it should not.

Google I/O

The most instructive fix in this session is not a model change: a response was taking too long and containing too much, so the presenter constrained the prompt to a single sentence under fifteen words and got a very fast response. On a phone, output length is the cost, because every token is generated on the device's own processor while the user waits. That reorganises how these features are built, since the constrained version satisfies the product requirement and the performance requirement with the same change. The first section runs in airplane mode, which settles what is actually being demonstrated. The privacy argument is made about receipts containing card numbers, and the demonstration then reaches for the larger cloud model for the harder version of that task — a tension the session does not comment on. The structural improvement, marking a data class as generable, removes an entire category of runtime failure.

Google I/O

The most revealing moment in this segment is not the hardware but a question the assistant asks before acting: would you like to confirm. On any other device that is unremarkable; on glasses it states the entire design problem. Every consumer transaction interface built in two decades has relied on a visual review step where errors get caught, and a device worn on the face has no review screen in any meaningful sense. What replaces it is the assistant restating what it is about to do, which must contain everything a user would have checked and be short enough to listen to — two requirements that pull against each other. Adding a tip after confirmation shows this is a conversation with amendments rather than a single transaction, which makes the boundary between negotiating and committing a design decision rather than an emergent property.

Google I/O

The example that justifies this session is a farming application in rural Maharashtra translating agricultural insights and weather warnings into a regional Marathi dialect, offline. That is not a latency argument — the user is unreachable by a hosted model twice over, once through connectivity and once through dialect coverage, and neither problem is solved by a more capable model in a data centre. The most concrete engineering claim concerns speech, where a conventional approach needs a separate 100-to-200-megabyte model per language while the on-device approach needs one small adapter across all supported languages, turning a linear install cost into a nearly fixed one. The guidance to always use the smallest model that reliably solves the use case is the opposite instinct to server-side development, where there is always a later.

Google I/O

The number establishing how fast this changed is that around seventy per cent of the global telecommunications market now holds at least one non-terrestrial partnership, against a situation twelve months earlier where most operators with anything had exactly one. The framing offered is pragmatic partnership rather than competition, and the word choice does real work: satellite connectivity spent most of its history as a competing answer to the question terrestrial networks answered, and lost comprehensively on cost wherever people actually live. What changed is the question. The coverage gaps identified recur weekly or monthly and are heterogeneous — maritime, remote industrial, disaster response, rural — each with different latency tolerance and willingness to pay, which is why no single answer covers them and why the connected-device case is stronger than the consumer one.

MWC Barcelona