Repository → Language Adapter → Graph (IR) → your code

Nodes and directed relations, typed and deterministic: functions, classes, modules, the calls between them, and the HTTP or gRPC boundaries where one service meets another.

Why

Code analysis usually asks you to assemble it — install a language server, put it on PATH, wire up the transport, keep the versions in step. callix links the analysis engines into the module instead:

Python and TypeScript need nothing beyond the wheel — the checkers and their standard-library stubs are inside it. Go and Rust use the toolchain the project already has, because a standard library shipped as sources cannot be frozen into a wheel. PHP and the C family have no checker worth linking and no widely installed indexer worth shelling out to — every precise C/C++ option requires a compile_commands.json, which almost no repository ships — so callix builds a symbol table from the sources and reports degraded, honest about being a symbol table and not a type checker.

Installation

pip install callix

Python ≥ 3.10. Wheels for Linux glibc and musl (x86_64, aarch64) and macOS (arm64, x86_64); Windows is not supported.

Usage

from callix import NodeKind, PythonAdapter

graph = PythonAdapter().analyze("path/to/project")

print(len(graph.nodes), len(graph.relations))
for node in graph.nodes_by_kind(NodeKind.FUNCTION):
    print(node.qualified_name, graph.callers(node.id))

graph.to_json(indent=2)          # serialization
old.diff(new)                    # structural diff

The same call works for every other language — TypeScriptAdapter, GoAdapter, RustAdapter, PhpAdapter, CAdapter, CppAdapter, YamlAdapter — and each discovers its own project roots, so a monorepo works without configuration.

Symbol resolution is on by default. resolve=False gives a structural graph. graph.metadata["resolver_status"] says whether the backend came up (ok), is a table of names rather than a type checker (degraded), or did not run (unavailable) — not how many calls it found. Each edge records how it was found in metadata["resolution"] (definition, value, flow, external, unlocated, name), callix report -t status counts them, and how accurate resolution is says what each language follows and what it does not, with measured numbers.

A Python server declaring @app.get("/users/{id}") and a TypeScript client calling fetch("/users/1") produce the same boundary node, so merging their graphs links the two services. See Cross-language analysis.

Command line and Docker

The same analysis without writing Python — and the formats other tools read:

docker run --rm -v "$PWD:/workspace" ghcr.io/callix-tools/callix:full \
  export . -f lsif -o dump.lsif        # GitLab code navigation, Sourcegraph-style tools

callix export also writes SCIP, CycloneDX, CSV, Graphviz and Mermaid; callix report prints summaries, resolver status, dependencies, boundaries and call lists. The full image carries the Go and Rust toolchains, so every language that has a real resolver gets it. See Command line, Export formats and Docker.

Documentation

https://callix-tools.github.io/callix/

• Installation · Quick start · Concepts
• Adapters and how the resolvers work
• Graph model · API reference
• Migrating from graphlens

Benchmarks

Last run: 2026-07-30 12:01 UTC · callix main · runner Linux x86_64 · single cold run, indicative only.

_{Peak RSS measured via getrusage.max (largest single process — ours or a resolver subprocess; no cgroup counter was readable, so this is not the tree total). KLOC/s = analysed thousands-of-lines per second. Answered = the share of use-sites the backend returned a place for - not a measure of correctness; see how accurate resolution is in the docs. Generated by benchmarks/run_benchmarks.py.}

Speed-ups against graphlens, the Python implementation this replaces: 5.2× on apache/superset, 3.3× on colinhacks/zod, 2.6× on gin-gonic/gin. Details and method in Benchmarks.

Versioning

Semver covers the graph contract — the node and relation kinds, the two id formulas, 1-based spans, node ordering, the serialization format — and the Python API as generated into the committed .pyi. It does not cover what the resolvers answer: the Python one is a pinned 0.0.x release of ty, the Rust one is whatever rust-analyzer the machine has. A patch release may change which CALLS edges appear. What is watched instead is what the resolvers get right on the accuracy suites (tests/accuracy, a floor CI enforces) and the aggregate share of queries the backend answered, recorded per project in the baselines.

Full statement, including which changes need a major release: Versioning.

Contributing

See CONTRIBUTING.md for the development loop, the build constraints, and how releases are cut.

License

MIT