Your CI runs every job on every push.
A push touches three files, but your pipeline runs every job anyway.
You pay for jobs that add no signal.
Docs changes run the integration suite, and jobs that haven't failed in months run on one-line fixes.
Every push restarts the wait.
Fix a typo after review and you wait on the slowest job again, not the one that mattered.
Stacked PRs pay for CI over and over.
Fix the bottom of a stack and every PR above it reruns its full pipeline, re-checking code that didn't change.
Agents multiply the waste.
Coding agents open more PRs, push more often, and lean on stacks, so your CI bill grows with them, not your headcount.
One verdict per job, with reasoning.
On every push, Dynamic CI scores each job against what changed and what that job has done before, then returns run or skip. Follow one PR from first push to merge.
Every job passes six checks before it is skipped.
Your merge queue skips nothing.
The commit that lands is fully tested. The only jobs skipped in the queue are ones your own path filters exclude.
Any job can be required.
Set any job to always run and it never skips. Developers can also force a skipped job back on from the PR, with no job change.
A job that just failed always runs.
If it rejected a PR from the queue, it runs again, whatever the score says.
New jobs always run.
No history, no skip. A job needs a couple of days of data before Dynamic CI will skip it.
Your call always wins.
Pinned jobs always run. Any developer can force a job back on from the PR.
When in doubt, it runs.
Trunk slow or unreachable, a fork with no token, a job with no verdict: everything runs.
Queue skips nothing
The commit that lands is fully tested.
Required jobs run
No queue behind it? It always runs.
Failed jobs rerun
Rejected a PR? It runs again.
New jobs run
No history, no skip.
Your call wins
Pinned or forced jobs always run.
When in doubt, it runs
Trunk down, forks, no verdict.
And if a skip is ever wrong, you see it. Every false skip is flagged in your dashboard and fed into the next verdict.
Keep what you have and skip what it can’t.
Most tools trim work inside a job that has already started. Dynamic CI decides before the job starts, so when it says skip, nothing after that point runs.
Replaces them. Your rules import as-is.
Use both. They skip targets; Dynamic CI skips jobs.
Use both. It trims tests inside jobs that still run.
Stacks with it. Fewer jobs, on faster runners.
Add one job. Keep everything else.
No new build system, no test changes, no migration. Paste one job into your pipeline, add a short condition to each job you want Dynamic CI to decide on, and open a pull request. On Buildkite, it's one extra stage in your pipeline upload.
Paste one job.
Add the Dynamic CI job to your pipeline, then a short condition on each job you want it to decide on. Your repo starts in learning mode.
Watch it learn.
It scores every job and skips nothing, then shows what it would have saved on your own repo.
Turn it on, repo by repo or user by user.
Enforce a repo, or a few users first, in the Trunk app when the numbers convince you. Widen from there.