Cody AI, a tool that left the individual market

Cody AI, a tool that left the individual market

Cody spent years among the more frequently recommended coding assistants for individuals, largely thanks to a free plan and its grasp of a whole repository. That variant no longer exists: the free and individual plans were retired on 23 July 2025, and the product moved into the enterprise offering only.

What exactly changed

The retirement covered two plans at once. The free variant used by individual developers, and the paid individual variant. The same announcement also stripped Cody out of the Enterprise Starter plan, so the change touched three items in the offering altogether. What remains is the enterprise edition, billed annually.

The product itself did not disappear, but its audience changed. Today it sells as part of a broader platform alongside code search, batch changes, and administrative tooling, rather than as a standalone assistant to install in an editor.

The company's centre of gravity moved too. The team shifted attention to a separate agentic product, available more widely, while Cody stayed as part of the offering for organisations already inside the Sourcegraph ecosystem.

It helps to understand where such a decision comes from. Multi repository context requires maintaining an index, and that cost grows with codebase size rather than user count. Under a free plan the vendor bore that cost for everybody who connected a large repository, which scales badly for this shape of product. Several tools in this category went through similar changes in recent years, usually for the same reason.

That explains why material online contradicts itself. Guides from before mid 2025 describe a free plan and a plugin install, while the current offering looks entirely different. When hunting for information, check the publication date.

What the enterprise edition costs

The vendor publishes one number: the platform starts at sixteen thousand dollars a year, with the bill scaling by team size and by allocated credits for model assisted features. There is no per seat rate in the price list.

Figures circulating in third party roundups, usually in the tens of dollars per seat per month, predate the change in the offering and are no use for budgeting. There is no self serve variant either, so a comparison against competitors starts with a sales conversation.

When comparing offers, ask directly about credits for model assisted features, since those determine the real bill under heavy use rather than seat count alone. The price list states four rules around them: the allowance is counted per user but pools across the whole organisation, it does not lapse at month end, and it rolls over into the next period at renewal. Larger buckets sell as a separate add on, so headroom for usage spikes has to be written into the contract rather than topped up on the fly.

That model makes sense for organisations already using code search across many repositories and needing administrative control. For a five person team looking for an editor assistant, it is an entry barrier that settles the matter without further analysis.

What Cody did well and why that still matters

It helps to understand what the product contributed, because that trait recurs in other tools today and it is what you should look for in an alternative.

The differentiator was context built on a code graph rather than purely on similarity search. The tool knew which function called which, where a type was defined, and what would break after a signature change, because it drew on an index built like a code search engine rather than on chunks matched by textual similarity.

The second trait was working across many repositories at once. In an organisation where business logic lives in one repository, the client in another, and shared definitions in a third, an assistant seeing only the open project is markedly limited.

A third element, less striking but practically important, was control over what reaches the model. Being able to exclude repositories from indexing and to inspect which queries leave the network is often a precondition for approving a tool inside an organisation, regardless of its quality.

Those two things still separate enterprise tooling from individual developer tooling, and they are what alternatives should be compared on, rather than code completion quality, which has levelled out across products.

What to replace Cody with

If you were after Cody for its free plan, the closest equivalent today is Devin Desktop, one of the few keeping a free variant for a single user.

If you were after organisation level control, the enterprise edition of GitHub Copilot comes closest, offering company wide policy and reporting, though without an index spanning many repositories.

If you were after it for multi repository context, no replacement exists at the same price. A partial answer is giving an assistant access to a code search engine through your own server in the MCP protocol, which hands the model an index it cannot build itself.

What Amp is

The team behind Cody built a separate agentic product available without the enterprise barrier, and on 2 December 2025 that product, Amp, spun out of Sourcegraph as an independent company. It works in the model that dominates today: you describe a task, the agent reads files, applies changes, and verifies the result.

One distinction matters. Amp is not a cheaper Cody, because it lacks what set Cody apart: index built multi repository context and administrative features for organisations. It is a different product for a different job rather than a successor in the same role, and since the spin out the two are not even developed by the same company.

For an individual developer that change is neutral or favourable, since they get an agentic tool with no annual contract. For an organisation that chose Cody precisely for cross repository context, it is a signal to check where development of the chosen variant is heading.

Trying the tool costs a few minutes, since it installs with one command and runs from the terminal, with no editor extension involved.

brew install ampcode/tap/ampcode
amp update

On systems without that package manager an install script from the project site does the job, and the npm registry package is named @ampcode/cli, though the vendor does not recommend that route. The version number here is built from a timestamp, so it says nothing about compatibility; update with the command rather than by pinning a version.

Who the enterprise edition still suits

Despite the high entry threshold, situations exist where this choice is justified, and they deserve naming rather than dismissing the product as merely expensive.

The first is an organisation with dozens of repositories and teams regularly reaching into each other's code. The licence cost then compares not against another assistant's price but against time lost hunting for where something is defined and who uses it.

The second is control requirements. A security team asking who has access to which code, which queries reach the model, and where they are stored gets answers here that individual developer tools do not provide.

The third is changes run at scale. The ability to apply the same fix across fifty repositories and open fifty change requests is a feature no editor assistant replaces, and during a dependency migration or an API retirement it saves weeks.

The fourth is a company already using the platform for code search. The assistant is then an addition to something you pay for anyway rather than a separate purchasing decision, and the bill looks entirely different.

Outside those four cases, the price difference against tools available for a dozen or so dollars per person per month is hard to justify.

How to make decisions like this

This story illustrates a risk more common in this category than in others, and practical conclusions follow from it.

A free plan is not a commitment. A tool that attracted you with a free variant can retire that variant when the business model changes. Build your process so switching tools costs days rather than weeks.

Keep configuration in the repository. Project rules, conventions, and a description of the technology stack recorded in a file beside the code work with any tool, while settings locked inside one product disappear with it.

Separate what the tool provides from what the model provides. Generated code quality depends mostly on the model, and those are available from many vendors. A tool's real value is the context it can gather, and that determines how hard replacement is.

The last point concerns teams. A tool deployed to twenty people carries a switching cost measured in weeks of their work, so at that scale ask about the exit path and configuration export alongside the feature list.

Multi repository context after leaving Cody

That is the one feature whose absence genuinely hurts after switching tools, so it helps to know how to rebuild it more cheaply.

The first route is a code search engine as a separate tool, unconnected to the assistant. You expose an index built across all repositories to the model through your own server in the MCP protocol, and the assistant gains the ability to ask for a definition or for usage sites rather than guessing from open files.

Wiring such a server in takes a few lines in the agentic tool's settings.

{
  "amp.mcpServers": {
    "code": {
      "command": "node",
      "args": ["./tools/search-server.js"]
    }
  }
}

On the server side it is enough to wrap what you already use from the command line. The Sourcegraph search engine ships its own terminal client, and the query syntax lets you narrow a search to repositories, to a language, or to symbol definitions alone.

src search -query='context:global repo:^github\.com/company/ lang:typescript type:symbol createOrder'

That last term matters most. Asking for a symbol type returns the definition site rather than every textual occurrence, so the model gets one accurate answer instead of forty lines to sift through.

The second is order inside the repositories themselves. Plenty of context problems come not from the tool but from shared definitions copied in three places instead of living in one package. Tidying dependencies often costs less than a licence and helps regardless of which assistant you choose.

The third is a monorepo where it makes sense. If the split into repositories came from convenience years ago rather than from team boundaries, merging them solves the context problem while solving several others along the way.

The fourth is describing the architecture in a file the assistant reads. A dozen sentences about where things live and how modules call each other replaces a good share of what a code graph computed automatically. It is an imperfect solution that costs an hour and works with any tool.

The file is usually named AGENTS.md and sits at the repository root, and most current agentic tools read it with no extra configuration.

# Architecture

Domain logic: packages/core, no dependency on the HTTP layer.
API: apps/api, calls packages/core only.
Client: apps/web, talks to the API through a generated client.

Shared types live in packages/contracts and are the source of truth for both
sides. Changing a type there requires regenerating the client with `pnpm gen`.

# Commands

Tests: `pnpm test`
Type check: `pnpm typecheck`

Note that the value here lies in describing dependencies rather than listing directories. The model will see the file structure anyway, whereas a sentence stating that one module must not call another is information no directory tree conveys.

Assess honestly how much this really changes, though. In many teams multi repository context was a sales argument rather than a daily need, since work stays inside one project most of the time anyway.

Common mistakes

The first is looking for a free plan based on older guides. That variant has been gone since July 2025, and installation instructions from that period lead nowhere.

The second is comparing the per seat price against competitors without accounting for the platform entry threshold. The monthly rate looks comparable until you add the minimum contract value.

The third is assuming the same team's agentic product succeeds it in the same role. It is a different tool, without multi repository context and without the administrative layer.

The fourth is judging a replacement by code completion quality. That has levelled out across products, so the difference lies in the context a tool can gather, and its absence is what you feel after switching.

The fifth is deferring the decision about an alternative. With a tool the team uses daily, a migration planned in advance costs a fraction of one forced by changed terms.

FAQ

Is Cody still free?

No. The free and individual plans were retired on 23 July 2025, and the same day removed Cody from the Enterprise Starter plan too. The product is available only in the enterprise edition, sold as part of a broader platform. The vendor publishes no per seat rate, and the single figure given is the platform entry threshold.

What does a deployment really cost?

The price list gives only the platform entry threshold, starting at sixteen thousand dollars a year and scaling with headcount and with allocated credits for model assisted features. There is no per seat rate at all and no self serve variant, so a specific figure requires a sales conversation.

What should I use instead of Cody?

It depends on why you used it. For work on one repository, Cursor or Claude Code suffice. For a free variant, Devin Desktop comes closest. Index built multi repository context has no direct replacement at a comparable price.

How does Amp differ from Cody?

Amp is an agentic tool available without the enterprise barrier, while lacking the multi repository context and administrative features that set Cody apart. It is a separate product for a different job rather than a cheaper version of its predecessor.

Is it worth migrating if I have an active contract?

There is no reason to rush if the tool works and multi repository context matters to you. At renewal, though, check whether the development direction matches your needs, and prepare your configuration so that changing tools would not mean rebuilding everything from scratch.

The current offering is described on the Sourcegraph site, and the plan changes were announced in a post on the company blog.