How to Keep AI Agents From Inflating Your Terraform Run Count

Platform teams that already use AI coding agents keep asking us the same cost question: what happens to the run count when agents start opening pull requests? The worry isn't the price of a run. It's waking up to a month's worth of runs spent overnight. This post covers why agents raise run volume, how the pricing meter changes what that costs, and the Scalr settings that keep it in check. For the broader picture of agents and infrastructure as code, start with the AI coding agents primer.

Why do AI agents raise the number of Terraform runs?

Most Terraform platforms plan on every pull request update, and AI agents update pull requests far more often than people do. A typical agent loop is: push a change, read the failed plan or policy check, edit, push again. Each push starts a new speculative plan, so one change can collect a dozen plans before anyone reviews it. Teams we talk to describe exactly this: the agent keeps iterating on its own until the plan passes, and every iteration is a new commit.

Two other patterns add volume. Agents that create workspaces through the Scalr provider can trigger runs on creation, depending on the workspace's auto-queue setting. And agent changes to an upstream workspace can fan out through run triggers, since every successful upstream run starts a run in each downstream workspace.

How does the pricing meter change the impact?

The meter decides whether extra runs cost money or cost time. Scalr bills per run, so agent-driven volume shows up on the bill, and the controls below matter. HCP Terraform bills its paid plans per managed resource per hour as of October 2026, so extra plans don't change the bill, but concurrent remote runs are capped by tier: one on Free, three on Essentials, ten on Standard and 200 on Premium, per HashiCorp's plan docs. Under that model an agent burst queues behind other work rather than adding cost. Spacelift sizes its paid plans by private worker count as of October 2026, so it, too, turns bursts into queueing rather than billing.

Neither cost is zero. A per-run bill grows with agent activity. A capped queue slows every engineer down when agents are busy. The rest of this post is about the per-run case, where you can remove most of the waste with configuration.

Which runs does Scalr not bill?

Scalr bills apply runs and dry runs, including dry runs on pull requests. As of October 2026, it does not bill scheduled drift detection runs, runs in state storage only (local execution) mode, runs stopped in the pre-init or pre-plan stage, runs that fail during terraform init or cost estimation, and runs that fail because of an internal Scalr error. The full list and a run estimator are on the pricing page.

That pre-plan exemption is the most useful one for agents. Anything you can reject before the plan starts costs nothing.

How do you stop an agent's plans before they're billed?

Use a pre-plan OPA policy that looks at who opened the pull request. Scalr evaluates pre-plan policies against the tfrun input before the plan stage, and that input includes the run source, the user who started the run, the commit message and author, and the pull request author. Runs that are denied at the pre-plan stage are not billed.

This policy denies dry runs on pull requests opened by an agent's account unless the head commit message contains [plan], so the agent iterates locally and asks for a plan only when it thinks the change is ready:

package terraform
 
import rego.v1
 
import input.tfrun as tfrun
 
agent_accounts := {"{agent-account}"}
 
deny contains msg if {
    tfrun.is_dry
    tfrun.vcs.pull_request.author in agent_accounts
    not contains(tfrun.vcs.commit.message, "[plan]")
    msg := "Plans on agent pull requests run only when the commit message contains [plan]"
}

Set the policy's enforcement level in scalr-policy.hcl. At the pre-plan stage, hard and soft mandatory both stop the run with an error, and advisory only warns. The denied run shows up as a failed check on the pull request, which also tells the agent why it got no plan.

Pair it with the account-wide pre-checks for terraform fmt and terraform validate (or the OpenTofu equivalents). They catch the syntax and formatting mistakes agents make most often, and a run that fails a pre-check is not billed either.

Which settings cut automatic runs?

Five settings reduce how often Scalr starts a run without being asked:

• Ignore draft pull requests. Uncheck "Trigger runs for draft pull requests" on the VCS provider. Agents that open drafts and mark them ready when done then plan once instead of on every push. The setting applies to every workspace linked to that VCS provider.
• Plan on demand. Disable "Enabled VCS-driven dry runs" on a workspace and plans stop starting automatically. A reviewer comments /scalr plan when the change is worth planning.
• Skip a commit. Put [skip ci] or [skip scalr ci] in the first line of the head commit message and Scalr doesn't start a run for it. The second form avoids clashing with other CI tools that read the same tag.
• Narrow the trigger. Set a working directory or trigger patterns so only changes to the files a workspace uses start a run there. Agents often touch docs, tests and unrelated directories in the same pull request.
• Check auto-queue on vended workspaces. If agents create workspaces with the Scalr provider, set auto_queue_runs deliberately. The default, skip_first, doesn't run on creation, while always runs as soon as the first configuration arrives.

Review run triggers too. A downstream workspace starts a run after every successful upstream run, and if two upstream workspaces finish at once, two downstream runs are queued.

For early development, set a CLI-driven workspace's execution mode to state storage only. Terraform then runs on the developer's or agent's machine and Scalr only stores state. Scalr doesn't charge for those runs, but they also skip the run dashboard, OPA, Infracost, provider configurations and variables stored in Scalr, so keep it to sandboxes. This guide covers the trade-offs.

How do you see a run spike before the invoice?

Alert on the billing metrics. Scalr's Datadog integration reports scalr.billing.runs.count, the runs in the current billing period, and scalr.billing.flex_runs.count, the flex runs used so far. A Datadog monitor on the daily rate of change catches a runaway agent the day it starts. The same usage data is available from the Scalr API's billing usage report if you use a different monitoring tool.

Scalr never blocks a run when prepaid runs are used up. Runs beyond the plan are billed at the flex rate of $0.99 per run at the end of the subscription period, so an alert is what turns a misbehaving agent into a same-day fix instead of an end-of-period surprise. If a spike is legitimate growth, renewing early or upgrading avoids the flex rate.

Where should you start?

Start with the pre-plan policy for your agent accounts, because it removes the biggest source of waste and costs nothing to run. Then turn on draft pull request filtering and the fmt and validate pre-checks, and add a Datadog monitor on scalr.billing.runs.count. Once a week of data is in, compare runs per merged pull request before and after: that number tells you whether the agent loop is under control.

If you're still estimating what a workload will cost, the pricing page has a run estimator, and our review checklist for AI-generated Terraform covers what to check once the plan does run.