where-next-gemma-xl1

The default model for where-next (wn). It's a local "where next" ranker for coding agents and developers: given a task, error or question, it ranks the files in a repository that you're most likely to need next.

Gemma is provided under and subject to the Gemma Terms of Use found at ai.google.dev/gemma/terms. This model is a Model Derivative of google/embeddinggemma-300m. It was fine-tuned by the where-next project and isn't affiliated with or endorsed by Google. Use of this model must comply with the Gemma Terms of Use and the Gemma Prohibited Use Policy. If you redistribute it or its derivatives, these restrictions must be passed on to recipients.

Usage

With the wn CLI (it downloads, verifies checksums and shows the licence notice):

curl -fsSL https://raw.githubusercontent.com/andreylukin/where-next/main/install.sh | sh
wn init && wn ask "where is the retry logic for failed uploads?"

Files:

• model.onnx and model.onnx.data: the fp32 ONNX graph, including mean pooling, Gemma's dense projection and normalisation. The output is 768-d L2-normalised embeddings (Matryoshka, so it can be truncated to 512, 256 or 128).
• tokenizer.json: the base model's tokenizer.
• wn-model.json: prompts and settings (query prefix task: code retrieval | query: , document prefix title: none | text: , max length 1024, query format v2).
• wn-manifest.json: sha256 of every file. wn verifies these on install.

Documents are file "skeletons": the path, the first doc or comment line, and top-level symbol names. Queries are the task text, optionally followed by the last tool output and earlier context (format v2).

Training

A contrastive fine-tune (MultipleNegativesRankingLoss with hard negatives) of EmbeddingGemma-300M on about 1.1M (query, file) pairs whose labels are outcomes: the files a change actually edited.

• Sources:
  • commit messages → the files and functions they changed, from about 2,600 public GitHub repositories plus the CommitPackFT and CommitChronicle datasets;
  • issue → fix files, and files an agent run read and then edited, from public agent-trajectory datasets (SWE-rebench, SWE-Gym, SWE-smith and similar);
  • error output → the location of the fix;
  • synthetic follow-up queries.
• A small amount of the author's own work: about 0.5% of the data comes from the author's own repositories and coding sessions.
• Eval exclusions: the evaluation repositories (ContextBench, SWE-bench Verified, Multi-SWE-bench, SWE-PolyBench and Long Code Arena) were excluded from training.

Evaluation (preliminary)

hit@k = at least one gold file in the top k. The candidates are every source file in the repository at the task's base commit, and the query is the issue text alone.

Also, hit@5: Multi-SWE-bench 0.661, SWE-PolyBench 0.702, SWE-bench Verified 0.822. Full protocol and limitations: where-next benchmarks.

Limitations

• It's a first-pass locator that returns hints, not answers. In a live agent trial on normal-sized repositories, hints didn't reduce a capable agent's cost. See the project README.
• Documents are skeletons, so logic hidden inside oddly named functions can be missed.
• It's weaker on short conversational follow-ups; send self-contained queries.