AI on smart glasses

"AI on smart glasses" sounds like one feature, but for a developer it's three separable primitives wired in a line: voice in (capture the wearer's speech), the AI (an LLM or agent that decides what to do), and voice out (speak the answer back). Almost every platform in this category exposes those three primitives — even the ones whose branded assistant is sealed shut. The reserved assistant and the buildable pipeline are different questions, and conflating them is the most common way developers mis-scope a glasses AI project.

This page teaches that distinction: where the first-party assistant is closed, where you bring your own model, how the AI can sit phone-side / in the cloud / on the device, and what the wake-word constraint actually blocks. It places each platform on that map and links to the per-vendor pages for the specifics.

The surface that generalizes

Strip away branding and a glasses "AI assistant" is a pipeline:

  microphone ──▶  speech-to-text  ──▶   your AI    ──▶  text-to-speech ──▶  speaker
  (voice in)        (STT)          (LLM / agent / tool loop)   (TTS)        (voice out)

The pipeline is what generalizes. A platform can reserve its own assistant (the thing that answers to a branded wake word) while still handing you the microphone, an STT stream, and a way to speak audio back — which is everything you need to run your model in the middle. So the useful question is never "does it have AI?" but two sharper ones:

1. Is the first-party assistant open to third parties? Almost always no (see the next section).
2. Can I get voice in and voice out to run my own model? Almost always yes — that's the surface Extentos and every serious glasses app build on.

Where the two diverge is placement — whether the AI runs on the phone, in the cloud, or on the glasses themselves — and invocation — whether you can trigger it hands-free without colliding with a reserved wake word.

First-party assistants are usually reserved

The branded assistant — the one wired to the hardware button and the vendor's wake word — is closed to third-party code on nearly every platform. It's a product surface the vendor owns, not an API. Treat first-party assistant access as the exception, not the default:

Two nuances worth internalizing. First, "reserved" usually means the wake word and the button, not the microphone — Meta AI is closed, but Meta's DAT still routes glasses audio to your phone app. Second, a handful of platforms deliberately don't seal the assistant: Rokid reserves the wake phrase but lets you swap the model behind it, and Mentra surfaces its Mira assistant as callable tools plus a transcription-event stream rather than an opaque service. Those are the outliers; design for the closed case and treat openness as a bonus.

Several platforms ship no first-party assistant at all — Vuzix, Even Realities, Epson Moverio, XREAL, VITURE, Iristick (on-device voice control only, no AI), Lenovo ThinkReality, and Jorjin. On those, there's nothing to be locked out of — the AI is entirely yours to bring.

Bringing your own AI

Because the assistant is usually closed but the pipeline is usually open, bring-your-own-AI is the mainstream path, not a fallback. What differs across platforms is where the model runs. Three placements, each with real trade-offs:

Phone-side

The AI runs in a companion app on the paired phone; the glasses are a microphone-and-speaker (and maybe display) peripheral. This is the lowest-friction path — you ship an ordinary phone app, use any model SDK, and the glasses never need to run inference. It's the model for display-less or thin-client hardware: Vuzix (BYO-AI fully open; the Z100 is a Bluetooth display peripheral, so the app is a phone app), Solos (audio-first, no HUD — voice in, your AI, voice out), MICROOLED ActiveLook (open BLE SDK, no first-party AI), and Even Realities (BYO-AI via fetch from the companion, no assistant API). It is also Extentos's model — see where Extentos fits below.

Cloud / gateway

The glasses (or the phone) reach a hosted model, often through a vendor-provided gateway that handles auth and network egress. Snap Spectacles is the clearest example: its Remote Service Gateway lets a Lens call out to your own AI backend, and — importantly — such bring-your-own-AI Lenses are publicly publishable through Lens Explorer, not stuck in an experimental sandbox. Rokid exposes a comparably open cloud/BYO-model agent path, and INMO is building a managed agent layer (an n8n-style workflow platform, currently beta) alongside its open BYO-AI story.

On-device

The model runs on the glasses themselves. This is the frontier, and it's advancing fastest on the open platforms. Brilliant Labs is the reference point: an on-device Lua VM over plain BLE plus an open-source, self-hostable, BYO-key assistant — you own the whole stack, model included. Omi (OmiGlass) offers full AI access with BYO keys or local models. And the standalone-Android devices — INMO Air3 (Android 14 with Play Store) and RayNeo X-series (standalone APKs, not phone-companion) — can host inference on-glasses because they're full computers, not peripherals. Rokid's on-glasses AIUI runtime (an open-source JavaScript/JSAR web layer) is a related trend: app logic, and increasingly AI glue, running on the lens.

On-device buys you latency and privacy at the cost of the compute/thermal budget of a wearable. Today it's most practical for small models, wake/keyword spotting, and routing — with the heavy generation still delegated to the phone or cloud. Expect the split point to keep moving on-device as the hardware improves.

Voice invocation and wake words

Hands-free invocation is where "bring your own AI" hits its sharpest limit. The pipeline is open, but the trigger often isn't: the vendor's branded wake word is reserved, and on some platforms it's the only truly hands-free path.

• Reserved wake words you cannot bind: "Hey Meta" (Meta), "OK Amu" (INMO), and the platform wake phrase on Rokid. Firing your AI on those phrases is not available.
• Your own wake path generally means phone-side keyword spotting on a continuous transcript — you run STT and match your own trigger phrase, rather than getting a hardware "wake" event. That works wherever you get a live mic/STT stream (most phone-companion platforms), at the cost of running detection yourself.
• Button and gesture invocation is the reliable fallback where a wake word is reserved: bind a tap, a button, or a captouch gesture to open your session, sidestepping the wake-word wall entirely.

The practical rule: don't design an AI feature around a hands-free wake word until you've confirmed the platform gives you a bindable trigger. If it doesn't, build on a continuous-transcript keyword spotter or an explicit button/gesture — both generalize across the whole category.

Where each platform sits

Putting the three questions together — first-party assistant, BYO-AI placement, invocation:

Platforms with no first-party AI surface at all — Epson Moverio, XREAL, VITURE, Iristick, Lenovo ThinkReality, Jorjin — are pure phone-side BYO-AI: whatever you build is the only AI on the device. Emteq is a special case: its ML is sensing (affect/expression), not a conversational assistant, and it's not open to third-party models.

Where Extentos fits

Extentos targets Meta today, where Meta AI is closed — so Extentos is a concrete instance of the pattern this page describes: the branded assistant is reserved, but the voice-in → AI → voice-out surface is open, and Extentos builds on that surface. Its assistant runtime wraps the full pipeline (wake, STT, tool-calling model, TTS, barge-in) behind one API, running the model phone-side / cloud through a managed gateway — the same placement as Vuzix, Solos, and Even Realities in the table above, just packaged as a capability instead of a hand-wired pipeline.

The reason this generalizes is structural: Extentos's capability vocabulary — microphone, STT, speak, voice triggers — is the same voice-in/voice-out surface every vendor exposes in some form. A closed first-party assistant on the next vendor doesn't block an Extentos app, because the app was never depending on it. That's the whole bet: build on the pipeline that's open everywhere, not the assistant that's closed almost everywhere. (Extentos doesn't and can't expose a vendor's reserved wake word or first-party assistant — those stay the vendor's, as they do for any third party.)

Related

• The assistant runtime — Extentos's voice-in → AI → voice-out pipeline as one API
• The managed AI gateway — where the cloud-placement model actually runs and meters
• Capabilities — the vendor-agnostic microphone/STT/speak vocabulary this all builds on
• Vendors — the full per-platform reference this page draws from

Related