Search engines are good at finding links, but a long flat list still leaves the user with the work of building a mental model. I built OneSearch to test a different interface: collect web results, organize related pages into semantic folders, and keep that structure visible while sources open in independent desktop tabs.
The pipeline
A OneSearch query moves through four stages:
- Fetch web search results.
- Create embeddings locally through Ollama.
- Cluster related results using the embedding vectors.
- Ask a local labeling model to name each cluster and build a folder hierarchy.
The resulting workspace is not just a generated summary. Every original result remains available, and each page opens in its own in-app tab so the user can compare sources without losing the folder structure.
Why local AI
The AI classification runs on the user's computer. The free setup uses a 4B labeling model so it can run on more machines, while the Pro option can use an 8B or 14B model for more precise labels.
"Local AI" does not mean the entire app is offline: search still needs the network and the selected search provider. It means the embedding and labeling stages run through the local Ollama runtime rather than sending search-result text to a hosted language model.
The reliability problem I hit
Small models do not always return valid structured output. During testing, the 4B model could occasionally fail the labeling stage with malformed JSON or incomplete cluster labels. Treating that as a fatal pipeline error made the whole search feel broken even though collection, embedding, and clustering had already succeeded.
For 1.0.0 I changed the failure behavior:
- Validate the model response against the expected cluster set.
- Keep model-generated labels when the response is complete.
- When generation fails or labels are missing, create deterministic labels from the cluster's domain, title, and keyword signals.
- Return the complete folder hierarchy instead of failing the search.
The fallback is less expressive than a successful model response, but it preserves the useful work and makes the free 4B path much more predictable.
Desktop packaging
OneSearch is built as a Tauri desktop application for macOS Apple Silicon and Windows x64. The release bundles the application server and prepares the local Ollama runtime so first-run setup can install the required models.
The current 1.0.0 binaries have been rebuilt and verified by SHA-256. macOS startup was smoke-tested from the DMG, and the Windows installer structure and x64 binaries were checked from the build environment.
There is still an important limitation: Apple Developer ID/notarization and Windows code signing are pending. Gatekeeper or SmartScreen can therefore show a security warning. I document that directly instead of presenting the current build as warning-free.
What I want to learn next
The main questions are not about adding more generated text. I want to know:
- Are the folders actually useful for research and comparison?
- Is first-run local-model setup understandable?
- When the fallback activates, are its labels still good enough to navigate?
- Which search workflows are worth saving and exporting?
You can try OneSearch on macOS Apple Silicon or Windows x64. The GitHub release includes the installers, hashes, and current signing status.
Feedback on the clustering, onboarding, and desktop workflow is welcome.
