Short answer
graphify builds a knowledge graph of code and of everything around it: docs, SQL schemas, PDFs, images, video. Code is parsed with tree-sitter and no LLM; docs, PDFs and images go through a model, and video is transcribed locally before it does. Pixel stays on code and Git: callers, blast radius, task scope, history search and guarded Git writes, in one binary.
Side by side
Not benchmarked. No figure: how Pixel and graphify work, side by side. Nothing on this page is a measurement.
| Measure | Pixel | graphify |
|---|---|---|
| Reads docs, PDFs, media | No, code only | Yes: a model, after local transcription for video |
| Graph view | No | Interactive HTML |
| Blast radius before an edit | Yes, pixel impact | Paths between two nodes, PR impact |
| Git history | Search and archaeology, guarded writes | Rebuilds on commit |
Where graphify wins
Non-code inputs (docs, PDFs, media, database schemas), community clustering and an interactive graph view.
How they differ
graphify parses code with tree-sitter into a graph written to local files, clusters it into communities, and adds docs, SQL schemas, PDFs and images through a model; video and audio are first transcribed locally with faster-whisper, and the transcripts then go through the same model. An agent reaches it through a /graphify skill, a CLI, hooks or an optional MCP server. Pixel indexes code only, and answers the questions an edit raises: pixel impact before it, pixel scope-task to find the files, pixel dig-history for why the code is the way it is, pixel commit to land it.
Choosing
Use graphify when the answer lives outside the code too (a design doc, a schema, a PDF) or when you want to see the project as a graph. Use Pixel for the code-and-Git loop of an agent’s edit. The two hook into the same agents, so they can run side by side.