ADeus Remains a Blueprint While Omi Gets the Active Development
ADeus remains publicly accessible, but it is no longer the active home of the wearable AI project. The current ADeus repository preserves its application, device and Supabase code while pointing active development to the former Friend repository, whose address now resolves to Based Hardware’s Omi project.
Omi is demonstrably active rather than merely a renamed landing page. Its official release history lists Omi Desktop v0.12.171 as a candidate release dated August 14, 2026, alongside several other builds from the preceding days. ADeus is therefore most useful now as an architectural reference, while Omi must be evaluated as the maintained successor ecosystem.
What the original ADeus design contains
ADeus divides a personal AI assistant into three layers. Wearable hardware captures speech, a Supabase-based backend processes and stores the resulting material, and a mobile or web application provides a chat interface for retrieving it. The repository separates these responsibilities into device, application and backend directories rather than treating the wearable as a self-contained assistant.
This architecture makes the device only one part of the privacy and reliability equation. The wearable supplies audio, but transcription, storage, authentication, retrieval and language-model interaction depend on the configured backend. A working deployment consequently requires more than assembling or obtaining the recording hardware.
The project’s defining proposition was that users could operate their own server instead of accepting a vendor-controlled database as the only option. That remains a meaningful design distinction, although it transfers responsibility for credentials, software updates, backups, access controls and deletion procedures to whoever runs the system.
A preserved codebase is not a maintained ADeus product
The repository notice changes how prospective users should interpret ADeus. It does not present a new ADeus hardware version, a current release schedule or a supported upgrade route from the original system. Instead, it retains the earlier implementation and directs ongoing wearable development elsewhere.
Omi should not be treated as an automatic update for an existing ADeus installation. It has its own repository structure, applications, backend, firmware and release process. Similar goals and project lineage do not establish drop-in compatibility between their databases, devices or clients.
This distinction also separates two different reader needs. A developer researching how wearable capture can connect to conversational memory may still find ADeus useful. Someone seeking maintained software, current builds and an operating product ecosystem should examine Omi directly rather than assume that the ADeus name still represents the active release channel.
The repository license restricts redistribution
ADeus makes its source visible, but its top-level license is CC BY-NC-ND 4.0 rather than a conventional permissive software license. The NonCommercial and NoDerivatives conditions make the practical rights substantially narrower than the repository’s broad “open-source” description might imply.
The Creative Commons license deed permits attributed, noncommercial sharing of unmodified material but prohibits distributing adapted material. It also cautions that the deed is a summary rather than the complete legal text and that other rights may affect a proposed use.
For developers, the important boundary is redistribution. Reading the code or experimenting privately is not equivalent to having permission to publish a modified fork, ship an altered device image or incorporate the work into a commercial product. Dependencies and separately licensed components may introduce additional terms, so the repository-level notice is not necessarily the complete licensing picture.
Self-hosting does not guarantee fully local processing
Running the database on infrastructure controlled by the wearer can reduce dependence on a product vendor, but storage location does not define the entire data path. Audio, transcripts or retrieved context may still reach external speech-recognition and language-model services, depending on how a deployment is configured.
A privacy assessment therefore has to follow the information through every stage: audio capture, transmission, transcription, database storage, model requests, backups and client access. The claim that ADeus can store information on a user-controlled server does not by itself establish that every processing stage remains on that server.
Wearable recording also involves people other than the device owner. Captured conversations can include personal details, workplace information or speech from participants who did not expect it to become searchable. Encryption, retention limits, access controls and compliance with applicable recording rules are operational requirements, not consequences that source-code availability resolves automatically.
Where ADeus still has value
ADeus remains a useful blueprint for examining the boundaries between wearable hardware, a personal-data backend and a conversational interface. Its separated components expose the major decisions that a closed consumer device can obscure, including where audio is processed, who operates storage and which model services receive context.
It is a weaker choice for anyone expecting a supported assistant under the ADeus name. Active development has moved to Omi, the original license limits redistributed adaptations, and self-hosting requires continuing infrastructure and security work. The durable contribution of ADeus is its system design—not an active product roadmap.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.