fittok

# fittok

**Retrieve only the relevant source code for a question — instead of the model
reading whole files — so an LLM answers codebase questions on a small, focused
slice of context.** Less input = fewer tokens, lower cost, faster answers.

Works three ways from one install: an **MCP server**, a **CLI**, and a **Python
library** — plus a **Claude Code plugin** that injects context automatically.

📖 **[Full command reference → docs/HANDBOOK.md](https://github.com/likhithreddy/fittok/blob/main/docs/HANDBOOK.md)**

<!-- MCP Registry: PyPI ownership verification — do not remove this line -->
mcp-name: io.github.likhithreddy/fittok

---

## How it works

```
codebase ──▶ graphify ──▶ slurp ──▶ readable slice ──▶ LLM answers
             (parse)      (select)   (trim to budget)
```

1. **graphify** — parses the repo with tree-sitter into a knowledge graph of
   functions / classes / methods (Python, JS, JSX, TS, TSX, Java, Go, Rust).
   Supports multi-language call/import/reference edges.
2. **slurp** — scores every node against the question using a **4-signal hybrid**:
   - **Semantic embeddings** (all-MiniLM-L6-v2) — meaning-based matching
   - **Content-BM25** (with camelCase/snake_case splitting) — keyword matching
   - **Summary-BM25** (node name + file + callers + callees) — structural matching
   - **PageRank** — graph centrality / hub detection

   Signals are fused via **Reciprocal Rank Fusion (RRF)** — rank-based, no score
   calibration issues. Nodes are selected via **round-robin directory interleaving**
   (guarantees facet coverage on multi-aspect queries — one node from each code
   area before any gets a second) with a **per-node token cap** (25% of budget, so
   large components don't crowd out smaller functions). A **relevance cliff**
   (semantic OR BM25 OR summary-BM25 threshold) excludes noise.
3. **readable output** — returns the **actual source code** of selected nodes,
   plus a **codebase map** (table of contents with docstrings, inspired by
   Karpathy's LLM Wiki / Google's OKF) so the model can route follow-up calls
   precisely. The model answers directly from it — no file reads needed.

As you edit, a file watcher (auto-started on first query) updates the graph
**incrementally** — only changed files are re-parsed and merged, and only
changed functions re-embed. Graphs and embeddings are cached on disk
(`~/.cache/fittok`). Set `FITTOK_AUTOWATCH=false` to disable the watcher, in
which case an edit triggers a full re-parse on the next query.

---

## Getting the best results (and known limitations)

### Ask focused questions

fittok ranks code against your question using a **4-signal hybrid** (semantic +
BM25 + structural + PageRank, fused via RRF) with **round-robin directory
diversity** — so multi-facet questions surface code from multiple areas (UI,
server, database) instead of clustering in one dominant area. It's most accurate
with **focused, specific questions** — ideally one concern each, and naming the
function/component/route when you can. Multi-facet questions are supported via
**decomposition** (the tool description tells the model to call once per aspect)
and the **codebase map** (a table of contents prepended to every response).

- ✅ *"How does `runSandboxQuery` execute and isolate a SQL query?"* → surfaces the exact function + its isolation code.
- ✅ *"How does the querydle client submit a query and render results?"* → surfaces the UI component.
- ✅ *"Trace the full lifecycle: UI submission, sandbox execution, data isolation"* → decomposition + round-robin diversity covers multiple facets; the codebase map routes the model to any missed files.

**Rule of thumb:** one concern per question (or 2–3 facets max). For "explain
the whole feature," split it into a few focused questions instead of one mega-query.

### Known limitations

- **GitHub Copilot Chat truncates large MCP outputs (the big one).** Copilot caches MCP tool results above ~7 KB to a `content.json` file, where the entire markdown collapses to ONE physical JSON line (newlines escaped) — and its Read tool truncates any line at ~2,000 characters. So an output over ~7 KB is effectively chopped to ~2,000 chars *regardless of total size*; the model can't see most of the code and falls back to reading source files directly. This is Copilot's delivery layer, not fittok — **every MCP server hits this wall.** By default (0.10.0+) fittok returns *all* relevant code uncapped, which is correct for clients that deliver inline but will be truncated by Copilot. Two workarounds:
  - **Cap the output for Copilot** so it's delivered inline (under the ~7 KB threshold). Set `FITTOK_MAX_BUDGET=1200` in your MCP server's env:
    ```json
    { "servers": { "fittok": { "command": "uvx", "args": ["fittok"], "env": { "FITTOK_MAX_BUDGET": "1200" } } } }
    ```
  - **Use Claude Code or the CLI** for multi-file questions. They deliver MCP output inline with no truncation — which is where fittok's complete (uncapped) results and anti-re-read design actually pay off.
- **Vocabulary gap on abstract queries.** When the query uses words that don't appear in the code (e.g. "isolation" → `REVOKE`/`DENY`), neither semantic nor BM25 can bridge it. The codebase map (file names + docstrings) and round-robin diversity help; naming the function/file routes the model to it.
- **Incremental edge-loss:** editing a file can drop call/import edges *into* it from unchanged files until a full re-parse. fittok auto-recovers on restart or `reset_graph`.
- **Token counts are approximate:** counts use `cl100k_base`, so real usage drifts ~10–20% vs Claude's tokenizer (only matters when you opt into a `FITTOK_MAX_BUDGET` cap).
- **Very large repos:** PageRank is not yet vectorized — fine through low-thousands of nodes, slower beyond that.

---

## Installation

fittok ships as an **MCP server**, a **CLI**, and a **Python library**. It uses
`torch` for embeddings, so a Python runtime must be present. **Pick one runtime**
below, then follow the section for your client.

> Every config below launches fittok as `uvx fittok`. If you chose Python or
> `pipx`, swap that for `python -m fittok` or `pipx run fittok` respectively.

### Prerequisites — choose a runtime (one of)

**A. `uv` — recommended (no Python needed on the machine)**

```bash
curl -LsSf https://astral.sh/uv/install.sh | sh   # Linux / macOS
winget install astral-sh.uv                        # Windows
brew install uv                                    # macOS (Homebrew)
```
Launch command: `uvx fittok` — `uv` provisions its own Python + all deps in
isolation. One static binary, so it's deployable org-wide via MDM/Intune/winget.

**B. Python 3.10+ (already on the machine)**

```bash
python -m pip install fittok      # Linux / macOS
py    -m pip install fittok       # Windows
```
Launch command: `python -m fittok` (Windows: `py -m fittok`).
> Managed Linux may reject `pip install` with PEP 668
> ("externally-managed-environment") — use option A to avoid it.

**C. `pipx` — isolated, no global install**

```bash
brew install pipx                               # macOS
pip install --user pipx && pipx ensurepath      # Linux / Windows
```
Launch command: `pipx run fittok`.

### MCP server — Claude Code

```bash
claude mcp add fittok -s user -- uvx fittok
```
Restart Claude Code → `/mcp` → confirm `fittok` is **connected**, then ask
codebase questions normally.

### MCP server — VS Code / GitHub Copilot Chat

```bash
code --add-mcp '{"name":"fittok","command":"uvx","args":["fittok"]}'
```
Or paste into `.vscode/mcp.json` (workspace) or your user `mcp.json`:
```json
{ "servers": { "fittok": { "type": "stdio", "command": "uvx", "args": ["fittok"] } } }
```
Then in Copilot Chat: **Agent** mode → enable fittok's tools (*Configure Tools*).

### MCP server — GitHub Copilot CLI

```bash
copilot mcp add fittok -- uvx fittok
copilot mcp get fittok          # verify status + tools
```

### MCP server — Cursor / Windsurf / any MCP client

```json
{ "mcpServers": { "fittok": { "command": "uvx", "args": ["fittok"] } } }
```

### Auto-trigger (optional, every MCP client)

To make fittok fire on **every** codebase question — without naming it — **and**
stop your client from re-reading files fittok already returned (which would
discard the savings), add this one line to your client's instructions file:

> *"For any codebase question, call fittok first and answer from its output —
> don't re-read files it already returned code from."*

The first half triggers fittok; the second keeps the client from opening the
same files afterward. They reinforce each other — one shapes *strategy* (use
fittok), the other stops the *double-read*. For a stronger, more explicit block:

> For any codebase question ("how does X work", "where is Y"):
> 1. Call the fittok MCP tool first, once.
> 2. Answer directly from its `optimized_context` — it is the real, authoritative
>    source for that question.
> 3. Do NOT read or grep the files fittok already returned code from. That
>    discards the token savings fittok exists to provide.

For the strongest effect, put it in your **user-global** instructions so it
applies to every repo, not just one:

| Client | Instructions file |
|---|---|
| Claude Code | `CLAUDE.md` (repo) or `~/.claude/CLAUDE.md` (user-global) |
| GitHub Copilot | `.github/copilot-instructions.md` or Copilot user instructions |
| Cursor | `.cursor/rules/*.mdc` (or `.cursorrules`) |
| Windsurf | `.windsurfrules` |

> fittok also bakes this rule into every response (an "answer from this, don't
> re-read" line above the code), so it works even without the snippet above —
> the snippet just makes it the client's default across all questions.

### CLI

```bash
cd /path/to/your/repo

uvx fittok index                                      # optional pre-warm (~15s, cached)
uvx fittok query "how does auth work"                 # LLM answers from relevant code
uvx fittok query "how does auth work" --budget 1500   # cap the slice at 1500 tokens
uvx