Overview

cix is project-context infrastructure for AI coding assistants.

It runs alongside Claude Code, Codex, or Gemini CLI and gives those tools something they otherwise lack: a precise, up-to-date understanding of the codebase they are working in. Every function and class. Every route. Every table column. Every import edge.

The result is an assistant that behaves less like a confident outsider and more like a careful contributor who has read the codebase.

Measured impact

In a side-by-side cleanup pass on a real Laravel + Vue project (300 indexed files, mid-rename), cix produced:

~50% fewer tool calls than a less-capable indexer (29 vs. ~55).
~60–70% fewer tokens for the same task (30–40k vs. 80–100k).
Three additional structural findings the baseline missed, including a hardcoded MySQL root credential in a Laravel public/ directory.

The full side-by-side is in the cleanup case study. The 25-repo benchmark covers a wider sample: standard backend stacks score 13–15 out of 15, large monorepos score 10–13, and the system is honest about where its parsers don't reach yet.

What problem does it solve?

AI coding assistants come with strong general knowledge and zero specific knowledge. They know how Django works. They do not know how your Django app is organized. They know how to write a SQLAlchemy model. They do not know what columns the orders table already has.

This gap shows up in predictable ways:

Duplicated work. Helpers that already exist get rewritten under new names.
Convention drift. New files land in the wrong folder, named the wrong way, in the wrong language.
Fabricated details. Column names, function signatures, and route paths get invented from training data instead of looked up.
Wasted reads. The assistant burns ten file reads to answer a question one targeted query could have answered.

These are not failures of intelligence. They are failures of context. cix closes that context gap.

How does it close it?

By turning the codebase into a queryable index, then giving the assistant a small, focused set of tools to query that index.

The assistant can ask:

"Does a function for X already exist?" before writing one.
"What columns does the users table have?" before writing a query.
"Who calls this function?" before changing it.
"Where does this route get registered?" instead of grepping the whole project.
"Is this file path allowed?" before creating a file the team would have to clean up later.

Each of those questions gets a fast, structured answer grounded in the actual code on disk — not training data, not a stale snapshot, not a hallucination.

What makes it different from search?

A grep finds strings. cix finds symbols. It knows the difference between the function format_date, a variable named date, and a comment that mentions date. It knows which routes belong to which framework. It knows which tables came from which migration. It treats your project like the structured artifact it actually is, not a pile of text files.

It also enforces. Where the underlying client supports it, cix's convention layer can block writes that violate project rules — not warn, not log, block. The assistant cannot quietly drop a file in the wrong folder, because the file system never accepts the write.

What does it not try to do?

cix is honest about its scope.

It does not replace your judgment about whether an abstraction should exist, whether two helpers are conceptually the same, or whether a particular pattern is the right one for your team. It enforces structure. It does not enforce wisdom.

It also does not invent data when it doesn't have it. If a file is in a language the system can't parse, you'll see "no parser available" instead of a fabricated answer. That honesty is intentional.

Who is it for?

Engineering teams who want their AI assistant to behave consistently across people, sessions, and machines. (Read more)
Solo developers who want the assistant to stop duplicating their own helpers and dropping files in the wrong place. (Read more)
Technical evaluators comparing AI tooling for adoption. (Read more)

Where it shines

In benchmarking across 25 real-world open source projects spanning Python, TypeScript, Go, Java, C#, and PHP, cix scored 13–15 out of 15 on standard backend codebases — Flask, FastAPI, Django, Spring Boot, ASP.NET Core, Laravel — and 13/15 on Apache Airflow, a multi-million-line monorepo. (See the full benchmark)

It struggles on languages without a current parser (notably Lua), and on codebases that register routes dynamically at runtime rather than statically. The Limitations page lays out exactly where it falls short.

Where to go next

Why cix — the problem in detail.
How it works — the architecture in plain language.
Features — the full feature surface.
Comparison — cix vs grep, LSP, RAG, and doing nothing.
Limitations — where it falls short, in our own words.