# cased/kit: a Python codebase context toolkit that outgrew its own release cadence

> kit is an MIT licensed Python toolkit for mapping repositories, extracting symbols, searching code and preparing context for language models, with a CLI, an MCP server and a Claude Code plugin on top. The interesting part for a new user is not the feature list but the gap between its last release in January and its last commit in March.

**cased/kit** — The toolkit for AI devtools context engineering. Build with codebase mapping, symbol extraction, and many kinds of code search.

- Repository: https://github.com/cased/kit
- Website: https://kit.cased.com
- Stars: 1,310 · Forks: 85
- Language: Python
- License: MIT
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/cased-kit

## The core abstraction is Repository, and it takes a URL or a path

The entry point is a single class that hides whether your code is on disk or on GitHub:

```python
from kit import Repository

repo = Repository("/path/to/your/local/codebase")
repo = Repository("https://github.com/owner/repo")
```

Private repositories are handled by an environment variable, a GitHub token named `KIT_GITHUB_TOKEN`, which is picked up automatically, with an explicit keyword argument available when you would rather not rely on ambient state. A `ref` argument pins the load to a commit, tag or branch, which is the detail that matters most in practice, since a code context tool that silently re-resolves to a moving branch will produce different answers to the same question on different days.

The read surface is small and flat. A file tree listing returns path and directory flags, symbol extraction returns names with types and file locations, git metadata exposes the current SHA and branch, and file content can be fetched one path at a time or as a list in a single round trip. That last method is the one to notice, because the cost model of any agent built on top of this is the number of round trips, and the multi-path form exists specifically to reduce it.

For codebases that are not one repository, a `MultiRepo` class takes a list of local paths and exposes the same search operation across all of them. The documented use is the obvious trio of frontend, backend and shared directories, and the reason to care is that a symbol defined in the shared directory and used in the backend is exactly the cross-boundary question a single-repository tool answers badly.

## Two search strategies, one deliberately not a parser

Text search and structural search are separate operations, and the project is clear that the first is not the second. `repo.search_text()` runs regular expressions, and it delegates to ripgrep automatically when that binary is available, which the documentation describes as roughly a tenfold speedup. The fallback is a pure Python path, which is the reason to install ripgrep rather than assume it.

Structural search works on the parse tree instead. The toolkit is built on tree-sitter with the language pack, and the documented capability is finding code by shape: async functions, try blocks, class inheritance. `repo.find_symbol_usages()` covers the third case, tracking where a named function or class is referenced. Combined, the three answer the three questions a code reviewer actually asks, and they fail differently. A regular expression misses a renamed identifier, an AST query catches it, and a symbol usage search catches it without you knowing what to search for.

Incremental extraction is the performance feature aimed at iteration. `repo.extract_symbols_incremental()` is described as cache-aware and intended for repositories with small changes, which is the situation an editor plugin or a pre-commit hook lives in. Parsing a large tree on every keystroke is the failure mode that makes tools like this unusable, and a cache is the difference between a demo and something you leave running.

For LLM consumption there is a fourth group: chunking a large file by lines or by symbols so it fits a context window, and pulling the full definition of a function or class when you have only a line number inside it. The second one is quietly the most useful primitive here, because it is what turns a search hit into something a model can actually reason about rather than a fragment it has to guess the rest of.

## The CLI covers review, commit messages and PR bodies

Most of the tool's surface is a Typer application exposed as `kit`, and the command set extends well past code search into workflow automation.

```bash
kit file-tree /path/to/repo
kit symbols /path/to/repo --format table
kit search /path/to/repo "def main" --pattern "*.py"
kit usages /path/to/repo "MyClass"
kit export /path/to/repo symbols symbols.json
```

The export subcommand is the escape hatch. Dumping symbols to JSON hands the index to whatever you want to build next, which turns the CLI from a tool into a data source. Given that the project already ships a benchmarks directory, that division of labour between extraction and consumption is clearly deliberate.

The review commands are where the project makes a claim beyond analysis. Configuration is created once with `kit review --init-config`, and then a review can run against a GitHub pull request URL, with a dry-run flag available first. More interesting is the local diff syntax: two branch names, a commit range, or the staged area. Reviewing your own uncommitted work without opening a pull request removes the main practical objection to automated review, which is that you would have to push code you have not read yet in order to get feedback on it.

The same pattern appears twice more. `kit summarize` generates a PR description for triage, and `kit commit` reads the staged changes and writes a commit message, which means the tool has to be pointed at a staged diff rather than the working tree, a small design decision that keeps generated messages honest about what is actually being committed. A separate package search command family covers searching inside installed packages, in plain grep output, structured JSON, a hybrid mode, or a read of a specific file, and it is the one part of the CLI that needs an external Chroma key.

## Three integration surfaces for the same capabilities

The toolkit can be driven four ways, and the documentation is explicit that they are equivalent. Python is the library, MCP exposes it to an agent, function calling and REST reach it from a service, and the CLI is for a person at a terminal.

The MCP path has a wrinkle worth understanding. Two commands are installed: `kit` and `kit-dev-mcp`. The second one is a local development MCP server, and the project maintains a hosted instance of it for documentation purposes, so you can point an agent at the hosted endpoint to explore the API before running anything locally. That is a genuinely useful onboarding pattern, and it also means the documented default path for a new user is not necessarily the one you want in production, since a hosted server sees whatever repository you point it at.

The Claude Code plugin is the other end user surface. It is installed through the plugin marketplace, and its purpose is described as giving Claude autonomous access to the analysis tools, so the model decides when to call them. The example questions in the documentation are ordinary codebase questions, which is the point: the plugin is a way of routing questions to a deterministic index rather than to the model's own scanning.

```bash
/plugin marketplace add cased/claude-code-plugins
/plugin install kit-cli
```

Looking at the dependency list explains a lot about the shape of the project. Three model providers are installed side by side, one from each major vendor, alongside a tokenizer library, an MCP client, a web framework with an ASGI server, a Redis client, and an HCL parser. The HCL parser is the outlier and the interesting one: infrastructure code is not Python, and a toolkit for codebase context that can read Terraform is making a claim about what counts as code worth understanding. Redis sits there for cache and rate limiting, which supports the incremental extraction story from the previous section.

## Version 3.5.1 in January, last commit in March

The maintenance picture is the part a new user should weigh most heavily, and it is not ambiguous once the dates are laid out. Three releases are recorded, all within a two-week window in early 2026: 3.4.0 and 3.5.0 on 2026-01-07, and 3.5.1 on 2026-01-18. The last push to the default branch is dated 2026-03-03. The repository is not archived.

So as of late September 2026 there is a gap of roughly two months between the last commit and the last release, and closer to eight months between the last release and today. Nothing in the repository explains the gap, and the project status is not a topic its README addresses. The correct reading is not that the project is finished, since the structure of the repository, with a benchmarks directory, a scripts directory and a populated test suite, looks like working software rather than an archive. It is that nobody has tagged or committed in a while, and for a library other teams pin in their dependency files, an unexplained six-month silence is a fact to plan around rather than a judgement to make.

There is a practical mitigation. The package is a normal Python distribution on PyPI with a conventional dependency list and a supported floor of Python 3.10, so pinning `cased-kit` to the exact version you tested removes the risk of a surprise upgrade. What you lose by doing that is any fix published after your pin, and on the current dates there has not been one for some time. For an internal tool that is an acceptable trade. For a dependency on a critical path it is worth a conversation with whoever owns the build before you commit to it.

## Conclusion

kit is worth evaluating if you are building a code reviewer, an agent or a review bot and want repository understanding you can call from Python without adopting a hosted service, and if ripgrep and tree-sitter are already acceptable dependencies in your environment. It is a poor fit for a team that needs a maintained dependency with a predictable release stream, since the last tagged version is 3.5.1 from January 2026 and the last commit to the default branch is dated 2026-03-03, which is nearly seven months of silence as of late September. Before adopting it, run the CLI against a repository you already understand and compare its file tree and symbol output with your ground truth, because the value of the whole toolkit rests on the parse quality of tree-sitter grammars, and no documentation here measures that for your languages.

## FAQ

### How do I install cased/kit and what are the two commands it provides?

Install it from PyPI with uv pip install cased-kit, or use uv tool install for an isolated global CLI. The base install provides the kit CLI, and the full extra named all also provides the kit-dev-mcp server along with the machine learning and vector search extras.

### What is the difference between search_text and AST based search in kit?

search_text runs regular expressions and automatically uses ripgrep when it is available for a large speedup. The AST based matching finds code by structure, such as async functions, try blocks or class inheritance, and neither approach replaces the other.

### Can kit review code that has not been pushed to a pull request?

Yes. Besides a pull request URL with an optional dry run, the review command accepts a branch range such as main..feature, a commit range such as HEAD~3..HEAD, or the staged flag for changes not yet committed.

### How does kit handle private GitHub repositories?

Passing a private repository URL works if a token is available in the environment under the name KIT_GITHUB_TOKEN, and a token can also be supplied explicitly as a keyword argument. A ref argument can pin the load to a specific commit, tag or branch.

## Sources

- [cased/kit on GitHub](https://github.com/cased/kit)
- [License: MIT](https://github.com/cased/kit/blob/main/LICENSE)
- [Project website](https://kit.cased.com)
- [README](https://github.com/cased/kit/blob/main/README.md)
- [Releases](https://github.com/cased/kit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cased-kit