code-context
by infino-ai
README.md
<div align="center">
[](https://github.com/infino-ai/supergrep/actions/workflows/ci.yml)
[](https://www.npmjs.com/package/@infino-ai/code-context)
[](LICENSE)
</div>
# SuperGrep
**Retrieval + inference offload for AI coding agents.** Help your agents find answers faster and at lower cost, while keeping the same answer quality. Particularly useful for cheaper models.
**[Try it live at infino.ai/supergrep](https://infino.ai/supergrep)** - put a question to a real codebase and watch the same model answer it with and without SuperGrep, side by side, with the bill for each. Supergrep uses Infino for retrieval, which tightly integrates small language models with indexes for scalable agent retrieval on object storage.
SuperGrep offers agents four tools over an Infino index, kept in two places. `find` and plain `sql` run on your machine, over the keyword index. Conversely, anything with meaning in it - `search`, a `sql` statement with a ranked search inside it, and `ask` - runs in the Infino cloud, so heavy compute and embeddings stays off your laptop. Infino also embeds inference models in its service, so several small models work the index at once and hand your agent the rows they found. Your agent keeps the reasoning, writes the answer, and decides when to use SuperGrep. No configuration.
<details>
<summary>The four tools, one line each - for the agent reading this</summary>
| tool | what it does |
|---|---|
| `find` | Every line containing an exact string, like `grep -n`: complete, unranked, with the repo-wide total and per-file counts. Tens of milliseconds from the index. |
| `search` | One ranked pass fusing exact keyword matching with semantic similarity, so it works whether or not you know the words. Hits carry the code, cited `path:line`. |
| `sql` | Read-only SQL over the index. The ranked searches are table-valued, so "which files have the most code about X" ranks and tallies in one query. |
| `ask` | A question that spans the repository, handed to small models on the Infino service that run the investigation against the index and return the rows they found, cited `path:line`, rather than prose. Several asks run at once. |
</details>
## What people use it for
- **Code review.** The reviewer's question is "what else calls this, and what breaks if it changes". `find` answers with every caller and the counts in one call, and `ask` reads the paths that matter, so the review is about the change rather than about finding it.
- **Big explorations.** "How does X work end to end" spawns fifty look-ups. With SuperGrep they run as fifty asks in parallel against the index, instead of fifty subagents reading the tree into your bill.
- **Several codebases at once.** Every local tool takes a repository path, so one session roams across every repo it touches - the service, the client, the shared library - without a checkout per question.
- **Code, logs and issues together.** Index the logs, the test output and the issue export beside the source, and "why did this integration test start failing?" is one question over all of them.
## Your agent reaches for it on its own
The model's own file tools stayed available throughout. What it had from SuperGrep was the server's instructions, which say which tool fits which kind of question; the choice on each call was the model's. The calls that are not SuperGrep are mostly `Read`: the model opens a file *after* the index has told it which one, rather than instead of asking. That is the shape you want - the index does the finding, and the model still opens what it needs to quote.
## Go beyond code - index your entire laptop or any corpus
SuperGrep looks across all the files a question needs, not just the source. Logs, test output, stack traces, CI output, configuration and docs go in beside the code -
`.log`, `.out`, `.err`, `.jsonl` and `.ndjson` are chunked at record boundaries, so a stack trace stays with the message that explains it -
and the same four tools run over all of it: `find` for an exact stack frame, `search` for a failure you can only describe, `sql` to count and rank across a
run, `ask` for the question that spans several of them at once.
That matters most where a frontier model is weakest. A log is the pathological case for a context window - large, repetitive, mostly irrelevant, and paid for
again on every turn it stays in the transcript. An index collapses it to the spans that matter before the model sees any of it. On a public benchmark of CI-failure diagnosis, scored by the benchmark's own judge, that puts SuperGrep second on the score and first by a distance on score per token of context:
For files that don't fit on your laptop - write them out to Parquet files in object storage and point SuperGrep at them without ever loading them onto your laptop ([how](#indexing-from-object-storage)). You can search them together with your code or laptop files using the same tools.
## What it saves
The same model, the same 36 questions about a 256,000-line codebase, with and without SuperGrep. Every answer was checked against the code. **Fully correct** means every claim held and the whole question was answered. The bill is everything you pay: your model, its subagents, and SuperGrep.
<details>
<summary>How the runs were set up</summary>
Real agent runs through the Claude Agent SDK, the same minimal prompt in every arm, on the [infino](https://github.com/infino-ai/infino) engine repository, measured 2026-09-24. Thirty-six questions in five categories: aggregation (10), comprehension (6), by meaning (6), pinpoint (8), known file (6). The file-tools arm is stock Claude Code: Glob, Grep, Read, LS, Bash, and the Agent tool with the built-in Explore subagent. The SuperGrep arm is the same plus the four tools above. The judge is Opus 5.5.
</details>
**Your mileage will vary with the model.**
- **Cheaper on every model.** Haiku 41% off the total bill, Sonnet 58%, Opus 26%, Fable 14%.
- **Quality increases on the cheaper models.** Haiku gets eight more fully correct answers with SuperGrep than without. On Sonnet, Opus and Fable the answers are level: the judge is itself a model, and graded four times the same answers came back with 19, 20, 17 and 23 claims it could not verify, so a difference under about six answers in 36 is noise, and those three are inside it.
- **No surprise bills.** On about a third of the questions, Sonnet with file tools sends a subagent off to read through the repository. That one question then costs four to five times as much and takes four times as long. With SuperGrep it asks the index instead. Over the 36 questions that is $3.66 against $8.73 and 20 minutes against 41, with 20 fully correct answers against 18.
- **On your own code the gap is wider.** These runs are on a public, open-source repository, because that is a test anyone can repeat - and the large models have seen it in training, which is a head start for reading files. On a private codebase the model has never seen, the index does more of the work, and the effect of SuperGrep is larger.
### Where it wins, and where it does not
It wins on questions about the whole codebase: counts, rankings, every occurrence. Grep gives the first forty matches; an index gives the total. It loses on finding one named thing with a large model, which reads whole files well.
### The cheapest model with SuperGrep against the most expensive without
23 correct answers to their 25, for $1.09 instead of $6.32 (Opus) or $19.36 (Fable).
## Install
Two commands, once per machine. You need Claude Code and node 22 or newer, on macOS or Linux.
```bash
claude plugin marketplace add infino-ai/supergrep
claude plugin install supergrep@infino-ai
```
(The plugin was called `code-context` before; an earlier install is replaced with `claude plugin uninstall code-context@infino-ai` and the two commands above. The MCP server inside keeps its name, so nothing the agent learned changes.)
That is the setup. Open Claude Code in any directory - a repository, a folder of logs, your notes, anything - and ask a question. The first question indexes the directory, and `find`, `sql` and `read` answer from then on. Nothing is configured per directory, no account exists yet, and nothing has left your machine.
`search` and `ask` are the cloud half - the embeddings and the retrieval loop run on the Infino platform, over a copy of the index kept there - and they need an account. The first time a question needs them, Claude tells you the one command and does not run it, because it is yours to run. Once, in a terminal:
```bash
npx -y @infino-ai/code-context login --platform https://api.supergrep.infino.ai
```
**A free account, no credit card required.** There is no form, no email, no password and no card, and nothing is created without your say-so: the command tells you that the contents of the directories you use `search` and `ask` in will be uploaded to Infino, asks, and only on your yes creates the account and stores its key at `~/.infino/key`, mode 600, readable only by you. No config file ever holds a key or a path to one. Infino is SOC 2 Type 2 certified.
**Keep that key.** Because the free account asks for no email and no card, the key is the only thing that identifies you: it is how you get back in, and nothing else can. Back it up somewhere safe. When you add your details in the Infino console the same account gains a sign-in, and keys can be managed from there.
Restart the session and every directory you open has all four tools. Each one gets its own database on your account, named after the directory and loaded the first time you use `search` or `ask` there - a directory you only ever `find` in is never uploaded. One server answers for every directory a session touches: the tools take a `path`, so a session that spans several projects names the one it means. When the free credit runs out, `ask` says so and tells you how to add billing details and a card to the same account; `find` and plain `sql` keep working throughout.
### If you already have an Infino account
Sign in once per machine instead. The key comes from a file or standard input, never from an argument - argv is readable by every process on the machine - and `--yes` is the same agreement the sign-up asks for, since a piped key leaves no terminal to ask on:
```bash
npx -y @infino-ai/code-context login --db https://api.supergrep.infino.ai --yes < keyfile
```
### Other MCP clients, and one entry per repository
Cursor, Codex CLI, Gemini CLI, Windsurf and Cline take the same server over stdio. `cx install` in a repository writes its entry into `.mcp.json` there (`--config` for another client's file); with the account stored it names the repository's database and nothing else, `--local-only` writes the keyword-only entry, and `install --platform https://api.supergrep.infino.ai` is the sign-up and the entry in one for a machine with no account. [The reference](docs/reference.md#cli) has every flag, and [CONTRIBUTING](CONTRIBUTING.md) how to build from source.
## Indexing it yourself
The first question in a directory indexes it and the MCP server keeps it current, so most of the time you never run an index by hand. When you want to - a first pass over a huge tree, a CI step, a corpus that is not a git repository - `index` is the command. (`cx` below is `npx -y @infino-ai/code-context`, or `cx` itself after `npm install -g @infino-ai/code-context`.)
```bash
cx index # bring the index up to date; incremental, full on first run
cx index ~/notes # index some other directory
cx index --full # force a full rebuild
cx index --watch # keep watching the tree and sync on every change
cx index --no-embed # keyword index only, skip the vector stage
cx index --max-files 1000000 # raise the cap past the 500,000 default; over it, the index is
# partial and says so, with the value to pass to get all of it
```
The index is plain files under `.infino/` in the directory you indexed. Keyword search is live within seconds of the first `cx index`; semantic and hybrid search light up as the vectors finish backfilling behind it. `cx status` says what the index holds and how fresh it is.
Signed in, `cx index` loads the platform copy in the same pass - the directory's own database on your account, so `ask` sees the same content as `find`. To load a database you name instead:
```bash
cx index --db https://api.supergrep.infino.ai/<database>
```
`--embed-provider platform` (the default) has the platform fill that table's vectors with its own model, server-side; `local` embeds on this machine and ships the vectors instead.
## Your data, through the same tools
The same plugin reaches every table in your Infino account, not only the directories it indexed. Signed in, the agent has three more tools and a `database` argument on the four it had:
| tool | what it does |
|---|---|
| `tables` | What the account holds: every database with its tables; a table's columns, which are indexed for search and which the platform embeds, the column that names a row, and the table's card - statistics, sample rows and what each column means. |
| `hydrate` | Load a dataset into a database of the account, from wherever it is: a bucket prefix the platform reads itself, files on your laptop, files on a machine you reach with `ssh`, or a prefix already in the database's storage. Parquet, CSV, NDJSON, Iceberg and parsed documents. The database is created if it is new; the load runs on the platform and `hydrate_status` follows it. |
| `hydrate_status`, `hydrate_cancel` | Where a load stands; stop one. |
`sql`, `search`, `find` and `ask` take `database` (and `table`) to run over a table of the account instead of a repository - the statement, the ranked search, the exact match and the retrieval loop, with the platform's verdict on a statement's rows and its keys for a join, exactly as over code. So one session asks "which files call this" of the checkout and "which accounts moved the most money last quarter" of the data, through one MCP, and a question can span both.
Nothing is configured per table or per database. Point the agent at a folder of CSVs, a Parquet export, a bucket, or a directory on a dev box, and ask it to load it; then ask questions. Files on your laptop or on a remote machine go straight into the database's storage over the platform's upload sessions (`ssh` is yours: the plugin runs one `find` and one `cat` per file over it and installs nothing there); a bucket is read in place and nothing is copied.
### As a connector, with sign-in
The same server runs over Streamable HTTP, as one URL that claude.ai, Claude Desktop, Claude Code and any other MCP client add as a remote connector:
```sh
cx mcp --http 9121 --db https://<platform> --sign-in https://<host>/.well-known/oauth-protected-resource/mcp
```
With `--sign-in`, every call carries an Infino account's key, and a call with none is told where to sign in (the OAuth resource metadata at that URL), which is how Claude knows to sign the person in. Every call then runs on that account's own databases. Without it, every session runs on the one account the process was started with (add `--read-only` for a URL shared with no sign-in).
## Indexing from object storage
For a corpus too big for your laptop - years of logs, a document dump, anything you already keep in a bucket as Parquet or JSON - leave it there, point the platform at the bucket, and it builds the index from there. Nothing is copied, nothing is downloaded to your machine, and no row passes through your laptop or through the API. The `hydrate` tool above does this from inside a session; the API it calls is below.
**1. Grant read on your bucket** to Infino's service account - we give you its address - on the prefix you want indexed: `roles/storage.objectViewer` on GCS, `s3:GetObject` + `s3:ListBucket` on S3. Read only: the platform writes nothing there.
**2. Submit the job.** One `POST`, naming the bucket and prefix, and it returns straight away - the build runs on the platform, not in the request:
```bash
curl -sS -X POST https://api.supergrep.infino.ai/v1/hydrate/<database> \
-H "authorization: Bearer $(cat ~/.infino/key)" \
-H 'content-type: application/json' \
-d '{
"table": "logs",
"source": { "kind": "bucket", "bucket": "<your-bucket>", "prefix": "exports/logs/" },
"fts": [ { "column": "message" } ],
"embed": { "column": "embedding", "source": ["message"] }
}'
```
(A database that lives in your own bucket can also read shards staged under its own `_source/` prefix: `"source": { "kind": "prefix", "prefix": "_source/logs/" }`.)
```json
{ "job": "hydrate/<customer>/<database>/logs", "state": "pending" }
```
Leave `fts` and `embed` out and the job reads a sample and picks the roles itself. `columns` narrows which source columns are carried; `no_embed: true` builds no vector column at all.
**3. Follow it.** The reply carries the state, how far it has got, the schema it settled on, and what it has cost so far:
```bash
curl -sS "https://api.supergrep.infino.ai/v1/hydrate/<database>?table=logs" \
-H "authorization: Bearer $(cat ~/.infino/key)"
```
States are `pending`, `running`, `cancelling`, `stopped`, `succeeded`, `failed`. A job that stopped - a cancel, or an outage that outlasted its budget - resumes from its own checkpoint rather than starting over:
```bash
# resume where it left off
curl -sS -X POST https://api.supergrep.infino.ai/v1/hydrate/<database> -H "authorization: Bearer $(cat ~/.infino/key)" \
-H 'content-type: application/json' \
-d '{"table":"logs","source":{"kind":"bucket","bucket":"<your-bucket>","prefix":"exports/logs/"},"resume":true}'
# stop a running job at its next commit boundary
curl -sS -X DELETE "https://api.supergrep.infino.ai/v1/hydrate/<database>?table=logs" \
-H "authorization: Bearer $(cat ~/.infino/key)"
```
By default a job that fails for good drops its half-built table, so a partial table is never served; `"on_failure": "keep"` keeps what was committed.
The table is then searchable like any other. `ask` runs over it, and one question can span it and your code at once.
Note: Hydrate API needs to be enabled per account. Contact support@infino.ai to enable.
## Learn more
- [Reference](docs/reference.md) - tools, flags, configuration, CLI, architecture.
- [FAQ](docs/faq.md), [Tradeoffs](docs/tradeoffs.md) - the honest limits.
## License
Apache-2.0
TDQS
A4.3/5.0
Scored across 3 tools
Disambiguation4/5
The three tools are clearly distinct: search for finding code, sql for analytical queries, reindex for index maintenance. There is minor overlap between search and sql since sql can also perform ranked searches, but the descriptions make the intended use cases clear.
Naming Consistency4/5
Tool names are simple lowercase verbs: search, sql, reindex. This is consistent in style, though 'sql' is a noun rather than a verb_noun pattern, and 'reindex' is a verb. Minor deviation but predictable.
Tool Count4/5
Three tools is on the lean side for a code-context server, but each tool serves a distinct and substantial purpose: search, SQL analytics, and index maintenance. The count is appropriate for a focused utility, though a get/read tool could be expected.
Completeness3/5
The server covers search, analytical querying, and index maintenance well, but lacks a direct file-read or file-content retrieval tool. Agents can work around this via search hits and sql, but a dedicated read tool would round out the surface.
Maintenance
ActivityActive
ResponsivenessUnresponsive