Every phone launch now includes claims about on-device intelligence and dedicated processing hardware. Some of that describes genuinely useful capability and a good deal of it describes things that were already happening.

What has been running locally for years

Worth establishing, because the recent marketing implies novelty that is not there.

Computational photography, which merges frames, reduces noise and applies scene-specific processing. This has been on-device for years and is the largest practical application.

Voice recognition for wake words, and increasingly for full transcription.

Face and object recognition in photo libraries, for search and organisation.

Text prediction and autocorrect.

Live translation and captioning in some implementations.

All of these predate the current wave of marketing and all of them use the same dedicated hardware now being advertised as new.

Why local processing genuinely matters

Three real advantages, independent of any marketing.

Privacy. Data processed on the device does not leave it. For voice, images and messages this is a meaningful difference, and it is the strongest argument for the approach.

Latency. A local model responds without a network round trip, which for anything interactive is the difference between usable and not.

Availability. It works without a connection, which matters more than people in well-connected places assume.

Against those, local models are smaller and less capable than what runs in a data centre, and they consume battery.

The hybrid reality

What most implementations actually do, which is rarely stated clearly.

Simple requests are handled locally. Complex ones are sent to servers.

The decision about which is which is made by the system, not by the user, and it is frequently not disclosed at the moment it happens.

Which means a feature advertised as on-device may route a substantial proportion of requests off the device, and the privacy claim attached to it is correspondingly weaker than it sounds.

Some manufacturers have published architecture describing how this is handled, including approaches where server processing occurs in environments designed so that the operator cannot inspect the data. Those are meaningful engineering efforts and they are also complex enough that most users cannot evaluate them.

The practical position is to read the specific claim rather than the general one, and to check whether there is a setting controlling it.

What is actually useful in daily use

From using these features rather than reading about them.

Transcription and live captioning, which is genuinely transformative for accessibility and useful for everybody in meetings and voice notes.

Photo search by content, which quietly became excellent and which most people underuse.

Object removal and background editing, which works well enough to be routine rather than a novelty.

Translation, particularly live conversation translation, which is imperfect and remarkable.

And summarisation of long text, which is useful and which requires care because summaries lose caveats.

What is mostly marketing

Assistant features that reword messages, which produce output that sounds like nobody.

Generative image editing that produces plausible content that was not there, which is entertaining and has obvious problems when applied to photographs presented as records.

Anything described as understanding context across applications, which in practice is a small number of scripted integrations.

And performance figures quoted in operations per second, which are not comparable between manufacturers and correspond to nothing a user experiences.

The battery and thermal cost

A practical point that gets no coverage.

Running models locally is computationally expensive and produces heat and battery drain.

Features that run continuously — always-on listening, continuous scene analysis — have a measurable cost, which is why several are off by default and why enabling all of them noticeably shortens runtime.

Worth checking what is enabled and turning off what you do not use, which is a five minute exercise that has a visible effect.

What I would take from it

The dedicated hardware is real and has been for several generations.

The genuinely valuable applications are unglamorous — transcription, search, photography — and they mostly do not appear in the launch presentations.

And the privacy advantage of local processing is real where processing is actually local, which requires reading the specific claim rather than the headline.

What to check in the settings

Practical, since most of this is configurable and the defaults are not always what people would choose.

Look for a section covering intelligence or assistant features, and check what is enabled, what sends data off the device, and whether there is an option to restrict processing to local only.

Several implementations offer exactly that toggle, with a stated reduction in capability, which is an honest trade clearly presented.

Also worth checking what is retained and for how long, and whether there is an option to delete history, which there generally is and which almost nobody uses.

The storage cost

A practical consequence nobody mentions at launch.

Models held locally occupy storage, and the larger ones occupy several gigabytes. On a device with modest capacity that is a meaningful share.

Some implementations download models on demand and cache them, which means the space usage grows over time in a way that is not obvious from any settings screen.

Worth checking storage breakdown occasionally if space becomes tight, since this is now a category that did not exist a few years ago and is not always labelled clearly.