Work Anywhere: Platform Support
Telemus AI offers a spatial 3D app and connected Web and terminal controls. Capabilities depend on the installed package, host, permissions and device. A supported target does not mean every integration is certified on every device.
Supported platforms
| Platform | Immersive XR | Flat experience |
|---|---|---|
| Meta Quest | Supported target | Available flat path |
| Windows | OpenXR PCVR where the active runtime/session validates | Desktop target |
| macOS | Unavailable | Desktop target |
| Linux | Unavailable | Development desktop target |
| WSL2 | Unavailable | Headless, server and terminal workflows only |
| Web browser | Unavailable | Experimental 3D browser target |
| iOS/iPadOS | Unavailable | Experimental flat target |
The hosted Web Command Center controls its connected app host. It is different from the standalone Web 3D app. Terminal TUI similarly reflects the connected host's capabilities rather than adding unsupported device features.
Browser builds
Supported Web builds provide mouse/touch controls, document/file entry points, and browser-permitted voice input. Hold Talk or Space to speak where available. Drop a supported file or use + to open it. Browser recognition, recording, microphone permissions and provider setup determine voice availability.
Browser files and persistent workspace storage require compatible browser features. Only one same-origin page can own the local workspace storage at a time. Close another active page if storage is unavailable. A storage error can require closing and reopening the affected page. Keep independent backups of important work; browser storage is not a cross-device backup.
Standalone Web cannot launch arbitrary local programs, provide a local shell, use native network-file protocols, or discover LAN servers by broadcast. Use a configured server URL where supported. Browser automation is limited to supported app-owned content unless an authenticated companion is configured.
Media remains subject to browser codec, origin, autoplay and gesture rules. A link card, accepted request or cached view does not prove that content loaded.
Web pages and documents
show_web distinguishes a displayed preview, a pending request, an external
browser handoff, a link fallback and a failure. Default desktop configurations
can open links externally; supported embedded-view builds can display previews.
Standalone Web uses a link card where embedded display is unavailable.
Undo closes the room card; it does not necessarily close an external browser. Restoring a card does not prove the page loaded. Native PDF support depends on the package; a fallback link or download offer is not an in-room viewer.
Live camera and visual answers
Where available, open Navigation drawer → AR View, grant local permission, and wait for a fresh preview. Web also needs a secure browser context and its Enable camera control. A restored room or ordinary text request does not turn the camera on.
To request a visual answer, type a question and choose Send Camera to AI. This sends one image and the question to the selected image-capable provider, including any configured fallback. It can be a remote service. Empty question text requests a description. Preview alone does not upload images.
The app does not record camera video or save raw frames through this workflow. The receiving provider's retention terms still apply. Text questions and answers can remain in conversation history. Stopping capture cannot recall a sent image. After stopping, pausing or losing capture, a new local action is required.
Camera availability varies by release and device. The direct send action is
unavailable in Quest builds, which have their separate camera flow, and in
Hermes/ACP sessions. Device permission alone does not establish release support.
Web Telemus Operations and terminal /camera status report status only;
they cannot start the local camera, retrieve its images or send questions remotely.
Headsets and Windows PCVR
Windows can attempt OpenXR sessions through a configured runtime such as
Quest Link/Air Link or SteamVR. Start with an appropriate supported option:
--vr, --pcvr, --quest-link, --air-link, --steamvr, --valve-index,
or --steam-frame. These are launch hints, not proof of headset support.
Check for a ready session before treating a run as validated. --flat or
VRAI_DISABLE_OPENXR=1 keeps the desktop app flat.
Standalone Quest uses its own app package. A Windows PCVR option does not add standalone support for another headset. Linux, macOS, iOS and Web remain flat.
Supported XR controllers can drive arm/hand appearance with trigger and grip input. Tracking loss can hide the arms. Hand closure and model deformation vary by assets and runtime; exact finger contact is not guaranteed.
Desktop services, terminals and extensions
Desktop apps can keep supported local services running in background mode. Use the tray/menu item to Show Telemus AI, open Settings, Open Web TUI, or Quit Telemus AI. Where a tray is unavailable, closing the window exits. A lost PCVR runtime can also end the app rather than leave it in background mode.
Local in-room shells are available only on supported Linux/macOS hosts. Windows, Android/Quest, iOS and standalone Web do not provide local PTY sessions. A remote terminal feed is not a local shell. The terminal TUI is a separate control client.
Windows packages can provide vrai_headless.exe --mcp-stdio for MCP and
TelemusAIACP.exe for ACP. The normal GUI console is not an MCP input pipe.
Supported macOS desktop builds provide F12 and Open Web TUI for the local
dashboard. Service availability remains subject to package and configuration.
Reviewed external Node/Python plugin code runs with the host account's access. It is not an operating-system sandbox. Dynamic native plugin loading is a separate guarded capability and is unavailable on Windows, mobile and Web.
Mobile channels
Mobile channel integration depends on a configured companion and OS lifecycle permissions. Android continuous operation requires an available foreground service. iOS does not provide continuous background channel sockets. A compiled integration or listed connector is not proof that it is currently receiving messages. Use status and recovery guidance before relying on delivery.
For continuous channel service, use a compatible configured host. This does not grant channels access to private assistant conversations or personal worlds.
Speech, media and remote desktop
Speech and audio capabilities differ by provider and platform. System voices can play without positional audio or avatar mouth animation. Local speech recognition requires its packaged or provisioned model to load, plus microphone permission. Standalone headless processes may need separate model setup.
Supported RDP viewing runs on Linux, Windows and macOS desktop packages. It is unavailable on Android/Quest, iOS and standalone Web. Local RDP input is currently limited to compatible Linux builds; other clients retain view-only behavior. See Integrations and Media for controls and format limits.
History and connected conversations
Supported local main/helper history can be inspected from Agent Sessions,
Web session views, and terminal /sessions or /switch <session_id>.
Those views do not automatically replay tools or transfer private history to
another device. See Local Agent Session Recovery.
Where Channel conversation is available, select the exact conversation before sending. In channel mode, both operator text and the assistant reply go to that conversation. Similar names can refer to different destinations. A selected robot alone does not select a recipient. Private assistant mode does not send channel messages.
Queued, confirmed, failed and uncertain delivery are different states. Use Check turn after an uncertain result; changing selection or cancelling cannot recall a message already handed to the provider. Do not resend automatically. Stop native hands-free realtime before entering channel mode. Choose Private Assistant to re-enable that mode. Review-required actions can remain unavailable on a channel even when ordinary text works.
Play Flat push delivery remains unverified. Builds without realtime conversation support retain push-to-talk instead. A listed control does not establish those capabilities on the current device.
Release availability
Experimental and development features can differ from a currently deployed build. Check the installed version and its release information. A package, preview or successful local check does not establish physical-device certification.
During offline license grace, status and recovery remain available; product actions require online verification. Reconnect and verify the device rather than assuming a previous verification grants offline authorization.