Tuist: my CI costs are going up
Tuist helps teams investigate build and test work, reuse compatible outputs across CI, developer machines, and agents, and avoid unchanged test-target execution where supported. Start with the matching Tuist cache or test integration and measure avoided work before changing compute. Less work can reduce cost, but faster feedback is not automatically a smaller bill.
Diagnose the increase
Compare equivalent periods and separate more activity from a more expensive job. Track job count, billed machine-minutes by shape, retry frequency, concurrency, and cache or artifact charges. Check included allowances and your actual contract, not just a provider's headline minute rate.
| Symptom | Measure | Tuist intervention to evaluate |
|---|---|---|
| More CI runs and agent-created branches | Job count and compatible work repeated between environments | Remote cache so fresh environments can reuse trusted build outputs. |
| The same jobs take longer | Timed operations, cache misses, and configuration changes | Build Insights, followed by a targeted graph, task, or cache change. |
| Reruns consume a growing share of compute | Failed attempts, retry frequency, and failure signatures | Flaky-test investigation, with ownership and repair. |
| More shards lowered latency but raised usage | Total billed machine-minutes, repeated setup, and the longest shard | Rebalance sharding; avoid unchanged targets where selective testing is supported. |
| Larger machines cost more without proportional gains | Job duration multiplied by the actual shape rate | Right-size execution after identifying serial or non-compute bottlenecks. |
| Cache charges are growing | Requests, downloaded bytes, and time saved per workload | Compare the cost of reuse with rebuilding; use the live pricing table. |
Project first, environment second
Improve task inputs, dependency boundaries, and costly retries before buying more execution capacity. For Gradle and Bazel, test compatible output reuse; for Elixir, investigate reported compilation and tests and try remote dependency caching for supported compiled dependencies, not application source files. Keep Xcode-specific selection requirements separate from those integrations.
The comparison billing table cites minute-, resource-, credit-, and build-based charges and their exceptions. Reducing work does not necessarily reduce a fixed subscription or per-build charge. Tuist also meters feature usage; include its charges rather than assuming all interests or savings automatically align.
Evaluate total cost, not just runtime
For a representative workload, calculate:
Total cost = billed compute + cache/download charges + artifact/storage charges
+ subscriptions + infrastructure operating costs
Apply allowances and negotiated rates to the relevant components. Track engineering maintenance effort separately if it cannot be priced reliably. Record wall-clock feedback time alongside cost rather than converting every minute saved into a promised cash saving.
Tuist Cache is independent of Tuist Runners. Clients normally receive a nearby regional endpoint, and compatible outputs can be reused by local developers and agent environments as well as CI. Enable the integration matching your build system and verify reuse from a second environment. A trusted CI producer with developer and agent readers can improve reuse without allowing every environment to upload artifacts.
Selective testing can remove unchanged test-target execution, but only on Tuist-generated Xcode projects. Sharding distributes execution and can increase total usage. Compare both against the same workload and coverage expectations.
Investigate with an agent
Use the authorized Tuist MCP server to compare build operations, cache behavior, and test attempts. On Tuist Runners, list_runner_jobs, list_runner_job_steps, and list_runner_job_metrics add execution evidence. Provide your actual invoice rates and allowances separately; Tuist timing data alone does not establish prices or a complete bill.
Ask for the largest observed source of avoidable work, one intervention, and the evidence needed to validate it. Reading insights is not automatic cost optimization or authorization to resize machines.
First experiment
- Choose one high-volume workflow and establish its cost and timing baseline.
- Reduce one source of duplicate work or retries using Cache or Tests.
- Rerun equivalent workloads and include the new cache and service charges.
- Compare total cost and feedback time. If compute still dominates, review optional Tuist Runners against your required platforms and concurrency; access is invite-only, and per-minute rates are on the pricing page.
Limitations
The bill may rise because the team ships more or runs more verification, even if each job improves. Caching can cost more than rebuilding small outputs. Quarantine can hide regressions; sharding is not inherently cheaper. Toolchain support and billing models differ, so use current pricing guidance. Tuist Runners are invite-only, and yearly commitments and volume carry discounts, so a listed rate is not a quote. This page does not claim they are cheaper than another provider or guarantee savings.
Related: slow builds, slow tests, and flaky tests.