Brilliant Labs
Brilliant Labs for third-party developers — SDK access, app model, distribution, capabilities & AI, and where it sits in the 2026 smart-glasses landscape.
Openness verdict. The most open platform in the category: OSS multi-language SDKs (BSD-3/MIT) + an on-device Lua VM over plain BLE, a first-party IDE (AR Studio) and a complete open-source reference host app, open hardware/firmware/design files, and an open-source self-hostable BYO-key assistant — with no gatekeeper on either building or shipping, since you distribute your own host app.
Covered here: Frame (shipping) · Halo (ships week of July 20, 2026).
Not covered here: Monocle.
Overview
Brilliant Labs is a Singapore/Hong-Kong open-source hardware startup that builds developer-first AI smart glasses. Two models are in scope. Frame (shipping) is a lightweight (~40g class) glasses with a monocular 640×400 color micro-OLED (0.23", 20° FOV), an OV09734-based 720p color camera cropped to 720×720, a single TDK ICS-41351 MEMS mic, a 6-axis MC6470 accel/e-compass, an nRF52840 Cortex-M4F MCU + FPGA for display acceleration, a 210mAh battery, and Bluetooth 5.3 — no speaker. Halo (ships the week of July 20, 2026) is a redesign: a 640×480 full-RGB VGA020 OLEDoS micro-display (0.2" panel, up to 5000 nit, 10000:1), a PixArt PAG7982J1 global-shutter VGA camera (81.2° H-FOV), dual T5838 MEMS mics with audio-activity detection, stereo bone-conduction speakers, a Bosch BMA580 accelerometer + QST QMC6308 magnetometer with tap detection, and notably an Alif Balletto B1 (Cortex-M55 + Ethos-U55 NPU) for on-device AI, a 300mAh battery, BLE 5.3, just over 40g. Halo is $349 introductory ($399 later), sold direct via brilliant.xyz. Both are fully open source — hardware design files, firmware (ZephyrOS on Halo), and SDKs on GitHub. Neither is standalone: both are phone/host peripherals over BLE. (n/a: neither is a tethered viewer, controller-driven AR, or MR headset.)
Access
The Brilliant SDK is a single open-source monorepo covering both Halo and Frame (device type auto-detected on connect), exposing three host bindings — Python (brilliant-ble low-level BLE via Bleak + brilliant-msg for rich objects), Flutter/Dart for iOS+Android, and Web Bluetooth/TypeScript — plus an on-device Lua 5.3 VM with a full Lua hardware API reachable directly on the glasses. Licensing is genuinely permissive: the unified brilliant_sdk is BSD-3-Clause, the older frame-sdk-python is MIT, and the Noa assistant backend is ISC. Beyond the language bindings there are two more first-party on-ramps the raw-SDK framing understates. First, AR Studio, Brilliant's VSCode extension, is a full IDE-integrated on-device workflow — device-file explorer, an interactive on-glasses REPL, auto-run/build that transfers files and soft-resets over BLE, FPGA-binary/firmware updates, and community-project browse/publish; the Frame SDK docs present it as the officially-documented way to "directly write and execute Lua code on Frame" (its lineage is the Monocle MicroPython tool, now extended to the glasses). Second, the complete Noa companion app is open-source Flutter and is promoted as the canonical reference — "a great example of how to build your own Frame apps" — so you can start from a shipping production host app rather than raw snippets. Maturity is actively-developed pre-1.0 (the docs note each platform SDK is under active development); Frame's SDK is battle-tested, Halo's ships alongside the July hardware. Who can build: anyone — open signup, no dev-mode toggle, invite, partner tier, enterprise contract, or fee. Docs at docs.brilliant.xyz; source at github.com/brilliantlabsAR.
App model
Explicitly phone/host-companion. Per the Frame SDK docs: "Rather than installing apps directly on Frame, it typically functions as a peripheral accessory for 'host' apps running on computers or mobile devices," with the glasses running a simple event-handler loop while the host drives logic. Transport is Bluetooth LE in every binding; brilliant-msg streams rich objects (images, audio, IMU data, rasterized text) between host and glasses. There is a second dev path: developers can also write Lua scripts that execute on Frame/Halo directly on the on-device Lua 5.3 VM (authored/pushed via AR Studio), supplementing — not replacing — the host app, so you can move logic on-glasses when latency or offline operation matters, and Halo's Ethos-U55 NPU makes some on-device inference viable. This is a near-exact match for Extentos's phone-companion model: a mobile app owning the primitives over BLE. The divergence is that Brilliant's transport/messaging is its own BLE protocol (not Meta's DAT), and Brilliant additionally exposes the on-device Lua path that Extentos's Meta-oriented model does not.
Distribution
There is no gatekeeper and no first-party developer app store for compiled SDK apps. An SDK app is just your own host program — a Python/desktop app, or an iOS/Android app built on the Flutter SDK — that you distribute through ordinary channels (the OS app stores for a mobile companion, or run it yourself); Brilliant reviews nothing and gates nothing, and because the SDK, hardware, and firmware are open source you can fork firmware or flash custom Lua freely. Two first-party sharing surfaces do exist, neither a curated native store: AR Studio carries a lightweight community browse-and-publish channel ("Access and publish user projects") for on-device scripts/projects — Monocle-rooted, but a real first-party discovery path — and the Noa companion app ships a consumer "Miniapps" system branded Vibe Mode, where an end user speaks a natural-language command ("build me a maps app that shows my next three turns") and Noa generates a running app in seconds that can then be shared and remixed by the community (see the Halo product page). Both are authoring/sharing surfaces, not compiled-SDK third-party publishing channels comparable to a reviewed native store. No preview→GA gating, no developer invite waitlist, no enterprise-MDM requirement. Publishing status: effectively open/unrestricted for SDK apps, with the caveat that "publishing" means shipping your own host app rather than submitting to a Brilliant-run store.
Capabilities, limits & AI
Camera: Frame captures 720×720 color stills to the host via brilliant-msg. Halo's PAG7982J1 is a global-shutter VGA color module (81.2° H-FOV); brilliant-msg lists image transfer, but Brilliant markets Halo's camera primarily as "AI vision input" and the product page frames it as a low-power optical sensor for AI inference — whether arbitrary photo/video capture-to-host is a supported first-class primitive on Halo is not spelled out in the official hardware docs (see open questions). No documented capture-gating/permission-broker layer — access is direct over BLE. Microphone/audio capture: yes — Frame single MEMS mic; Halo dual T5838 mics with audio-activity detection, streamable to host. Audio output/TTS: Frame has no speaker (host-side audio only); Halo has stereo bone-conduction speakers you can drive. On-lens display/UI: yes, a real first-class surface — you render directly to the color OLED via Lua graphics APIs or host-pushed rasterized text/images (Frame 640×400, 20° FOV; Halo 640×480 RGB OLEDoS). Sensors: IMU/accelerometer + magnetometer with tap detection on both; no GPS on-glasses (location comes from the phone host). Input: capacitive tap/tap-detection on the frame; Halo adds an optical sensor and a physical button + status LED. No gesture-camera, controller, or neural-band input. Reserved surfaces: essentially none — because the assistant, wake handling, gestures, and IMU are all exposed to developer code, there is no locked first-party layer the way Meta reserves "Hey Meta." AI & the assistant: Noa is the bundled multimodal assistant, and it is fully open: noa-assistant is open-source (ISC), self-hostable, and bring-your-own-key — you supply your own provider credentials in a .env and point the glasses at a model you host. The documented runtime flags are OpenAI-centric (--assistant gpt, vision via gpt-4-vision, web search via --search-api serpapi): OpenAI and SerpAPI are the clearly-enumerated providers, and while other models (e.g. a Claude id) appear in code examples they aren't spelled out as first-class selectable provider flags (see open questions). Voice invocation and vision queries are developer-controllable; Halo's Ethos-U55 NPU enables some on-device inference, though the shipped Noa experience is cloud-backed.
Roadmap
Frame has been shipping and its Python/Flutter SDKs are mature. Halo was announced in 2026 as the successor, priced $349 (rising to $399), with shipping stated to "start the week of July 20" 2026 — the unified brilliant_sdk monorepo (Python/Flutter/Web Bluetooth, Lua 5.3, auto device detection) lands with it. Momentum signals: consolidation of Frame+Halo into one open SDK, a move to a modern NPU-class SoC (Alif Balletto B1) for on-device AI, and continued full open-sourcing of hardware/firmware/design files. Announced-but-still-settling at time of writing: Noa's paid "Plus" tier pricing and the exact scope of Halo's on-device (vs cloud) AI. No developer-publishing gate is announced or planned — the platform's trajectory is more-open, not gated. The predecessor Monocle (MicroPython clip-on) is legacy and out of scope.
In the landscape
Brilliant Labs is one platform in the third-party smart-glasses landscape. See how open it is relative to other platforms, how AI works across them, and the full platform comparison.
Related
The third-party smart-glasses landscape
Can you build third-party apps for smart glasses today? A platform-by-platform comparison — Meta, Snap Spectacles, Brilliant Labs, Rokid, RayNeo, Even Realities, Vuzix, Android XR, Apple and more: which have an official SDK, how apps are built and distributed, and whether you can publish publicly.
How open is smart-glasses development?
A mental model for the openness spectrum in smart-glasses development — SDK availability, license, build-time gating, and publishing gating — with today's platforms placed on it.
AI on smart glasses
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.
How third-party smart-glasses apps are distributed
Smart glasses don't have one app store. The app-model taxonomy — companion mobile app vs. an app that runs on the glasses (native or web) — and why a single platform (Meta) offers two entirely separate developer systems: DAT and Ray-Ban Display Web Apps.
Meta smart glasses (Meta DAT)
Meta smart glasses developer guide: DAT 0.8.0 capabilities, supported models (Ray-Ban Meta, Oakley Meta, Ray-Ban Display), 2026 distribution state, and how Extentos abstracts the toolkit.
Capabilities
The Extentos capability vocabulary — the vendor-agnostic SDK primitives (audio, camera, voice, assistant, display, hardware events) your handler subscribes to.
Android XR
Android XR for third-party developers — SDK access, app model, distribution, capabilities & AI, and where it sits in the 2026 smart-glasses landscape.
Rokid
Rokid for third-party developers — SDK access, app model, distribution, capabilities & AI, and where it sits in the 2026 smart-glasses landscape.