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 tier: "stable" | "preview" | ... markers per block, trigger, and stream — 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 composing a real spec; this page exists for evaluation, planning, and search retrieval.

Status — as of 2026-05

Currently shipping

What's GA in @extentos/mcp-server@0.0.16 (the published version on npm as of this writing):

• Vendor: Meta Ray-Ban (every variant in market — Gen 1 frame styles, Gen 2, Display, Oakley Meta HSTN). Camera, voice triggers, audio, sensors, hardware events all work uniformly across variants.
• MCP surface: 18 deterministic tools across 7 categories (discovery, generation, guidance, validation, simulation, production, search). The full catalog is at /docs/mcp-server.
• Transports: RealMetaTransport (production hardware), BrowserSimTransport (extentos.com/s simulator), LocalSimTransport (Mock Device Kit on phone/emulator). All three behind the same glasses.* API.
• Native libraries: Android (com.extentos.glasses.core, Kotlin) and iOS (Extentos, Swift via SPM). Source-available, MIT-licensed for the MCP server.
• Anonymous-first auth: 1000-event browser-simulator meter without an account; free email-only account after exhaustion. No paid tier exists.
• Telemetry pipeline + privacy posture: structured 7-layer 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.

Next vendor beyond Meta Ray-Ban

A second smart-glasses vendor is the active focus. The architectural seams are already in place — the AppSpec 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 spec format and the public library API. Until then, pin to an exact version (@0.0.16) 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.
• iOS auto-bind: Android's auto-bind dev loop (the localhost:31337 bridge) is fully shipped; iOS auto-bind is in progress. Until it lands, iOS uses the URL-bake path via extentos.session.plist.

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:

• Mentra G1 — open-ecosystem developer glasses. Tracked since the AppSpec abstraction was designed with multi-vendor portability in mind. Implementation contingent on Mentra's SDK maturity and developer-program access.
• Android XR — Google's XR platform with Samsung partner devices. Tracked since the Android XR developer preview availability. Implementation contingent on Google's GA timeline.
• Apple smart glasses — pending Apple's release of a third-party developer SDK for whatever AR/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 all three: the AppSpec is already vendor-agnostic by design. Adding the vendor means implementing one GlassesTransport per platform (Android Kotlin + iOS Swift) against the vendor's SDK. Existing Extentos apps targeting Meta Ray-Ban will run on these vendors with no spec or code changes.

Possible future paid tier

The current pricing model is free everything with a 1000-event browser-simulator meter that gates onto a free email-only account. No paid tier exists at launch. Whether a paid tier is introduced post-launch depends on cost trajectories (browser-simulator infrastructure, voice inference, event-log retention) and developer-population growth. If introduced:

• Existing free accounts will not be retroactively gated
• The free-forever-no-account tier (all MCP tools + on-device simulation + real-hardware testing) stays free
• Material changes get a release-note entry and a privacy-policy bumped flag in the MCP response

See pricing for the current state.

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, vendors/apple is roadmap-only.

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.
• Hosted AI provider proxying. Developers bring their own AI provider keys (BYOK). Extentos won't proxy AI calls, monitor AI cost, or sit in the inference path.
• Multi-seat team workspaces in MVP. Single-account-per-developer at launch. Multi-seat may come post-1.0 as the developer base grows.

How to influence the roadmap

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

1. File a feature request at github.com/Asgermolgaard/vibe-hardware/issues 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 Mentra or Vuzix transport 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-05. The MCP server publishes regularly to npm (@extentos/mcp-server@0.0.16 is the current version). The changelog tracks each release. Active development is ongoing on 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 AppSpec format change before 1.0?

Possibly. Pre-1.0 means minor versions can introduce breaking changes. The compiler-derived metadata fields (derived.capabilitiesUsed, derived.requiresNetwork) are stable; the block kind / trigger type / action type vocabulary may be extended but not contracted. After 1.0, the spec format 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 categories, new tools) are additive. Tool removals or parameter renames may happen pre-1.0 but get changelog entries. The 18 tools in 0.0.16 are stable in shape; specific response fields evolve.

Will Extentos always be free?

The current free model (all MCP tools + on-device simulation + real-hardware testing free forever, no account; browser simulator free up to 1000 events / unlimited with free account) is not changing. If a paid tier is introduced post-launch, the current free model stays. The decision on whether to introduce paid tiers depends on browser-simulator infrastructure costs and the developer base size — 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