Features
cix gives your AI assistant a set of tools for reading your codebase by structure rather than by guesswork. This section covers what those tools do and when each one earns its place.
You don't call these yourself. Your assistant picks them while it works — the value of knowing them is recognising when it should have reached for one, and asking for it by name.
The tool groups
| Group | Answers | Pages |
|---|---|---|
| Orientation | What is this project, and what changed? | Project shape, routes, schema, health |
| Search and lookup | Where does this live, and what does it say? | Symbols, text, files, line ranges |
| Tracing and impact | What else does this touch? | Callers, data flow, blast radius |
| Validation and writing | Is this right, and can it be changed safely? | Conventions, audits, structural edits |
| Collaborators | Is this repo already covered by someone else? | Reading an owner's index |
| Branches and worktrees | Does this answer match the branch I'm on? | Per-branch index, worktrees, uncommitted work |
Two of these are less common elsewhere and worth knowing about: cix is anchored to git, so answers are scoped to the branch you're on and worktrees stay separate — and a repository someone else already indexed may need no work from you at all.
The other half: workflows
The groups above are what your assistant can look up. They answer questions about your code, one question at a time.
Workflows are the other half — how a piece of work gets run. A perfect index does not stop a long agent session from drifting off the task, or from declaring something finished without evidence. Those are failures of process, not of lookup, and no amount of retrieval fixes them.
| Workflow | Answers |
|---|---|
| The loop | How does this task get executed without drifting or ending in an unverified "done"? |
| Research | What did we establish, and how do we know? |
| Design | What should be built, and what has to stay true? |
| Plans | In what order, and what is actually finished? |
| Tidy | What state is this repository really in? |
Research, designs, and plans are stored with your cix account and are part of a paid plan. See Workflows for how they fit together and what each one needs.
Why structure beats reading files
An assistant without an index answers by opening files it guesses are relevant. That works until the codebase outgrows what fits in a context window, at which point the guesses quietly get worse — and a confident answer built on three of the eight relevant files reads exactly like a correct one.
An index changes the question from "which files should I open" to "where is this symbol defined, who calls it, and what breaks if it changes." Those have exact answers.
What this means in practice
- Before writing something new, your assistant can check whether it already exists rather than adding a second implementation.
- Before changing something, it can list the callers instead of hoping there aren't any.
- Before creating a file, it can check where that kind of file belongs in your project.
- After time away, it can summarise what changed structurally rather than replaying the commit log.
What your plan includes
Most of this works on the free tier: searching symbols, reading a symbol or a line range, listing files, reading your schema, checking conventions, finding callers, and the structural edit tools.
Twelve capabilities are grouped onto the paid plans, and pages below mark them where they appear:
| Plan | What it adds | Capabilities |
|---|---|---|
| Individual | Change code safely | Impact analysis, counterfactual, file dependencies |
| Pro | Stay up to date | Catch-up briefing, vital sign, pre-commit impact, last diff |
| Max | Analyze and transform architecture | Convention audit, stale symbols, rename detection, data flow, bulk rename |
Each plan includes everything below it. See pricing for the full comparison.
Note — your assistant is only offered the capabilities your plan covers, so a gated tool is absent rather than failing when called.