---
title: Extentos vs Meta DAT directly
description: Extentos sits on top of Meta's Device Access Toolkit — it wraps DAT, it doesn't replace it. What you write yourself against raw DAT vs what Extentos gives you, and when going direct is the right call.
type: concept
platform: all
vendor: meta
related:
  - /docs/concepts/transport-vs-app
  - /docs/concepts/capabilities
  - /docs/concepts/architecture
  - /docs/vendors/meta
  - /docs/getting-started/with-agent
---

**Extentos isn't an alternative to Meta's Device Access Toolkit — it's a layer on top of it.** Extentos's production transport (`RealMetaTransport`) calls Meta DAT under the hood; the question isn't "Extentos *or* DAT," it's "compose against Extentos's typed primitives and tooling, or wire the raw DAT API yourself." This page is the honest comparison, including when going direct to DAT is the better choice.

## What Meta DAT gives you, and what you still have to build

Meta's [Device Access Toolkit](/docs/vendors/meta) is the official SDK for connecting a mobile app to Ray-Ban Meta — it handles Bluetooth pairing, the session/stream lifecycle, camera frames, photo capture, and the audio path. It's solid plumbing. But it stops at the SDK surface. Building a real voice-glasses app on raw DAT means you also write, yourself:

- **The wake-phrase path** — DAT doesn't recognize phrases. You stream the glasses mic to the phone's `SpeechRecognizer` / `SFSpeechRecognizer` over Bluetooth HFP, normalize transcripts, and match strings.
- **A capability abstraction** — DAT exposes raw publishers (`videoFramePublisher`, `photoDataPublisher`, …). You build the typed surface your handlers call.
- **A test harness** — DAT ships a Mock Device Kit for the *transport*, but you write the speech-recognition simulation, TTS playback, hardware-alert injection, and an event correlator to actually exercise your app's behavior. (See [transport vs app simulation](/docs/concepts/transport-vs-app).)
- **Permission derivation** — you map each capability to the right Android manifest entries and iOS Info.plist keys (including the Meta DAT-specific ones) by hand.
- **The audio-coexistence decisions** — A2DP playback racing an HFP capture is fragile; you write the routing policy.
- **Multi-vendor portability** — DAT is Meta-only. Supporting another vendor later is a fresh integration.

## What Extentos adds

Extentos builds that layer once, shared across every Meta Ray-Ban app:

- **Typed capability primitives** — your handler subscribes to `glasses.audio.transcriptions()`, `glasses.camera.capturePhoto()`, `glasses.audio.speak()`, `glasses.assistant.start()`, `glasses.display.show()` — the same API across the [browser simulator](/docs/concepts/transport-vs-app), the on-device Mock simulator, and real hardware.
- **A real app-level simulator + agent-driven testing** — drive voice, camera, and display from a browser (or from MCP tools, no human), and read a structured [7-chip event log](/docs/concepts/sessions). The bulk of the dev loop happens without pairing glasses.
- **MCP scaffolding for AI agents** — `generateConnectionModule` writes the wiring, `getPermissions` derives the entitlements, `validateIntegration` gates correctness. See the [MCP tools reference](/docs/reference/mcp-tools).
- **A typed error model** — lifecycle ops return [`ExtentosResult<T, E>`](/docs/reference/errors) with concrete failure variants instead of raw exceptions.
- **A managed AI gateway** (optional) — the [assistant runtime](/docs/concepts/assistant) routes voice AI on Extentos's keys by default; no key in your app. See [the gateway](/docs/concepts/ai-gateway).
- **A multi-vendor seam** — handler code is vendor-agnostic; adding a vendor is a new transport, not a rewrite.

## Side by side

| | Raw Meta DAT | Extentos (on top of DAT) |
|---|---|---|
| Bluetooth pairing, session/stream lifecycle | ✅ DAT | ✅ (wraps DAT) |
| Camera / photo / audio primitives | ✅ raw publishers | ✅ typed `glasses.*` |
| Wake-phrase recognition | ❌ you build it | ✅ `glasses.voice.onPhrase` / `transcriptions()` |
| App-level simulator (voice, TTS, alerts) | ❌ you build it | ✅ browser simulator |
| Agent-driven E2E testing | ❌ | ✅ inject + assert + event log |
| Permission derivation | ❌ by hand | ✅ `getPermissions` |
| Typed error model | ❌ raw exceptions | ✅ `ExtentosResult` |
| Voice AI / assistant runtime | ❌ you wire a provider | ✅ managed gateway + `glasses.assistant` |
| Ray-Ban Display rendering | DAT 0.7.0 primitive | ✅ `glasses.display.*` DSL |
| Multi-vendor portability | ❌ Meta-only | ✅ vendor-agnostic handlers |
| Dependencies | DAT only | DAT + Extentos SDK |

## When to use Meta DAT directly

Extentos is the faster path for almost any voice/camera/display glasses app — but going direct to DAT is the right call when:

- **You need a DAT capability Extentos doesn't surface yet.** Extentos exposes a curated primitive set; if you need a raw DAT API that isn't wrapped, use DAT directly (and consider [filing an issue](https://github.com/Asgermolgaard/vibe-hardware/issues) so it gets surfaced).
- **You want zero added dependencies.** A minimal app that only does, say, one photo capture may not need the abstraction.
- **You're doing something very low-level** with the transport that the capability model would get in the way of.

Because the Extentos libraries are **source-available** ([repo](https://github.com/Asgermolgaard/vibe-hardware)) and `RealMetaTransport` is just a thin bridge over DAT, you can read exactly how Extentos calls DAT and drop down to the raw API for the parts you need while keeping the typed surface for the rest. It isn't all-or-nothing.

## The bottom line

Extentos doesn't hide Meta DAT — it does the repetitive, fragile, per-app work (wake-phrase plumbing, the app-level simulator, permission derivation, the test harness, the error model) once, so you write your app's logic instead of its infrastructure. If you'd end up rebuilding that layer anyway, Extentos is the layer. If you genuinely only need raw transport, DAT alone is fine.

## Related

- **[Transport vs app simulation](/docs/concepts/transport-vs-app)** — Mock Device Kit (transport) vs the Extentos app-level simulator
- **[Capabilities](/docs/concepts/capabilities)** — the vendor-agnostic primitive surface
- **[Vendors: Meta Ray-Ban](/docs/vendors/meta)** — the DAT capability matrix and setup
- **[Quickstart with an agent](/docs/getting-started/with-agent)** — install and build the first flow