Local coding models need better repo context, not just bigger context windows
Local coding models have a repo-context problem.
When using llama/qwen/mistral/gemma for coding, the hard part is often not the model itself. It is getting the right files/functions into context without dumping too much raw source.
Long context helps, but it does not solve retrieval.
If the model never sees the right file, it still guesses.
I’ve been building SigMap, a zero-dependency CLI that creates a compact repo map for coding workflows.
Instead of sending raw source first, it extracts:
- function signatures
- classes/interfaces
- exports
- import relationships
- ranked file matches per query
The workflow is simple:
repo map first → find likely files → read full source only where needed
Benchmarked across 18 repos / 90 tasks:
- 81.1% hit@5 vs 13.6% random baseline
- ~6× better file retrieval
- 96.9% token reduction in the benchmark setup
- 41.4% fewer prompts per task
No embeddings. No vector DB. No npm dependencies.
This is not meant to replace LSPs, grep, agent search, MCP tools, or full-file reads.
It is meant to give local coding models / agents a cheap first-pass structure map before deeper inspection.
Repo: https://github.com/manojmallick/sigmap
Benchmark suite: https://github.com/manojmallick/sigmap-benchmark-suite
Curious how people here handle repo context with local coding models.
Are you mostly using grep/search, RAG, repo maps, MCP tools, or just relying on longer-context models?
Edit: Good point from the comments — SigMap core is model-agnostic. The docs currently look too focused on proprietary assistants, so I’ll add clearer examples for VSCodium/Open VSX, Continue, Cline/Roo Code, Aider, OpenHands, and local Ollama/llama.cpp workflows.