> For the complete documentation index, see [llms.txt](https://pharaoh.so/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pharaoh.so/docs/concepts/comparison.md). # Pharaoh vs. Alternatives > **Status:** First draft (2026-04-10) — needs Dan's hands-on validation for several entries marked `TODO`. Honest comparison page; competitor entries credit what each tool does well before describing what Pharaoh does differently. The category is **codebase intelligence for AI agents.** It's forming, fast, and nobody owns it yet. This page exists because the most common question on Pharaoh's first Reddit posts was *"how is this different from X?"* — and the right answer is a clear, honest comparison, not dodging. **Disclosure:** This page is written by Pharaoh's team. Read the Pharaoh column with the appropriate grain of salt; the competitor columns are written to be fair and would still be true even if Pharaoh didn't exist. ## TL;DR matrix | Tool | Hosted? | Multi-repo? | Cross-file reasoning? | Auto-refresh? | Skills layer? | Best when... | | ---------------------- | ---------------- | ------------------ | ------------------------------ | -------------------- | ------------- | --------------------------------------------------- | | **Pharaoh** | ✅ Hosted (cloud) | ✅ Yes | ✅ Knowledge graph | ✅ GitHub App webhook | ✅ 10 skills | You want zero-setup multi-repo intelligence | | **Serena** | ❌ Local | TODO | ✅ Semantic search | TODO | ❌ | TODO — Dan to verify | | **GitNexus** | TODO | TODO | TODO | TODO | TODO | TODO — Dan to verify | | **CodeGraphContext** | TODO | TODO | ✅ Graph-based | TODO | TODO | TODO — Dan to verify | | **Engram** | TODO | TODO | TODO | TODO | TODO | TODO — Dan to verify | | **Repomix** | ❌ Local CLI | ❌ Single repo | ❌ Concatenates files | ❌ On-demand | ❌ | You want one big prompt of your repo | | **Traycer AI** | TODO | TODO | TODO (architecture spec layer) | TODO | TODO | TODO — Dan to verify | | **LSP (built-in)** | ❌ Editor-only | ❌ Single workspace | ⚠️ Symbol-level only | ✅ Live | ❌ | You're navigating in your editor, not from an agent | | **Just use grep** | ❌ Terminal | ✅ Any | ❌ Text only | ✅ Live | ❌ | You only need string search | | **A CLAUDE.md prompt** | ❌ File | ⚠️ Manual | ❌ Static snapshot | ❌ Hand-maintained | ❌ | Your codebase is small and stable | The TODO rows above are not laziness — they're honesty. We will not write a comparison entry for a tool we haven't personally evaluated. Dan to fill in over the next session pass. *** ## When you should NOT use Pharaoh This section is here on purpose and will not be deleted. Honest "don't use this" sections build more trust than a feature list ever will. * **Your codebase is small enough** that your AI agent can hold the whole thing in context. Pharaoh is overkill — just paste the directory. * **You don't use AI agents for anything beyond autocomplete.** Pharaoh's value is invisible until you have an agent making multi-step changes that need cross-file awareness. * **You can't install a GitHub App** (corporate restriction, non-GitHub repo, etc.). Use the upload path instead, or wait for [Local Pharaoh](#local-pharaoh). * **Your security requirements forbid cloud code analysis.** Pharaoh is read-only and never stores source, but if your policy is "no third party touches the repo," wait for Local Pharaoh. * **You're a Cursor user who is happy with how Cursor's composer mode handles your codebase.** Pharaoh adds value for Claude Code, Codex CLI, and other agent surfaces; if Cursor is working for you, you probably don't need it. *** ## Detailed comparisons ### Pharaoh vs. "Just use grep" **What grep does well:** Grep is fast, free, universal, and tells you exactly which files contain a string. For string-level questions ("where is the word `validateUser` used?") it is the right answer. **What grep can't do:** * Tell you the **call graph**: which functions call `validateUser`, which functions `validateUser` calls, and what depends on it transitively * Tell you the **blast radius** of changing `validateUser`: how many other modules will need to change * Tell you whether `validateUser` is **actually reachable** from any entry point, or whether it's dead code that nobody calls * Tell you if a function with the same purpose **already exists** under a different name in another part of the codebase * Operate **across multiple repositories** in a single query **When to pick grep:** You need a string search and you're already in your terminal. **When to pick Pharaoh:** You need to reason about *relationships* between code, not just locations. Your AI agent is about to make a change and needs to know what breaks. *** ### Pharaoh vs. a `CLAUDE.md` prompt or static documentation **What a CLAUDE.md prompt does well:** Hand-written context is precise, opinionated, and reflects exactly how the human wants the AI to think about the codebase. For a small, stable codebase maintained by one person, a well-crafted CLAUDE.md is surprisingly effective. **What a CLAUDE.md prompt can't do:** * **Stay current.** The moment you refactor, the prompt is lying. Static docs go stale; the graph is queried live. * **Trace dependencies dynamically.** A prompt can describe the architecture, but it can't answer "what calls this function" without you adding that fact manually. * **Scale with codebase growth.** A 50K-token CLAUDE.md is no longer a context optimization — it's a context budget burner. * **Cover what you forgot to write down.** The graph contains *everything*, including the modules you forgot existed. **When to pick CLAUDE.md:** Your codebase is small and stable. You enjoy maintaining the doc by hand. You want to teach the AI your conventions, not just your structure. **When to pick Pharaoh:** Your codebase changes faster than you can document it. You want the AI to know the current state, not last month's snapshot. (These are not mutually exclusive. Most Pharaoh users have both — CLAUDE.md for *conventions*, Pharaoh for *current state*.) *** ### Pharaoh vs. LSP (Language Server Protocol) **What LSP does well:** LSP is the foundation of modern code navigation in editors. Go-to-definition, find-references, hover-for-type, rename-symbol — LSP is what makes those work. It runs locally, it's fast, and it understands your language deeply. **What LSP can't do:** * **Be invoked by an AI agent** that isn't running inside your editor * **Reason about the architecture** above the symbol level — modules, layers, ownership boundaries * **Cross repository boundaries** in a multi-repo workspace * **Surface emergent properties** like dead code, unreachable branches, or duplicate functionality across files * **Tell you the blast radius** of a change — LSP tells you what *references* something, not what *transitively depends on it* **When to pick LSP:** You're editing code in a real editor, by hand, and you want to navigate. You don't need an AI agent to query it. **When to pick Pharaoh:** You're driving an AI agent that needs codebase awareness *outside* of an editor. You want answers at the architecture level, not the symbol level. (Pharaoh and LSP coexist happily. LSP is symbol-level local navigation; Pharaoh is architecture-level remote reasoning.) *** ### Pharaoh vs. Repomix **What Repomix does well:** Repomix concatenates a repository into a single text file (or one big prompt) so you can paste the whole thing into an AI conversation. For small repositories or specific subdirectories, it's a clean way to get full context into one shot. **What Repomix can't do:** * **Scale to large repositories** without blowing the context window * **Update incrementally** — every run is a fresh dump * **Surface relationships** — Repomix gives you the text, not the structure * **Be queried selectively** — it's all or nothing **When to pick Repomix:** Your repo is small (under \~100 files), you want a one-shot full-context prompt, and you don't mind manually re-running it when files change. **When to pick Pharaoh:** Your repo is large enough that a full dump would exceed your model's context window. You want the agent to query *what it needs*, not receive *all of it*. *** ### Pharaoh vs. Serena > **TODO — Dan to fill in.** Serena is a semantic-search-based MCP server for codebase context. We need a fair comparison that credits what Serena does well (probably: zero-setup local install, language-model-agnostic embedding search) and describes the structural difference (Pharaoh: graph-based relational queries; Serena: vector similarity over code chunks). > > Specific points to research before writing: > > * Does Serena run locally or hosted? > * What's its multi-repo story? > * What does its install path look like? > * What's its update model — embedding refresh on push, or manual? > * Does it expose tools beyond raw semantic search? *** ### Pharaoh vs. GitNexus > **TODO — Dan to fill in.** GitNexus was named by `DragonflyHumble` in the r/mcp comment thread (`o8dhqxx`) as a comparison. We don't have direct evaluation data yet. > > Specific points to research before writing: > > * Hosted or local? > * Single-repo or multi-repo? > * What's the underlying data model — graph, embeddings, AST, something else? > * What MCP tools does it expose? > * How does it stay current? *** ### Pharaoh vs. CodeGraphContext > **TODO — Dan to fill in.** **This is the most important entry.** CodeGraphContext is the closest direct competitor and outperformed Pharaoh's launch posts on Reddit (186 + 122 points across two progress posts vs. our 55 + 3 on launch announcements). Both tools are graph-based. > > Specific points to research before writing: > > * Architecture differences in the graph model > * Setup friction comparison (hosted vs local) > * Tool surface: what does CodeGraphContext expose vs. Pharaoh's 16 MCP tools > * Multi-repo support > * Auto-refresh mechanism > * Pricing > > When written, this entry should be the most generous toward the competitor. They have shipped well; respect that explicitly. Then describe the structural choice points where we made different tradeoffs. *** ### Pharaoh vs. Engram > **TODO — Dan to fill in.** Engram was named by `Foi_Engano` in the r/mcp comment thread (`o8edurj`) — Portuguese-speaking commenter asking about Pharaoh vs Engram and CodeGraphContext. > > Specific points to research before writing: > > * Architecture > * Hosting model > * Tool surface > * Audience overlap *** ### Pharaoh vs. Traycer AI > **TODO — Dan to fill in.** Traycer was named by `nikunjverma11` in the r/mcp comment thread (`o8f7ul9`) — they described using Traycer to spec the "allowed edit surface" and architecture boundaries before letting Claude Code or Codex operate on top of it. > > Notable: this is a *different category* from Pharaoh — Traycer is architecture specification, Pharaoh is architecture *discovery*. The comparison should make this clear: they're complementary, not competitive. > > Specific points to write up: > > * How Traycer's specification layer works > * How it could compose with Pharaoh's discovery layer > * When to pick each, and when to use both *** ### Pharaoh vs. sdl-mcp > **TODO — Dan to fill in.** sdl-mcp was linked by `ShagBuddy` in the r/mcp thread (`o8htoq9`) — described as "focused on reducing input token use by 70%+." Token-efficiency-focused MCP. *** ### Pharaoh vs. dragonflymcp > **TODO — Dan to fill in.** dragonflymcp was named by `RandomMyth22` in the r/ClaudeAI thread (`o8cy19s`) — they submitted it for Claude Code plugin review. Adjacent tool, may be a partner more than a competitor. *** ## Local Pharaoh This page will be updated when **Local Pharaoh** ships. Local Pharaoh addresses the trust objection ("I don't want my code touching your servers") and the Neo4j-weight objection ("I don't want another Java service running") by providing a self-hosted single-binary execution path. When Local Pharaoh ships, the comparison matrix above gets a new column: **"Pharaoh (Local)"** with `Hosted? = ❌ Local`. The same MCP tools, the same graph model, the same workflow — running on the developer's machine instead of `mcp.pharaoh.so`. Track progress: [Vision doc — Local Pharaoh](https://github.com/Pharaoh-so/pharaoh/blob/main/docs/VISION.md#local-pharaoh) (TODO: link when section exists) *** ## How this page should evolve This page is a high-traffic destination because it answers a question every prospect asks. It must stay fresh. Rules: 1. **When a new competitor is named in a Reddit thread or user conversation, add a TODO entry** within 48 hours — even if the entry is empty. The placeholder is the commitment. 2. **When a competitor ships a major release**, update their entry within 1 week. 3. **When Pharaoh ships a major feature** that affects a comparison row, update within 1 day. 4. **Never trash a competitor.** If we can't write something positive about a tool, we don't write the entry — we leave it as TODO and ask Dan. 5. **Every entry must end with "When to pick X" and "When to pick Pharaoh"** — both must be honest. If there's no scenario where we'd recommend the competitor, we haven't found their use case yet and we're not done researching. *** **See also:** * [How Pharaoh Works](/docs/concepts/how-it-works.md) * [Security](/docs/concepts/security.md) * [Tools Overview](/docs/tools-reference/overview.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://pharaoh.so/docs/concepts/comparison.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.