Understanding a large codebase is hard. You clone it, start reading files, and quickly lose track of how everything connects. Which modules are most depended on? Where are the circular dependencies? What would break if you refactored this file?
Orbis answers these questions visually. Paste a GitHub repository URL, and Orbis clones it, parses the ASTs across Python, JavaScript, TypeScript, Go, Rust, and Java, detects architectural patterns, and renders the entire codebase as a navigable 3D force-directed graph. Click any module to inspect its dependencies, metrics, and exported symbols. Ask the built-in AI assistant questions like "which module should I refactor first?" and get answers grounded in the actual code structure.
Features
3D force-directed graph - Nodes sized by lines of code, colored by type, with animated directional particles on edges.
Multi-language AST parsing - Python, JavaScript/TypeScript, Go, Rust, and Java via tree-sitter.
AI chat assistant - Ask Claude questions about the analyzed codebase. Questions like "Which modules have circular dependencies?" or "Where should I add feature X?" are answered with full architectural context.
Architectural insights - Auto-detected issues including god modules, high coupling, and circular dependencies, each with severity ratings.
Focus Mode - Dim unconnected nodes to trace dependency paths clearly.
Shareable URLs - ?repo=https://github.com/... auto-triggers analysis on load, making it easy to share a specific codebase view.
Recent history - Last 5 repos stored locally for quick re-analysis.
Demo mode — Load a pre-analyzed snapshot without a GitHub clone.
Tech Stack
- Backend: FastAPI + Server-Sent Events (SSE)
- AST Parsing: tree-sitter (Python, JS/TS, Go, Rust, Java)
- AI Integration: Claude Opus 4.6 via Anthropic API
- 3D Rendering: 3d-force-graph + Three.js
- Frontend: Vanilla JS SPA - no build step
Quick Start
1. Clone and install
cd orbis
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -r requirements.txt
2. Set up environment
cp .env.example .env
# Edit .env and add your ANTHROPIC_API_KEY for the AI chat feature
Get an API key at console.anthropic.com. The AI chat feature requires ANTHROPIC_API_KEY in your environment. It degrades gracefully, if the key is missing, the chat panel shows an error message rather than breaking the rest of the app.
3. Run
uvicorn main:app --host 0.0.0.0 --port 8001
Open http://localhost:8001.
Docker
docker build -t orbis .
docker run -p 8001:8001 -e ANTHROPIC_API_KEY=sk-ant-... orbis
Usage
Once running, the workflow is straightforward:
- Enter a public GitHub repository URL - for example
https://github.com/expressjs/express - Optionally specify a branch
- Click Analyze - Orbis clones the repo, parses ASTs, and builds the graph in roughly 5–30 seconds
- Explore the 3D graph - click a node to open its detail drawer, scroll to zoom, drag to rotate
- Use Focus Mode to highlight a node's direct connections
- Use layer filter chips to show or hide architectural layers
- Ask the AI assistant questions about the codebase in the chat panel
Keyboard Shortcuts
- R: Reset camera
- P: Pause/resume rotation
- F: Toggle Focus Mode
- /: Focus search box
- Esc: Close detail drawer / exit Focus Mode
Architecture
The project has four files at its core - a FastAPI backend, a single-file AST parser, and a vanilla JS frontend with no build step:
main.py FastAPI backend — SSE streaming for /analyze, /chat
neo_parser.py Multi-language AST parser (tree-sitter)
static/
index.html Single-page frontend (3d-force-graph + Three.js)
save_analysis.py Utility: pre-generate demo data from a repo
The backend streams analysis progress to the frontend via Server-Sent Events, The backend streams analysis progress to the frontend via Server-Sent Events while cloning and analyzing the repo.
API Endpoints
Output Schema
/analyze emits SSE events and completes with a complete event containing:
{
"schema_version": "2.0",
"architecture_type": "MVC",
"languages": { "python": 42 },
"summary": "Codebase contains 42 modules...",
"nodes": [{
"id": "requests/auth",
"label": "auth.py",
"type": "utility",
"language": "python",
"lines_of_code": 315,
"complexity": "medium",
"exported_symbols": ["AuthBase", "HTTPBasicAuth"],
"internal_dependencies": ["requests/compat"],
"external_dependencies": [],
"metrics": { "functions_total": 12, "classes": 4 }
}],
"edges": [{ "from": "requests/api", "to": "requests/auth", "type": "import" }],
"insights": [{
"type": "high_coupling",
"severity": "high",
"title": "High fan-in on requests/models",
"description": "14 modules import this file directly.",
"affected_nodes": ["requests/models"],
"recommendation": "Consider splitting into smaller focused modules."
}]
}
Each node carries its lines of code, complexity rating, exported symbols, and both internal and external dependencies. The insights block surfaces architectural issues automatically, high coupling, circular dependencies, and god modules - each with a severity rating and a specific recommendation.
Supported Languages
- Python -
.py - JavaScript/TypeScript -
.js,.mjs,.cjs,.jsx,.ts,.tsx - Go -
.go - Rust -
.rs - Java -
.java
AI Chat
The chat assistant uses Claude Opus 4.6 and receives the full architectural graph as context - node list, dependencies, insights, and summary. It can answer questions like:
- "What does the auth module depend on?"
- "Why are there circular dependencies between X and Y?"
- "Which module should I refactor first?"
- "Where would I add a caching layer?"
The assistant's answers are grounded in the actual parsed structure of the codebase - not generic advice. Requires ANTHROPIC_API_KEY in your environment.
Development
# Run with auto-reload
uvicorn main:app --reload --port 8001
# Re-generate demo data
python save_analysis.py
How I Built This Using NEO
This project was built using NEO. NEO is a fully autonomous AI engineering agent that can write code and build solutions for AI/ML tasks including AI model evals, prompt optimization and end to end AI pipeline development.
The idea was a tool that turns any GitHub repository into an interactive 3D graph, something a developer could paste a URL into and immediately understand the architecture without reading a single file. The requirements included multi-language AST parsing, automatic architectural issue detection, an AI assistant grounded in the actual code structure, and a frontend that required no build step.
NEO built the full stack from that description: the FastAPI backend with SSE streaming for real-time analysis progress, the multi-language AST parser in neo_parser.py covering Python, JavaScript, TypeScript, Go, Rust, and Java via tree-sitter, the 3D force-directed graph frontend in vanilla JS, the Claude Opus 4.6 chat assistant with full architectural context, the insights engine detecting god modules, high coupling, and circular dependencies with severity ratings, and the demo mode with pre-generated analysis data.
How You Can Use and Extend This With NEO
Use it to onboard onto an unfamiliar codebase.
Instead of spending hours reading files to understand how a project is structured, paste the repo URL into Orbis and get an immediate visual map of every module, its dependencies, and the architectural issues that already exist. The AI assistant can then answer specific questions about the structure without you having to trace imports manually.
Use it during code review to understand structural impact.
When reviewing a large pull request, run Orbis on the repo and use the insights panel to see whether high coupling, circular dependencies, or god modules exist in the areas being changed. The AI assistant can answer specific questions about how the affected modules connect to the rest of the codebase.
Use it to plan a refactor.
Ask the AI assistant "which module should I refactor first?" or "where would I add a caching layer?" and get answers grounded in the actual dependency graph. The focus mode lets you isolate a specific module and trace exactly what depends on it before touching anything.
Extend it with additional language parsers.
neo_parser.py already handles five languages via tree-sitter. Adding a new language - Ruby, C++, Swift - follows the same parser pattern and surfaces automatically in the language filter chips and the supported languages list without touching the frontend or the API.
Final Notes
Orbis makes codebase architecture something you can see and navigate rather than something you have to reconstruct in your head. A 3D dependency graph, multi-language AST parsing, automatic architectural issue detection, and an AI assistant that knows the actual structure - all from a single repo URL.
The code is at https://github.com/dakshjain-1616/Orbit-dependency-visualised
You can also build with NEO in your IDE using the VS Code extension or Cursor.
You can use NEO MCP with Claude Code: https://heyneo.com/claude-code
Top comments (3)
This is really cool. I've always wanted a way to quickly grok the shape of an unfamiliar repo without cloning it and grepping through imports.
The tree-sitter multi-language support is the right call most code visualization tools I've tried lock you into one language, which falls apart the moment you hit a polyglot repo.
A few questions:
How does it handle monorepos with nested packages?
Like a Next.js app with a
packages/dir Does it treat each package as a separate cluster or flatten everything into one graph?Also curious about scale what happens with a really large repo (say, VS Code or the Linux kernel)? Does the 3D graph become unreadable past a certain node count, or is there some filtering/zoom level that keeps it usable?
The AI assistant with architectural context is a nice touch. "Which module should I refactor first?" with actual dependency data behind the answer is way more useful than generic advice.
One idea: an option to export the dependency graph as a Mermaid or DOT file would be great for people who want to embed it in docs or PR descriptions without running the full 3D viewer.
Really nice work. Definitely trying this on my next onboarding. 🔥👍️
Monorepos / nested packages: Right now Orbis doesn't have explicit monorepo awareness, it treats the whole repo as a flat namespace and the packages/ dirs just become part of the path-based node IDs. So a Next.js monorepo with packages/ui, packages/api etc. gets flattened into one graph. The node IDs do preserve directory prefixes, so you can visually spot clusters if the layout is clean, but there's no automatic "treat each package as its own sub-graph" logic yet. That's actually the next thing I want to add - workspace detection (reading pnpm-workspace.yaml, lerna.json, top-level package.json workspaces field) and rendering each package as a distinct cluster with inter-package edges highlighted differently.
Scale / large repos: VS Code or Linux kernel would absolutely crater the 3D viewer in its current state, the force simulation runs client-side with no node cap. Realistically past ~300-400 nodes it starts getting noisy, and beyond ~800 it's more art than utility. The layer filter chips help (you can hide entire architectural layers), but that's a band-aid. The right fix is progressive loading, start at directory/package granularity, let you drill into a subtree, never render the full graph at once. On the radar but not built yet.
Mermaid/DOT export: Love this idea and it's genuinely easy to add since the analysis output is already a clean JSON graph (nodes + edges). A DOT export is basically a two-liner over the existing schema.
Nice work!