Retrieval, and why it is a different mechanism
Most assistants build context from what is in front of you: the open file, nearby tabs, perhaps a per-project index. Copilot reads open tabs; Cursor indexes the current repository.
Cody retrieves across every repository Sourcegraph has indexed. Ask how authentication works and it can pull the actual implementation from a service you have never opened, in a repository you may not know exists, in a language you do not write.
For an organisation with one large monolith the difference from Cursor is modest. For one with four hundred services, it is the difference between an answer and a guess — and no amount of per-project indexing reaches it.
The prerequisite that decides everything
Cody needs a Sourcegraph instance with your repositories indexed. That is not a setting; it is infrastructure.
Either a Sourcegraph cloud deployment or a self-hosted instance, connected to your code hosts, kept indexing as repositories change, and maintained. For organisations that already run Sourcegraph, Cody is an addition. For those that do not, adopting Cody means adopting Sourcegraph — a considerably larger decision involving procurement, infrastructure and someone to own it.
This single fact explains most of the tool’s positioning. It is why it is enterprise-shaped, why it is not evaluated casually, and why comparing it feature-by-feature against Copilot misses the point.
Index freshness, and the failure mode nobody warns about
A retrieval-based assistant is only as accurate as its index.
When repositories change faster than indexing keeps up — after a large merge, a refactor, or on an actively developed service — Cody will answer confidently about code that no longer exists. The answer is well-formed, cites a real file path, and is wrong.
That failure is harder to catch than a model simply not knowing, because everything about the response signals authority. Whoever owns the deployment should understand indexing latency, and developers should treat answers about very recently changed code with more suspicion than answers about stable code.
What it does day to day
Completion, chat, and structured commands — explain this, generate tests, write documentation, find usages — inside VS Code, JetBrains IDEs or a web interface.
It supports several underlying models, so an organisation is not locked to one provider and enterprise deployments can route to a model of their choosing. That flexibility is unusual and matters for organisations with an existing position on which AI vendors they will use.
Sourcegraph has also built batch and agentic capabilities on the same foundation, for changes applied consistently across many repositories — which is a genuinely hard problem that editor-scoped tools cannot address at all.
Availability, which changed during 2025
Sourcegraph moved Cody away from standalone individual plans toward enterprise during 2025. Descriptions of a free personal tier are likely out of date, and a great deal of published comparison writing predates the change.
Check Sourcegraph’s own pricing before planning around individual access. If it no longer exists, the practical position is that Cody is an option for organisations and not for individuals — which changes who should be reading about it at all.
Self-hosting, and what it does and does not cover
Self-hosting is available, which puts Cody in the small group — with Tabnine — that can keep both code and index inside your own infrastructure.
The model itself may still be a hosted API depending on configuration, so “self-hosted Sourcegraph” and “no code leaves the network” are not automatically the same claim. Establish which components are internal and which call out, because that is the question a security review will ask and the answer depends on deployment choices rather than on the product.
What must already be in place
- A supported editor: VS Code, JetBrains IDEs, and a web interface.
- A Sourcegraph instance — cloud or self-hosted — with repositories indexed.
- An enterprise agreement, given the 2025 shift.
- For self-hosting, capacity to run and maintain indexing infrastructure at your repository scale.
Who it is genuinely for
Large engineering organisations — hundreds of repositories, long-lived services, and the specific problem that no individual understands the whole system.
Onboarding especially. A new engineer asking “where does this happen and why” gets an answer from the actual code rather than from documentation that stopped being true two years ago. That is the use case where the value is least disputed.
Teams doing coordinated change across many repositories, where the work is repetitive and the risk is inconsistency.
It is the wrong tool for an individual developer, a startup, a single repository, or anyone without an existing Sourcegraph deployment. On one small project the index gives it nothing a cheaper tool does not already have.
What retrieval at scale buys
- Context across every indexed repository — the clearest differentiator in this category.
- Onboarding onto systems too large to read, which is a real and expensive organisational problem.
- Model choice, so the organisation is not tied to one provider.
- Self-hosting for code and index.
- Cross-repository change at a scale editor-scoped tools cannot reach.
Its costs
- The prerequisite is the barrier — without Sourcegraph, no advantage, and standing it up is a project.
- Enterprise-only direction; do not assume older articles describing individual plans still apply.
- Little benefit at small scale.
- Stale indexes mislead confidently, which is worse than not answering.
- Completion is competent, not leading — retrieval is the product.
- Deployment complexity that requires an owner.
Unwinding a Sourcegraph deployment
The editor extensions uninstall cleanly and your code is untouched.
The real question is the Sourcegraph deployment itself, which may serve purposes beyond Cody — code search and navigation are useful without an assistant. Decommissioning it is a separate and larger decision, and organisations that adopted Sourcegraph for Cody alone should expect that unwinding to be a project rather than a cancellation.
Options without the indexing burden
- GitHub Copilot — enterprise controls without the indexing prerequisite, weaker cross-codebase context.
- Cursor IDE — per-project indexing, far easier to adopt, single codebase.
- Tabnine — when air-gapped deployment rather than scale is the requirement.
- Claude Code — agentic work with MCP connections to internal systems.
Compiled from Sourcegraph’s documentation and public sources. Plans and availability changed during 2025 — verify against Sourcegraph’s own pricing page. We have not hands-on tested this tool. Last reviewed 16 August 2026.
