To see what a go-to-market change will set in motion before it merges, connect its repository to your Cargo project: every pull request gets a plan comment with an “On merge” table that counts, for each play and one-off execution, the records it runs on, the emails, LinkedIn actions and messages it can send, and the credits it can spend. Past 100 emails, 100 LinkedIn actions, 100 chat messages, 5,000 audience adds or 2,500 credits, the Cargo check fails until a reviewer adds the cargo:approve-impact label.
A resource diff tells you that a play changed. It does not tell you that the new filter enrolls 1,200 contacts who will each get an email. The preview answers the second question, on the pull request, before anyone presses merge.
Turn it on #
The preview is part of the connected-repository deploy. Once a repository holding a Cargo project is connected in Settings → States, there is nothing else to configure:
git checkout -b widen-expansion-filter
# edit infra/plays/expansion.ts
git commit -am "Expansion: include accounts from 50 employees"
git push -u origin widen-expansion-filter
gh pr create --fill # Cargo comments the plan and the preview on this pull request
Cargo clones the commit into a sandbox, runs your project’s own @cargo-ai/cdk with plan, and updates the same comment on every later commit. A plan never gets a Cargo credential: it reads a copy of the deploy state and nothing else.
What the comment shows #
Above the resource table, one “On merge” table covers every play the pull request creates, updates or enables, and every one-off execution the merge would run:
| What | Runs | Records | Sends, at most | Credits, at most |
|---|---|---|---|---|
| Expansion | play, keeps running | 1,200 | 1,200 emails, 1,200 chat messages | 1,200 |
2026-10-14-pilot | batch of Expansion, once | 40 | 40 emails | 40 |
How each column is counted:
- Records, for a play. A new play, or one this change enables, counts every record its filter matches. A running play whose filter is unchanged counts only the records that match now and are not enrolled yet, so rewording a step does not read as a fresh send. A changed filter, sort or limit counts every record it matches. A play keeps enrolling after the merge, so its row is a snapshot.
- Records, for an execution. It runs once, so its row is all of it: a filter’s matches under its limit, a segment’s records, the listed ids, the records written in code, a file’s rows, or one for a run.
- Sends. Emails, LinkedIn actions, Slack and Teams messages and audience adds, read from the workflow’s steps, including steps inside a loop, once per record. Every branch is assumed taken, so these are upper bounds.
- Credits. Each connector action’s credit cost. Actions on a connector that uses your own API key count as zero.
Steps that call a tool or an agent are noted in the comment but not counted.
The approval gate #
These limits come from Cargo’s code (STATE_RUN_IMPACT_THRESHOLDS, October 2026), totalled across plays and executions:
| Effect | Needs approval above |
|---|---|
| Emails | 100 |
| LinkedIn actions | 100 |
| Chat messages | 100 |
| Audience adds | 5,000 |
| Credits | 2,500 |
Over any of them, the check fails with Needs approval: large impact. It also fails when a play or execution that sends or spends cannot be counted: its model or segment is created by the same change, its steps could not be read, or it sends inside a loop. Adding the cargo:approve-impact label re-plans the pull request and the check passes; removing the label fails it again.
Make the check required in branch protection so the gate actually stops a merge. It is named Cargo, or Cargo (directory) for a project that is not at the repository root.
What the merge does with the preview #
A merge starts only the executions a pull request previewed. The deploy holds an execution, rather than starting it, when no successful plan counted that exact version of it, when that plan was not approved, or when it now runs on more records than the preview allowed (up to 10% over a filter’s or segment’s count). A held execution stays pending and is previewed again by the next pull request.
Limits #
- The preview needs a connected repository. A plan run on your machine with
cargo-ai project planlists executions but does not count sends or credits, because counting reads live workspace data. - Pull requests from forks are not planned.
- Counts are upper bounds, not forecasts: every branch is assumed taken.
Full reference: GitHub deploys in the Cargo docs. The whole lifecycle is in GTM as code: the complete guide.