Limits, Concurrency & Cold Start
Concurrency defaults per plan, cold start latency, queue handling, and billing behavior for Tenki Runners.
This page is the single reference for the operational limits of Tenki Runners: concurrency, cold start, queue handling, and how usage is billed.
Cold start
Tenki Runners cold-start in approximately 15 seconds on average, regardless of runner size or concurrency. Every job boots into a fresh VM.
Concurrency
Default concurrent-job limits, by plan:
| Plan | Concurrent jobs |
|---|---|
| Starter | Up to 5 |
| Team | Up to 50 |
| Enterprise | Custom (unlimited on request) |
The Team plan includes 4 concurrent macOS jobs by default; higher macOS concurrency is available on request within the overall account cap.
Jobs above your concurrency limit queue rather than fail, and start as capacity frees up. Queue time is never billed.
Size limits
The Starter plan supports runner sizes up to 4 vCPU / 8 GB. A Starter job targeting a larger size is blocked rather than queued; switch to a smaller label or upgrade to run it. The Team plan supports sizes up to 64 vCPU / 256 GB; see Pricing for current plan details.
Billing behavior
- Usage is billed per second of job runtime; rates are quoted per minute. Billing starts when the job starts running, not when it queues.
- There are no idle charges: VMs are destroyed at job end and there is no standby pool, so nothing accrues overnight or on weekends.
- Jobs are balance-gated: if your workspace has no usable credit, Tenki rejects new jobs before any paid work starts.
- An optional daily spending limit can cap usage; Tenki cancels runs beyond it with a "spending limit exceeded" notice.
- The only recurring charges are your plan fee and any active add-ons; see Pricing.
Job duration
Tenki imposes no job time limit of its own; GitHub's standard limits (6 hours per job, 35 days per workflow) still apply.
Cache storage
Cache quotas are per plan (5 GB Starter, 10 GB Team) with LRU eviction; see Caching for the full behavior.