I built OneSearch to turn a flat result list into semantic folders while keeping the actual source pages close at hand. The desktop app runs the organization pipeline locally with Ollama and keeps the resulting folder tree visible while pages open in separate in-app tabs.

The interesting engineering problem was not generating a folder name. It was keeping the whole search usable when a small local model produced an incomplete answer.

The pipeline

A OneSearch query moves through several explicit stages:

1. Fetch, normalize, and deduplicate web results.
2. Build embedding text from each title, snippet, and domain.
3. Generate local embeddings through Ollama and cache them.
4. Cluster the vectors.
5. Extract keywords and representative domains for every cluster.
6. Ask a local Qwen model for labels, parent labels, and short summaries.
7. Build the folder hierarchy and return timing and cache diagnostics to the UI.

The stages are deliberately separate. That makes failures visible and lets the app degrade one stage without discarding all earlier work.

Clustering without trusting one algorithm

Search-result sets vary a lot. Some queries produce several clean topics; others contain one broad theme plus a few outliers.

OneSearch starts with a lightweight HDBSCAN-style pass. If it cannot form at least two useful groups, the pipeline falls back to agglomerative clustering. If that result collapses into one group or creates one group per item, it tries k-means++.

Afterward, it removes outliers, merges overly similar groups, splits oversized groups, and balances the result. This is more code than calling a single clustering function, but it avoids treating one algorithm as universally correct.

Where the 4B model failed

The free configuration uses qwen3:4b for labeling. It is fast enough for a desktop workflow, but small models do not always follow a structured-output contract.

The most common failure was malformed or incomplete JSON. A label request could successfully finish at the model level and still be unusable by the application. Originally, that surfaced as a labeling error and made the whole search appear broken.

That was the wrong failure boundary. Search results, embeddings, clusters, keywords, and domains were already available. Only the human-friendly names were missing.

A three-layer recovery path

Version 1.0.0 handles labeling in three layers.

1. Constrain generation

The Ollama request uses JSON output, disables thinking text, sets temperature to zero, and limits the prediction budget. This reduces variation before parsing begins.

2. Repair once

If the first response is not valid JSON, OneSearch sends the raw output through one focused repair prompt. The repair request asks for minified JSON only and preserves the original data.

The retry is intentionally bounded. Repeating the same request indefinitely would make local latency unpredictable.

3. Fall back deterministically

If generation still fails, or if the response does not contain a complete entry for every cluster, the app creates labels from data it already trusts:

• the top cluster keywords,
• the most representative domain,
• a short slice of the first result title,
• or a numbered search-group name as the final fallback.

The hierarchy remains usable and the UI shows that folder names were recovered. Failed model output is not written to the label cache, while complete successful responses can be reused.

This changed a fatal AI dependency into an optional quality improvement.

Desktop tradeoffs

Local processing gives users control over the model and keeps the organization step on their machine, but it is not free of cost.

The first Ollama model download is large. Lower-memory machines take longer to embed and label a result set. The current macOS and Windows installers are also unsigned, so Gatekeeper or SmartScreen can display a warning. Those limitations are stated on the download page rather than hidden behind the launch message.

The next release priorities are code signing, clearer model-size guidance, and more real-world evaluation of folder cohesion.

OneSearch 1.0.0 is available for macOS Apple Silicon and Windows x64. The free workflow does not require an account.

Try OneSearch and see the implementation details

I would especially value feedback on the fallback boundary: when a local model fails, is a deterministic but less polished label the right behavior, or should the UI stop and ask the user to retry?