# Estimate savings and cost

This guide estimates two numbers before you roll hushrun out: the CI time that skips save, and the recorded checks your plan has to cover. Then it shows where to read both once hushrun runs.

## Before you begin

- List the checks your CI runs, how long each takes, and which run in a job with variants, such as a `strategy.matrix`. A job with variants skips only once each variant has its own name ([Jobs and variants](https://hushrun.com/docs/ci.md#variants)).
- Know whether the repository has [CI reuses only CI's results](https://hushrun.com/docs/ci.md#ci-only) on. With it on, laptops' and agents' passes don't skip CI, so the first source below saves nothing in CI.

## Know what a skip saves

A skip saves the run it stands in for: as long as that pass took. It's the `saves 41s` at the end of hushrun's line, and what the dashboard adds up as time saved.

In CI, a skip saves the check's time, not the job's. The runner still starts, checks out the code and installs dependencies, then the check exits 0 at once. To cut whole jobs, see [Skip CI when the code hasn't changed](https://hushrun.com/docs/guides/skip-ci.md#which-one-to-use).

hushrun saves repeats, not first runs. Code no one has checked yet runs every check that covers it.

## Find where the same code comes back

A check skips only when files that already passed it reach it again. That happens in five places:

1. **CI, after an agent or a person ran the check.** The pre-push hook refuses an agent's push until the checks that can run on its machine pass ([When a push is refused](https://hushrun.com/docs/for-agents.md#refused)). CI then skips them in jobs without variants, when it checks the same files the agent did.
2. **The run after a merge.** When `main` gets exactly the files CI checked on the pull request, its checks skip. That's the case when nothing else merged in between. A merge queue makes it the rule, since it checks each change as it will land.
3. **A re-run.** Re-run a whole workflow after one job failed or flaked, and the checks that passed skip in their jobs.
4. **Another machine on the same code.** An agent that runs the tests first, to see where the code stands, skips what CI already passed on that commit. So do a second agent on the same task, a reviewer's clone, and a revert to files that passed.
5. **Projects that didn't change.** In a repository with several projects, [scopes](https://hushrun.com/docs/monorepos.md#scopes) keep a change in one project from running another's checks.

> **Note:** A `pull_request` run checks the branch merged into its base. Once something else lands on the base, those are new files, and CI runs every check whose files changed, whatever passed on the branch. Have agents bring their branch up to date before they run the checks and push ([Pull requests](https://hushrun.com/docs/ci.md#pull-requests)).

## Estimate the CI minutes saved

For each check, multiply how often the same files reach it in CI by how long it runs, then add the checks up:

```text
minutes saved a month = repeats a month × the check's minutes, for each check
```

Your CI's history gives the second source. When the GitHub CLI is signed in, `npx hushrun init` in a GitHub repository not yet set up for hushrun counts it while it waits for your sign-in:

```text
Last 30 days, CI ran 96 times on code it had already passed: about 11 h.
```

That's whole workflow runs that started after the same workflow had passed on the same files, failed and cancelled ones included, timed from start to finish. GitHub lists a re-run under its original run, so re-runs aren't in it. The time a skip saves is less: the jobs still start and install, and jobs with variants don't skip.

The first source isn't in CI's history. It grows with the number of pushes from agents whose branch was up to date: each one carries a pass for every check that can run on the agent's machine.

An example, with numbers to replace with your own. One CI job, without variants, runs `lint` (1 minute), `typecheck` (2 minutes) and `unit` (6 minutes). In a month, agents push 300 times with their branch up to date, 80 merges land with nothing merged in between, and 40 runs are re-run in full after another job flaked:

```text
agents' pushes   300 × 9 min = 2,700 min
merges            80 × 9 min =   720 min
re-runs           40 × 9 min =   360 min
saved                          3,780 min, about 63 hours
```

With CI reuses only CI's results on, the first line drops out: 1,080 minutes.

To put it in dollars, multiply the minutes by your runner's price per minute ([GitHub Actions pricing](https://hushrun.com/docs/guides/github-actions-pricing.md)). Count the time people and agents stop waiting, too: a skip on a laptop or in a sandbox saves the same run there.

## Estimate your recorded checks

Your plan counts the passes and fails hushrun records. Skips and reads are free. So count the runs that don't skip:

```text
recorded checks a month = CI's runs + laptops' runs + agents' runs, of checks that didn't skip
```

- **CI:** each check that runs counts once per workflow run. Re-runs of the same run count once.
- **Laptops:** each run of a wrapped check that doesn't skip.
- **Agents:** often the largest term. An agent that edits, tests, edits and tests again records a check each time, because each edit is new code. Count test runs per task, not pushes. The checks the hook asks for before a push skip when the agent's last run already passed those files.

An example: 40 pushes a working day that each run 6 checks in CI, 300 runs a day on laptops and 750 in agents' sandboxes come to about 1,300 recorded checks a day. Over 22 working days, that's about 28,000 a month.

## Pick a plan

Find the smallest plan that covers your estimate. Plans count recorded checks, not people: no plan limits members.

| Plan | Recorded checks a month | Price |
|---|---|---|
| Free | Up to 2,000 | $0 |
| Pro | Up to 5,000 | $20/month, billed monthly, or $200 billed yearly |
| Team | 10,000, then overage: 20,000 in all at the default spend cap | $49/month, billed monthly, or $490 billed yearly |
| Growth | 75,000, then overage: 150,000 in all at the default spend cap | $99/month, billed monthly, or $990 billed yearly |
| Scale | About 300,000; a contract sets it | ~$399/month, billed yearly |
| Enterprise | What a contract sets | From $1,500/month, billed yearly |

Overage costs $3 per 1,000 on Team and $1.50 per 1,000 on Growth. Past 20,000 checks a month, the dashboard suggests Growth to an organization on Team: from about 26,700, Growth costs less than Team with overage.

At the limit, checks still run and passes recorded before still skip: [At the limit](https://hushrun.com/docs/plans.md#at-the-limit).

If you aren't sure of your estimate, start on Free. The Usage page's chart shows your recorded checks by day until recording pauses at Free's limit, which for a large team can come within days. That's enough to read your rate. A paid plan comes with a [60-day refund guarantee](https://hushrun.com/docs/plans.md#refund).

## Measure it in a trial

Once hushrun runs, two pages in the dashboard answer both questions:

- **Time saved.** The organization's **Overview** shows the time skips saved in the last 7 days, on laptops, in sandboxes and in CI. Each repository's page shows each check's runs, skips and time saved in the last 30 days ([Repositories](https://hushrun.com/docs/teams.md#repositories)).
- **Recorded checks.** **Usage** shows the recorded checks this period, a chart by day and each repository's share. From a terminal, run `hushrun repository usage` ([See where your organization stands](https://hushrun.com/docs/plans.md#usage)).

## Next

- [Roll out to your team](https://hushrun.com/docs/rollout.md): set up people, CI and agents.
- [Plans and limits](https://hushrun.com/docs/plans.md): what counts, the limit and the spend cap.
- [Set up CI](https://hushrun.com/docs/ci.md): jobs, variants and the CI-only setting.