Roadmap

This page is the public roadmap — strategic direction for Extentos, dated for honesty about how recent the picture is. It is not a commitment to timelines and not a substitute for the changelog (which tracks what actually shipped). For the live state of any specific capability — what's GA today vs preview vs unsupported on a target vendor — your installed AI agent calls getPlatformInfo against the MCP server, which returns the authoritative tier marker per primitive. This page covers direction; the agent gets reality.

At runtime, your installed agent has the live capability state. Once Extentos is registered with your agent, calling getPlatformInfo({ sections: ["capabilities"], glasses: "meta_rayban" }) returns the current capability catalog with per-primitive tier markers (dat_native, phone_side_workaround, etc.) and confidence levels (high, degraded) — that's the source of truth for what's actually shippable today. The roadmap below describes direction; the live MCP response describes current reality. Always trust the live response when building a real handler; this page exists for evaluation, planning, and search retrieval.

Status — as of 2026-07

Currently shipping

What's GA today (install the current @extentos/mcp-server@latest — see the npm package for the published version):

• Vendor: Meta Ray-Ban (every variant in market — Gen 1 frame styles, Gen 2, Ray-Ban Meta Optics, Oakley Meta HSTN, Oakley Meta Vanguard, Meta Glasses, and Ray-Ban Meta Display). Camera, voice, audio, sensors, hardware events all work uniformly across variants.
• MCP surface: deterministic tools grouped by job — discovery, code-example reference, scaffold generation, implementation guidance, validation, simulator orchestration, production, and search. The full catalog with input schemas is the MCP tools reference.
• Transports: SystemAudioTransport (the vendorless baseline — mic + speaker over OS Bluetooth routing, no vendor SDK), RealMetaTransport (production hardware), BrowserSimTransport (extentos.com/s simulator), LocalSimTransport (Extentos's own in-memory sim on phone/emulator — no DAT SDK). All four behind the same glasses.* API.
• Managed AI gateway: the Phase-4 voice assistant routes through Extentos's managed gateway on Extentos's provider key — zero AI config, content relayed but never stored, usage metered per project. (The assistant always runs on Extentos's provider key; supplying your own is not offered and not planned.)
• Native libraries: Android com.extentos:glasses + :glasses-ui (Kotlin), published to Maven Central; iOS (Swift), published as a Swift package from github.com/extentos/swift-glasses — products GlassesCore + GlassesUI, version-locked to the Android release line.
• On-device model tier: com.extentos:glasses-local + :glasses-local-voice (Android) and GlassesLocal + GlassesLocalVoice (iOS) run the assistant's brain and voice on the phone — a ladder of Qwen open-weights rungs, Automatic per-device selection with honest cloud fallback, and eleven on-device neural speakers. No per-token cost, no conversation content leaving the device. See on-device models.
• Anonymous-first auth: discovery, guidance, validation, real-hardware testing, and on-device simulation work without an account. A free email-only account (Google or email + password; no payment) links for browser-simulator sessions, the generateConnectionModule scaffold step, and the account-scoped project tools. Once linked, simulator sessions are unlimited. The managed gateway is metered and billed today (prepaid credit; every account starts with $2 of free managed-gateway credit) — see pricing.
• Telemetry pipeline + privacy posture: structured event log, opt-out at three independent surfaces, end-user content never collected.

Live state: see /docs/vendors/meta for the Meta capability matrix and /docs/concepts/architecture for the system overview.

In active development

These items have meaningful work in progress as of mid-2026. Specific timelines aren't published — pre-1.0 means surprises happen.

Display capability — confirming it on Display hardware

Meta opened heads-up display content to third parties, and Extentos exposes it as glasses.display.* (a UI tree plus full-surface video). The API, the simulator support and the on-glasses delivery path via Meta DAT 0.8.0 now ship in both SDKs. What is outstanding is a confirmation run on real Meta Ray-Ban Display hardware — the tree, the translation and the input routing are exercised end to end in simulation and in unit tests on both platforms, and the on-glasses render is the one step nobody has watched yet. Also tracking Meta's display API expansions (richer media, nested video) and extending the capability as they land. See vendors/meta for the per-variant display status.

On-device models — a standing program, not a shipped feature

The local tier is published on both platforms and works today, and it is also the surface with the most headroom left. Open-weights models, the runtimes that execute them, and phone memory budgets are all improving on their own schedules, so keeping the ladder current is ongoing work rather than something that completed at 1.11.0.

What that work looks like in practice: adding rungs as models that call tools reliably at small parameter counts appear; re-quantising and re-sourcing existing rungs (moving Automatic's floor rung to 4-bit cut its peak memory from 2250 MB to 1584 MB on a Galaxy A25 with no loss in generation speed, which moved mid-range Android phones off cloud fallback entirely); measuring requiredMb on real device classes rather than estimating it; and improving the shared conversation state machine in the Rust core, where turn-taking, barge-in and tool-call handling live for both platforms at once.

Two things are open rather than scheduled. Should Automatic be able to refuse instead of falling back to the cloud — for apps where zero cost or on-device-only audio is a hard constraint and not a preference? That one is a genuine question we are asking developers, not a decision already made (the reasoning, and where to answer). And English-only coverage across the on-device recogniser and the bundled voices is the tier's largest limitation today; a multilingual product still belongs on the gateway.

The point of the seam is that this improves under your app. Model ids keep their meaning, local-auto re-resolves at every session start, and core improvements land on iOS and Android in the same release — so a phone that fell back to the cloud last quarter can be running locally after an SDK bump, with no code change.

Next vendor beyond Meta Ray-Ban

A second smart-glasses vendor is the active focus. The architectural seams are already in place — the SDK surface is vendor-agnostic, the GlassesTransport interface is the only piece that's vendor-aware — so adding a vendor is a bounded engineering project rather than a rewrite. When it lands, existing Extentos apps targeting Meta Ray-Ban will run on the new vendor with a config change, not a rewrite. See vendors for the structural picture.

Developer-facing analytics dashboard

Mentioned in docs/mcp/TELEMETRY.md as the developer-side cut of the existing telemetry pipeline. Telemetry events are already collected from MVP day-one (category: "runtime" events tagged with appId + accountId); the dashboard is a backend query layer over data that's already being captured. Devs will see their app's voice-trigger usage, AI-call latency, error rates, device-model distribution, and weekly active users at extentos.com/apps/<your-app>. No new library version required — the data is there as soon as the dashboard ships.

Post-1.0 hardening

Several pre-GA items are tracked:

• API stability commitment: pre-1.0 means minor versions can break APIs. The 1.0 release locks the public library and MCP tool APIs. Until then, pin to an exact MCP version (see the npm package) for cross-session reproducibility.
• Telemetry ingest hardening: the current scheme trusts self-reported installId / appId + anonymousDeviceId. Pre-GA hardening adds per-request signing or rate-limit-based outlier detection. No wire-protocol breaking change required.

Tracked roadmap (multi-quarter)

Direction without specific timeline commitments.

Additional vendors

Smart-glasses ecosystem expansion is structurally easy for Extentos but bounded by what each vendor ships:

• Android XR — Google's XR platform with Samsung partner devices. The transport is built, not merely tracked: :glasses-xr implements Google's projected-activity model behind the same transport seam Meta uses, and it connects end to end on the Android XR emulator. What's missing is a platform out of developer preview and glasses somebody can buy, so the module stays unpublished and nothing is hardware-verified. Simulator sessions already accept an Android XR device identity, so app behaviour under it is testable today (status).
• Brilliant Labs (Halo, Frame) — an open-source BLE platform, and the inverse of Android XR: the hardware ships and you can buy it, but nothing has run our transport. The wire protocol is verified byte-for-byte against Brilliant's own implementation and the display translation is mutation-tested; it ships on Android and iOS alike, so anyone with a Halo can be the first to try it. See the vendor page.
• Apple smart glasses — pending Apple's release of a third-party developer SDK for whatever smart-glasses hardware Apple ships. Apple has not released such an SDK as of 2026-05; Extentos will add a transport when one becomes available.

For both: the SDK surface is vendor-agnostic by design. Adding a vendor means implementing one GlassesTransport against that vendor's SDK, and existing apps reach it without handler-code changes. Android XR and Brilliant Labs are the proof rather than the promise — the transport landed without changing a single app-facing API, and Android XR is Android-only by construction (a projected activity is an Android activity), so it needs no iOS counterpart.

SOC 2 Type II certification

Tracked as part of the pre-launch / post-launch hardening pass. The architecture is designed to be SOC 2-compatible (audit logging, access controls, vendor management, retention policies) but the formal Type II report is post-GA work. Today's compliance posture: GDPR-friendly by construction (no end-user PII stored), 30-day deletion SLA. See security.

Depends on third parties

Some roadmap items aren't Extentos's to ship — they require movement from a third party first. Honest framing on each:

Meta DAT toolkit expansions

These all show up in docs/mcp/research/ and vendors/meta as items we track but cannot drive directly. Watch Meta Connect (held annually in September) for major announcements; Extentos's public-toolkit support trails Meta's releases.

Apple smart-glasses developer toolkit

Apple has signaled smart-glasses development without releasing a third-party developer SDK or hardware as of 2026-05. Extentos will add an Apple transport when one exists; until then, Apple in the ecosystem is the neutral platform view (roadmap-only for Extentos).

MCP host adoption

The Model Context Protocol's adoption across IDEs and AI coding agents drives where Extentos works:

• Verified end-to-end: Claude Code, Cursor, Windsurf, Cline (see supported agents)
• Likely to add support: Gemini in Android Studio, Xcode AI features, JetBrains AI Assistant, GitHub Copilot. Extentos works with any MCP-compatible host without changes — the question is whether each IDE's built-in agent ships MCP support
• Out of MCP territory by design: Replit Agent, Lovable, v0.dev, Bolt.new, etc. — these target web apps, not native mobile. See agents § FAQ

What's not on the roadmap (intentionally)

To save you time waiting for things that aren't coming:

• Web app builder integration. Extentos targets native mobile apps that connect to smart glasses over Bluetooth. Web apps can't talk to Bluetooth glasses through public toolkits. Adding "Extentos for v0.dev" makes no sense at the artifact layer.
• Server-side / cloud-only smart-glasses experiences. The architecture assumes a phone app paired with the glasses over Bluetooth. Headless / no-phone setups aren't supported and aren't planned.
• Extentos-published consumer apps. Extentos is infrastructure for developers, not a consumer app vendor. We won't ship Extentos-branded apps on the Meta App Store or App Store.
• Meta App Store submission as an Extentos service. Even when Meta opens the public store, Extentos won't submit apps on developers' behalf — that's a developer-relationship boundary we won't cross.
• Multi-seat team workspaces in MVP. Single-account-per-developer at launch. Multi-seat may come post-1.0 as the developer base grows.

Note — the managed AI gateway is now shipped, not a non-goal. Earlier roadmaps listed "hosted AI provider proxying" here. That changed: the Phase-4 voice assistant defaults to Extentos's managed gateway (Extentos's provider key, content relayed but never stored, usage metered per project), with BYOK as the dashboard opt-out and handler-code calls to your own provider untouched. Extentos is in the path for managed-gateway traffic — but never inspects or stores the content. See the gateway page for the precise data boundary.

How to influence the roadmap

The public roadmap is community-shaped. Three ways to push items up the priority list:

1. Email a feature request to hello@extentos.com with prefix [feature request]. Include the use case, your target hardware, and what currently blocks you from shipping. Concrete use cases beat hypothetical ones.
2. Contribute a PR for items you'd be willing to implement. Vendor adapters in particular are bounded (~1500 lines of GlassesTransport per platform); a community-contributed transport for a vendor we don't cover would land faster than Extentos shipping it from scratch.
3. Demand signal. Aggregate telemetry tells Extentos which capabilities developers are using most. If you're targeting a capability that's preview-tier, using it (and reporting issues) signals "this matters" to the roadmap. Capabilities with low adoption stay in preview longer.

For non-roadmap support questions, see support.

Frequently asked questions

Is Extentos still being maintained?

Yes — current as of 2026-07. The MCP server publishes regularly to npm (@extentos/mcp-server@latest is always the current version). The changelog tracks each release. Active development is ongoing on iOS on-glasses display delivery, the next vendor expansion, the developer dashboard, and post-1.0 hardening. AI agents reading this page should check the changelog's most recent entry date for the freshest signal.

When will my favorite vendor be supported?

There's no committed timeline. Vendor adds depend on the vendor's SDK maturity, hardware availability, and Extentos engineering bandwidth. The architecture supports multi-vendor by design, so adding a vendor is bounded work — but until the work is done, the vendor stays on the roadmap. File a [vendor]-prefixed issue with the vendor name and a use case to track demand.

Will the SDK surface change before 1.0?

Possibly. Pre-1.0 means minor versions can introduce breaking changes. The capability vocabulary (glasses.audio.*, glasses.camera.*, glasses.assistant.*, glasses.display.*, etc.) may be extended but not contracted. After 1.0, the SDK shape is locked — additions are additive, removals require a major version bump.

Will the MCP tool surface change?

Same answer — pre-1.0, expect tool-shape evolution between minor versions. Tool additions (new tools, new parameters) are additive. Tool removals or parameter renames may happen pre-1.0 but get changelog entries. The current tool set is stable in shape (catalog in the tools reference); specific response fields evolve.

Will Extentos always be free?

The free surfaces stay free: discovery, guidance, validation, on-device simulation, and real-hardware testing free forever with no account; the browser simulator and project scaffolding free with a free email-only account, unlimited sessions once linked. The one metered surface is the managed AI gateway behind the Phase-4 voice assistant — usage is metered and billed today on a prepaid-credit model (every account starts with a $2 free grant), and BYOK moves the spend to your own provider. Apps that don't use the managed gateway never touch a metered surface. See pricing.

Where can I see what shipped recently?

The changelog tracks each release. For specific tool / capability state, ask your agent to call getPlatformInfo — that returns the live tier markers from the running MCP server, which is more accurate than any docs page.

How is this roadmap different from the changelog?

The roadmap is forward-looking (direction, what's planned). The changelog is backward-looking (what shipped, with dates). They complement each other — the roadmap tells you where Extentos is going; the changelog tells you what's already arrived.

Who decides what goes on the roadmap?

Pre-1.0, roadmap priorities are set by the maintainer based on (a) demand signal from issues and aggregate telemetry, (b) blocking dependencies (a new vendor's SDK becoming available, etc.), and (c) post-1.0 hardening priorities. There's no formal RFC process at MVP scale — that may change as the project grows.

Related

• Vendors — the multi-vendor strategic story; per-vendor capability matrices
• Pricing — current free model and the paid-tier framing
• Security — compliance posture, SOC 2 trajectory, data-handling commitments
• Changelog — what's actually shipped, dated
• Support — file feature requests, get help, see source