Feature: Suggest Tab by semantic vector similarity of tabs and titles

[bennolor]

By fetching not just the URL but also the Tab title from the browser and vector embedding the combination of the two via a small model (i.e. https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2 ) we can then suggest tab groupings by vector similarity.

The likely best way to go about this is to generate the vector on change and recalculate cosine similarities.
Embedding a single tab has minimal overhead as the content is quite low and calculating groups is also a fairly solved and performant issue.

Example for preparing embed:

tab.url = "https://github.com/nitzanpap/auto-tab-groups/issues/new?exampleurlparamsfluff"
tab.title = "New Issue"

embedding_string = " github.com nitzanpap auto-tab-groups issues new new issue" 

cleaning up this way should reduce the overall amount of tokens to be embedded and avoid noise of processing irrelevant context that causes unwanted results.

This approach should have a drastically lower performance overhead whilst still providing semantics based tab grouping.
It should also be able to reliably run in the background without needing the user to actively promt the llm to suggest rules/groupings.

Furthermore if I understand manifest v3 correct it should not require additional permissions from the user

---

If there is interest for this approach I could try to create a pull request for this concept.

[nitzanpap]

Thanks @bennolor — this is a genuinely well-thought-out proposal, and the
reasoning holds up. Embedding URL + title and clustering by cosine similarity
would be far cheaper than what's currently shipped, and "suggest, don't
auto-apply" is the right call for something probabilistic. Your point about
cleaning the string before embedding to cut noise is a good one.

Some context you can't see from outside the repo, because it changes the shape
of the problem:

There's already an AI layer. It's opt-in and off by default, runs WebLLM
with Qwen2.5-3B on-device, and needs WebGPU. There's a provider abstraction
behind it, so an embedding-based provider could slot in alongside the LLM one
rather than replacing anything.

It's Chrome-only, and that's the hard part. WebLLM bundles a 4.5 MB inline
tokenizer, which pushes the output over the Firefox Add-on Store's 5 MB
per-file parse limit — so the Firefox build swaps it for a stub. Any embedding
library would have to pass that same test to reach Firefox users. Model weights
themselves download at runtime, so delivering them isn't the blocker; the JS
bundle is.

The honest gate is whether anyone uses the AI features already there. The
extension has no telemetry, deliberately — the privacy policy is that nothing
leaves your browser — so I have no way to know whether the AI features get
switched on at all. Committing weeks to a second AI path before knowing that is
hard to justify, and I'd rather say so than leave this open indefinitely with no
answer.

So: not planned right now, but not dismissed. Two things would move it — other
people in this thread saying they'd use it, or a proof of concept. If you
wanted to try one, the provider abstraction is the place it would plug in, and
the Firefox bundle-size question is the thing worth checking first because it
decides whether this is Chrome-only too.

(Related: #44 is an open plan for getting AI working on Firefox via wllama.
Same underlying question.)