Sourcegraph now charges for merged AI changesets

Sourcegraph made Agentic Batch Changes generally available on September 14, with a pricing model tied to merged changesets. The company says customers pay for changes that merge, rather than tokens, seats, or attempts. A pull request that a team chooses not to merge does not incur that changeset charge.

For engineering managers budgeting a library upgrade or API migration across repositories, that changes the commercial conversation. The estimate starts with the work expected to land, rather than a forecast of how many model calls the agent will need. It also makes the definition of a billable changeset worth settling before the work begins.

How the agent gets a change ready to merge

In its launch announcement, Sourcegraph describes a system built on Batch Changes, its coordinated code-change engine, and Deep Search, its codebase-search agent. An engineer describes the change in plain language. The system scopes the indexed codebase, builds a plan, tries the change in one repository, and then applies it more broadly.

The work does not always go to a coding agent. Sourcegraph says the system generally writes scripts for repeated transformations and delegates work that needs judgment to Claude Code or Codex. As repositories differ, it adapts the change. When CI fails, it responds to the failure and continues preparing the pull request for human review and merge. It tracks merge status across the rollout.

That combination matters because a migration involves both editing and coordination. A script may handle a repeated transformation efficiently, while a shared view helps an engineer see which proposed changes have actually landed. The announcement describes the product's intended behavior; it is not a BaristaLabs test of migration accuracy or completion time.

Sourcegraph says Agentic Batch Changes is available to Sourcegraph Cloud customers and on by default. The announcement does not establish equivalent availability for self-hosted installations. Existing customers should confirm their account's commercial terms before using the new billing model in a budget.

The charge follows the merge, not the attempt

Sourcegraph's wording is explicit: “You pay per changeset merged into your codebase, not per token, seat, or attempt.” It also says that if a team decides not to merge an opened pull request, it does not pay for that change.

This makes the billable event easier to connect to repository records. Under the stated model, extra agent attempts do not themselves add changeset charges. A rejected proposal can still consume CI resources and reviewer time, however. Those costs remain part of the engineering effort even when the vendor's changeset charge is absent.

The announcement gives no numerical price per merged changeset. It also does not explain minimum commitments or how this charge relates to a customer's underlying Sourcegraph agreement. “Not per seat” describes the announced Agentic Batch Changes pricing unit; it should not be read as a promise that every other platform charge disappears.

Our earlier Sourcegraph analysis addressed how to control a multi-repository rollout. The new decision is narrower: what the team will buy, how the vendor will count it, and how finance can reconcile that count with engineering's records.

Agree on how changesets will be counted

A repository count is not enough to settle a migration quote. Ask Sourcegraph to map the proposed work to billable changesets and explain what happens when the plan changes. In particular, establish the treatment of a change split into several pull requests, a merged change later reverted, and a follow-up correction.

These are unanswered commercial questions in the public announcement, not claims that Sourcegraph charges twice or refuses credits. Written answers would let a buyer distinguish ordinary rollout changes from events that alter the invoice.

Give the quote an agreed migration scope: the intended transformation, repositories included, and known exclusions. Then ask what record will identify each billed merge. Engineering and finance should be able to compare the same changeset identifiers rather than reconcile a vendor total with an unrelated count of repositories.

The accounting should not dictate how reviewers divide the code. Keep pull requests small enough to understand and test. If a pricing definition makes that review structure unexpectedly expensive, resolve the commercial terms rather than combine unrelated edits to reduce the count.

Keep migration completion separate from billing

A merged changeset is a useful billing event because it is observable. It is not necessarily the end of the migration. A merged dependency update may still need deployment; a deprecated API may remain in repositories outside the original search scope.

Keep the agreed billable merge record alongside the team's own completion criteria. For a dependency migration, those criteria might include the deployed version and a check for remaining uses of the old dependency. This lets finance verify the charge while engineering verifies that the intended change reached the systems that need it.

Sourcegraph's launch offers a more direct connection between agent spend and accepted code changes. To evaluate it, bring one defined migration to the account team and ask for a quote with an explicit changeset definition. That provides a firmer basis for a purchase decision than estimating tokens without knowing how many attempts the work will take.

Sources

• Sourcegraph: Introducing Agentic Batch Changes, September 14, 2026. Primary source for availability, execution workflow, human review, and merged-changeset pricing.
• Sourcegraph: Agentic Batch Changes. Product overview of migration planning and execution. Commercial questions and budgeting recommendations above are BaristaLabs' analysis.