Code Context

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 - 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: find and plain sql on your machine, search, semantic sql and ask in the Infino cloud, one index in both places]

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.

[Search functions live inside SQL, so one statement asks a whole question]

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

[Offered both, the model reaches for SuperGrep]

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:

[LogDx-CI: diagnosis score, context handed to the model, and score per 1k tokens, by method]

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). 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.

[The same model with file tools and with SuperGrep, on four Claude models: bill, fully correct answers, time]

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

[Fully correct answers by kind of question, all four models together]

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

[Haiku with SuperGrep against Opus and Fable with file tools: bill, fully correct answers, time]

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.

claude plugin marketplace add infino-ai/supergrepclaude 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:

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:

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 has every flag, and CONTRIBUTING 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.)

cx index                      # bring the index up to date; incremental, full on first runcx index ~/notes              # index some other directorycx index --full               # force a full rebuildcx index --watch              # keep watching the tree and sync on every changecx index --no-embed           # keyword index only, skip the vector stagecx 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:

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:

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:

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:

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/" }.)

{ "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:

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:

# resume where it left offcurl -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 boundarycurl -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 [email protected] to enable.

Learn more

• Reference - tools, flags, configuration, CLI, architecture.
• FAQ, Tradeoffs - the honest limits.

License

Apache-2.0