Rabbit's OS3 Bets That Users Want One Conversation, Not One App

A small operations team running client work across a laptop, a cloud VM for heavier compute, and a phone for on-the-go approvals loses real hours every week just moving context between those three surfaces: re-explaining a task, re-uploading a file, re-authenticating into a tool that lives on only one machine. That friction is small enough to ignore day to day and large enough, over a quarter, to eat a meaningful chunk of billable time. Rabbit's new operating system is built explicitly around erasing that friction, and its launch this week is worth examining not for the hardware angle but for what it implies about how AI-native companies think people should relate to their devices going forward.

A Single Conversation Replaces the App Grid

On September 22, rabbit inc. announced the general release of OS3, which it calls an agentic operating system built around one chat interface as the primary way users interact with their devices. Instead of opening separate apps, switching accounts, or managing session threads, a user states an outcome and OS3 reasons through what's needed: pulling in connected AI models, the open web, existing services, or other devices the account controls. The company frames this as ending "isolated accounts and fragmented chat threads" in favor of one continuous, linear conversation that keeps track of prior context automatically.

The practical mechanism is multi-device orchestration. One rabbit account can connect up to five devices — Windows, Mac, or Linux machines, cloud VMs, dedicated AI hardware, or rabbit's own r1 — and OS3 decides where a given task should run, moving work between devices as needed and retrieving whatever files, applications, or skills the job requires. A local rabbit agent installs with a single command and gives OS3 the hooks to actually operate a machine, rather than just advise from a chat window.

Betting on Openness Instead of a Walled Garden

What separates OS3 from a typical assistant product is how aggressively it avoids locking users into rabbit's own models or ecosystem. The system supports "bring your own key" access to frontier AI labs, cloud router platforms, or locally hosted models, and users can swap models mid-task without losing context, memory, or configured skills. Rabbit also says any AI skill published anywhere can be added by pasting its URL into the chat, with no command-line setup or configuration files required.

That openness matters because the model layer underneath these systems is moving fast on its own. The same week rabbit shipped OS3, Anthropic released Claude Opus 5.5, a model it positions as its new agentic coding leader, priced 40% cheaper than its predecessor and reporting strong results on agentic coding and computer-use benchmarks. A rabbit user who wants that specific model for a coding-heavy task, and a different model for research or writing, can theoretically plug both into the same OS3 conversation without re-platforming. Whether that flexibility holds up in daily use is something only broader adoption will show, but the architectural intent — decoupling the orchestration layer from any single model vendor — is a deliberate design choice, not an accident of timing.

On top of model flexibility, OS3 pairs its own DLAM technology with the local agent to enable what rabbit calls direct computer control: operating desktop software, local files, and web pages on a user's behalf, plus writing, debugging, and running software autonomously. That combination — an LLM fused with coding and personal-agent capability — is what allows the system to claim it can act across a task's full lifecycle rather than just draft a plan for a human to execute.

The Privacy Architecture Behind the Control

Granting an operating system this much reach naturally raises the question of what happens to a user's data. Rabbit's stated model has three components: the local agent doesn't copy, store, use, or sell data from a user's machine, though conversations and the memory built from them are stored on rabbit's servers; context handed to a model provider is processed through rabbit's servers first but not retained there, with files staying on the user's device; and all actions are user-initiated, with sensitive steps requiring explicit confirmation and system-level permissions that can be revoked at any time. Rabbit's own framing is that OS3 "does not run tasks on its own" — an important distinction from more autonomous agent designs, since it keeps a human confirmation step in the loop for consequential actions even while automating the mechanics around them.

Following the Idea Into a Business Scenario

Consider a five-person consulting shop that does market research and light software prototyping for clients. Today, one team member drafts a report on a laptop, another spins up a cloud VM to run a heavier data pull, and a third fields a client's urgent Slack message from their phone — three separate contexts, three separate memories of what's already been done, and a project manager stitching it together at the end of the day.

Under an OS3-style workflow, the team would instead operate through one shared conversational thread tied to a single account. A team member could ask the system to pull client data, and OS3 would determine that task needs the cloud VM's compute rather than the laptop, route it there, and report back in the same thread. If a code prototype needs debugging, the system could hand that piece to whichever connected model is best suited to the job — plugging in something like Claude Opus 5.5 for a coding-heavy pass — without anyone manually copying files between environments. The promise is fewer handoffs and fewer places for context to get lost.

The tradeoff is concentration of trust. A single unified identity spanning five devices means one compromised account, one over-broad permission grant, or one misrouted task has a wider blast radius than a fragmented setup ever would. Rabbit's confirmation-gated, user-initiated design is meant to blunt that risk, but centralizing this much control is still a different security posture than the app-by-app model most businesses run today, and operators adopting it should treat permission review as an ongoing discipline rather than a one-time setup step.

What Operators Should Actually Do With This

For founders and operations leads evaluating OS3 or systems like it, a few concrete next steps make sense: pilot it on a low-stakes, multi-device workflow before touching anything client-facing; audit exactly which permissions the local agent requests on each connected machine, and revoke anything not tied to an active task; and treat the "bring your own key" flexibility as a chance to match specific models to specific job types — a cheaper, faster coding model for engineering work, a different one for research synthesis — rather than defaulting to whatever ships as the system's baseline. Rabbit says OS3 is available now through os3.rabbit.tech, with additional device types and input methods still rolling out, so early adopters should expect the feature set to keep shifting under them for a while yet.

Sources