OmniBox: a self-hostable capture-and-ask hub built from four separate repositories
Collect, organize, use, and share, all in OmniBox.
At a glance
- What is it?
- OmniBox collects webpages, files and chat messages into one store, then answers questions over them with an LLM. It is Apache-2.0 and Python-based, but the monorepo is a submodule shell, so the real code lives elsewhere.
- Who is it for?
- Adopt OmniBox if you want a self-hosted store that takes input from a browser extension, a WeChat bot and an iOS app, and you are willing to clone with --recurse-submodules and read the deploy docs before touching example.env. Do not adopt it if you only need one ingestion path, since a single-purpose note tool or a plain RAG library will be less to operate.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OmniBox targets: capture in many places, ask in one
Most knowledge tools assume you will do your saving inside them. OmniBox assumes the opposite. The README lists capture paths that sit outside the app: a browser extension that saves the main content of a webpage, a WeChat bot that accepts files, webpages, videos, voice messages, text and chat records, and an iOS feature called Flash for voice recordings and text notes, plus iOS share-sheet sending. The stated goal is compressed into one line: collect, then ask. That framing matters because it sets the product boundary. OmniBox is not trying to be the place where you write. It is trying to be the place where things land, so that question answering over your own material has something to work with. The audience is therefore people who already have scattered inputs and want one searchable pool: researchers who save articles, teams that receive documents over chat, anyone whose notes are spread across a phone, a browser and a messaging app. The repository topics confirm this reading, listing agent, ai-search, editor, llm, note and rag together rather than picking one.
Four repositories, one product: the submodule layout is the first thing to understand
The GitHub repository at import-ai/omnibox is not where the application code lives. The README badge row points at four separate repositories: omnibox-web, omnibox-backend, omnibox-wizard and omnibox-browser-extension. Each carries its own version number, and the releases listed for the parent repository (v0.1.48, v0.1.48-beta.1, v0.1.47) are dated within days of each other, which suggests the parent tags move roughly in step with the parts. The quick start makes the arrangement explicit: the clone command is git clone --recurse-submodules, and the README describes the result as a monorepo whose components are pulled in as submodules. This has practical consequences. A plain git clone without the flag gives you a directory that looks complete and is not. Checking out a parent tag does not by itself tell you which commit each submodule is pinned to unless you inspect the gitlink entries. The Python label on the repository is best read as describing the backend, since the web front end, the wizard and the browser extension are separate codebases with their own release cadences. The architecture implied by the README is a backend that performs parsing, indexing and question answering, with several thin clients in front of it: a web app, a browser extension, an iOS app and a WeChat bot. The README does not describe the API between them, so the wire format and authentication model are things to read from the backend repository rather than from this one.
What ingestion and retrieval actually cover, per the README
The feature list is specific about file types: PDF, Word, PPT and MP3 are named as formats that get end-to-end parsing and indexing on upload. End-to-end here means the upload path is expected to produce indexed content without a separate manual step, though the README does not say which parser handles which format or where that work runs. Question answering is described as based on both Internet and local databases, which implies the system can combine retrieved local material with web results in a single answer, but the README gives no detail on how the two sources are ranked or merged. The editor is Markdown with rendering for formulas, mind maps, flowcharts, sequence diagrams, Gantt charts and music notation. That is a wide rendering surface, and it is worth testing each diagram type you depend on rather than assuming parity across them. The account layer covers users and teams, permissions, sharing management, multi-tenancy, multiple languages, dark mode and mobile responsiveness. Multi-tenancy in the README is a bullet point, not a specification. If you plan to host for more than one organisation, the isolation model is something to confirm in the deployment documentation before you build on it.
Getting it running: two commands and one environment file
The README gives exactly one local path, and it is short. Clone with submodules, enter the directory, copy the example environment file, then bring the stack up:
git clone --recurse-submodules https://github.com/import-ai/omnibox.git cd omnibox cp example.env .env bash scripts/dev.sh up -d --build
That is the whole of the quick start. The scripts/dev.sh wrapper takes docker-compose-style arguments (up, -d, --build), which tells you the development stack is containerised, but the README does not enumerate the services, the ports, or the required values in .env. The example.env file is the only documented source for configuration keys, and it is not reproduced in the README, so you have to open it after cloning to learn what must be filled in. For production, the README defers entirely to a Local Deployment page on omnibox.pro, and for the browser extension it links to a separate installation page. There is also a hosted service at omnibox.pro with login by Email, Google and WeChat, which is the fastest way to evaluate the product before deciding whether the self-hosted path is worth the setup. The roadmap marks Agent, folder and document public sharing, the WeChat Bot, the Open API and the Mobile APP as done, with RSS Subscription still open. If RSS is a requirement, it is not there yet.
Where OmniBox is the wrong tool
The capture breadth is also the operational burden. A self-hosted instance here means running a web app, a backend that parses and indexes documents, and whatever the WeChat bot and iOS clients need to reach it. That is a reasonable amount of surface for a team that wants all four input channels. It is a poor fit for someone who wants to save links and search them, because a browser bookmark manager plus a local full-text index does that with one process. The WeChat dependency is a second constraint: the bot is a headline feature, and if your team does not use WeChat, a meaningful part of the README's value proposition does not apply to you. The Internet-plus-local answering is another area to probe. Mixing retrieved web content into answers over your private documents raises questions the README does not answer: whether web retrieval can be disabled per query, whether citations distinguish the two sources, and what leaves your instance when a web lookup happens. Given that the project is at v0.1.x, with a beta tag published three days before the corresponding release, expect the API and the submodule pins to move. The README's own structure reflects this: the web, backend, wizard and extension each version independently, so an upgrade is four decisions, not one.
Compared with a plain RAG stack or a hosted knowledge base
The closest alternative for a Python team is not another all-in-one product but a retrieval library such as LlamaIndex or LangChain wired to your own storage. The difference is where the work sits. With a RAG framework you write the ingestion pipeline, choose the parser for each file type, decide the chunking, and build the interface yourself. OmniBox ships those choices already made: parsers for the listed formats, an index, an editor, a permission model and four clients. You trade control for not having to build the capture layer, and the capture layer is the tedious part. The other alternative is a hosted knowledge base, where you give up self-hosting in exchange for zero operations. OmniBox's answer to that is the deployment path in its docs, which the README points to but does not reproduce. If data residency or the ability to run offline is the reason you are looking at this repository, the self-hosted route is the one that matters, and the hosted service at omnibox.pro is only useful as a way to see the interface before you commit to running it.
Licence, releases and the cost of keeping up
The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes an explicit patent grant. That is a permissive licence, not a copyleft one, so it does not oblige you to publish changes. Two caveats follow from the structure rather than the licence text. First, the parent repository's licence does not automatically tell you the licence of each submodule, so check the LICENSE file in omnibox-backend, omnibox-web, omnibox-wizard and omnibox-browser-extension separately. Second, Apache-2.0 requires that notices be kept intact, which matters if you fork and rebrand. This is not legal advice; a lawyer should review anything you ship commercially. On maintenance, the release cadence visible in the supplied data is fast: v0.1.47 and v0.1.48 landed three days apart, with a beta in between. Fast patch releases at a 0.1 version number usually mean the interface is still settling. Budget for reading release notes before each upgrade and for re-checking submodule pins, because a parent tag alone does not describe the full state of the tree. The upside of the split layout is that you can pin the backend while letting the browser extension track upstream, if the versioning allows it.
Editorial conclusion
Adopt OmniBox if you want a self-hosted store that takes input from a browser extension, a WeChat bot and an iOS app, and you are willing to clone with --recurse-submodules and read the deploy docs before touching example.env. Do not adopt it if you only need one ingestion path, since a single-purpose note tool or a plain RAG library will be less to operate. Before committing, verify which submodules the tag you are checking out actually pins, what the backend requires for storage and model access, and whether the Apache-2.0 licence text is present in the sub-repositories as well as the parent.
Community notes