Pydantic Cuts CI Bill From $18,200 to $5,700 by Moving to RunsOn

A CI bill that nearly tripled in a few months

According to Pydantic, its CI spend was relatively flat in the spring: $3,813 in April 2026, $3,665 in May and $3,990 in June. It then rose to $10,778 in July, nearly three times April's spend, and reached $18,200 in August.

The company ties this to a jump in development activity on Logfire, which is built in its pydantic/platform repository. By August 30, the Logfire team had merged 2,032 pull requests that month. Over the same 30 days in 2025, a team of the same size merged 365. The main CI workflow in that repository ran 4,194 times in May, 6,669 times in June, 11,919 times in July and 20,659 times through August 30.

Pydantic says this was not low-quality output. It says the team shipped real products, added important tests, improved browser coverage and ran significantly more automated reviews, with bots creating much of the pull request activity and responding to the rest.

Why Pydantic chose RunsOn

Before September 1, Pydantic used a mix of GitHub Actions, Depot and Ubicloud for CI. With RunsOn, GitHub still orchestrates every workflow, while fresh EC2 runners start in Pydantic's AWS account and disappear when the job finishes. The company says it did not have to replace GitHub's CI control plane or build its own runner platform.

Migration was mostly light, according to Pydantic. Ordinary jobs mainly needed a different runner label and the RunsOn setup action, while container builds needed some additional cache and registry changes. The company says that above a million runner minutes per month it wanted more control over which machines it paid for, and that RunsOn pays for itself at 22 jobs per day, a threshold it was well past.

RunsOn handles the runner lifecycle. Pydantic still manages its AWS account, runner catalog, capacity strategy, storage, cache policy, quotas and telemetry.

How the setup works

The runner catalog now ranges from one-core ARM runners to 16-core image builders. Most Python, TypeScript, agentic and control-plane jobs run on Graviton, while x64 remains for container builds and tests that require it. Each preset includes several eligible EC2 families so the Spot allocator has more capacity pools to choose from.

• RunsOn's Magic Cache serves existing actions/cache calls close to the runners.
• Sticky EBS disks preserve expensive BuildKit state.
• Merge-queue validation, release publishing, deployments and jobs with expensive restarts use On-Demand instances.
• Long, interruption-sensitive jobs use capacity-optimized Spot placement, and shorter jobs use price-capacity-optimized placement.

The private deployment spans three availability zones. A circuit breaker temporarily sends new jobs to On-Demand after a burst of interruptions.

Results and lessons

September was the first month on RunsOn. Total CI cost was $5,700, down from $18,200 in August, and Pydantic says that figure includes the RunsOn license and all AWS costs: compute, EBS, S3 cache storage and data transfer. Usage kept growing, with runner minutes rising from 1,230,264 in August to 1,617,654 in September.

Pydantic summarizes its lessons as three rules: use Spot where retries are cheap and keep the merge queue and release paths on On-Demand capacity; right-size against the critical path, since the cheapest runner is the one that meets the workload's latency target at the lowest total cost; and keep cache near the compute, retaining it only while it is likely to be reused.

For teams seeing similar growth in automated and AI-assisted contributions, the company's account suggests that CI cost can be addressed by changing where builds and tests run rather than limiting the agents. In its words, it "did not ask the agents to stop." These figures come from Pydantic's own reporting of a single team's workload.