---
title: "AI on smart glasses"
seoTitle: "AI on smart glasses: reserved assistants vs. bring-your-own-AI across platforms"
description: "How third-party AI works across smart-glasses platforms — which first-party assistants are reserved (Meta AI, Gemini, Ari), where you bring your own AI (phone-side, cloud, on-device), wake-word limits, and the voice-in → AI → voice-out surface that generalizes even where the assistant is closed."
type: guide
platform: all
related:
  - /docs/ecosystem
  - /docs/ecosystem/distribution
  - /docs/ecosystem/openness
  - /docs/concepts/assistant
---

"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](/docs/vendors) for the specifics.

## The surface that generalizes

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

```text
  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:

| Platform | First-party assistant | Open to your code? |
|---|---|---|
| [Meta](/docs/vendors/meta) | Meta AI ("Hey Meta") | No — closed to third parties |
| [Android XR](/docs/vendors) | Gemini | No — system assistant, GA-gated |
| DigiLens | Google Gemini voice (via Google Cloud) | No — wired to the OS |
| RealWear | Ari | End-user assistant; you build apps *around* it |
| [RayNeo](/docs/ecosystem/platforms/rayneo) | Gemini (West) / Qwen (China) | No — closed **and** region-split by firmware |
| [INMO](/docs/ecosystem/platforms/inmo) | "OK Amu" | No — reserved wake word; managed agent layer is separate |
| [Rokid](/docs/ecosystem/platforms/rokid) | Platform assistant | Wake word reserved, but **open at the model layer** |
| Mentra | Mira | Exposed as **tools + transcription events**, not a sealed box |

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](/docs/ecosystem/platforms/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](/docs/ecosystem/platforms/vuzix), [Even Realities](/docs/ecosystem/platforms/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](/docs/ecosystem/platforms/vuzix) (BYO-AI fully open; the Z100 is a Bluetooth display peripheral, so the app *is* a phone app), [Solos](/docs/ecosystem/platforms/solos) (audio-first, no HUD — voice in, your AI, voice out), MICROOLED ActiveLook (open BLE SDK, no first-party AI), and [Even Realities](/docs/ecosystem/platforms/even-realities) (BYO-AI via `fetch` from the companion, no assistant API). It is also **Extentos's model** — see [where Extentos fits](#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](/docs/ecosystem/platforms/snap) 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](/docs/ecosystem/platforms/rokid) exposes a comparably open cloud/BYO-model agent path, and [INMO](/docs/ecosystem/platforms/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](/docs/ecosystem/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](/docs/ecosystem/platforms/inmo) (Android 14 with Play Store) and [RayNeo](/docs/ecosystem/platforms/rayneo) X-series (standalone APKs, not phone-companion) — can host inference on-glasses because they're full computers, not peripherals. [Rokid](/docs/ecosystem/platforms/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](/docs/vendors/meta)), "OK Amu" ([INMO](/docs/ecosystem/platforms/inmo)), and the platform wake phrase on [Rokid](/docs/ecosystem/platforms/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:

| Platform | First-party assistant | Your AI runs | Notable |
|---|---|---|---|
| [Snap](/docs/ecosystem/platforms/snap) | None open | Cloud (Remote Service Gateway) | BYO-AI Lenses are *publicly publishable* |
| [Brilliant Labs](/docs/ecosystem/platforms/brilliant-labs) | OSS, BYO-key | On-device + self-host | Most open; you own the whole stack |
| [Rokid](/docs/ecosystem/platforms/rokid) | Wake reserved, model open | Cloud / on-glasses (AIUI) | Open at the model layer |
| [RayNeo](/docs/ecosystem/platforms/rayneo) | Closed, region-split | In your standalone APK | Gemini (West) / Qwen (China) |
| [Vuzix](/docs/ecosystem/platforms/vuzix) | None | Phone-side | Display-only peripheral; BYO-AI fully open |
| [Solos](/docs/ecosystem/platforms/solos) | Closed | Phone-side | Audio-first, no HUD |
| [INMO](/docs/ecosystem/platforms/inmo) | "OK Amu" reserved | On-glasses + managed layer | Standalone Android 14; agent platform (beta) |
| [Even Realities](/docs/ecosystem/platforms/even-realities) | None | Phone-side (`fetch`) | No assistant API |
| Omi | None | On-device / BYO keys | Full AI access, local models |
| Mentra | Mira (as tools) | Phone-side | Transcription events + tool calls |
| [Meta](/docs/vendors/meta) | Meta AI, closed | Phone-side (DAT companion) | Production target for Extentos |
| [Android XR](/docs/vendors) | Gemini, closed | System / your app | GA-gated |

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](/docs/vendors/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](/docs/concepts/assistant) 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](/docs/concepts/ai-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](/docs/concepts/capabilities) — 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](/docs/concepts/assistant) — Extentos's voice-in → AI → voice-out pipeline as one API
- [The managed AI gateway](/docs/concepts/ai-gateway) — where the cloud-placement model actually runs and meters
- [Capabilities](/docs/concepts/capabilities) — the vendor-agnostic microphone/STT/speak vocabulary this all builds on
- [Vendors](/docs/vendors) — the full per-platform reference this page draws from