The CI Arcade

A fairness layer for CI that saves money by slowing you down just enough.

TL;DR

CI is too fast, engineers are too parallel, and cloud bills are too real.
The CI Arcade introduces a token-gated queue that meters the blast radius of human enthusiasm. One job at a time. Sometimes.

The Pitch

• Cut CI concurrency without saying “we cut CI concurrency”
• Align engineering behavior with finance targets using playful “game” mechanics
• Make throughput feel like a privilege you earn, not a utility you expect

Core Mechanics

You don’t run CI. You buy a turn.

Token lifecycle

• One active token per user. No token, no CI
• Tokens are consumed on job completion
• Forced issuance lets a user eject their currently running job to get a fresh token. Brutal but fair

Golden path flow

1. User requests token generation.
   - Check for existing active token.
     - If active token exists: Notify user (cannot generate new token).
     - If no active token: Generate new token and mark as active.

2. User requests forced token issuance.
   - Check for active job.
     - If job is running: Terminate job, mark existing token as invalid.
   - Generate new token and mark as active.

3. User provides active token to run CI job.
   - Check token status.
     - If valid: Run CI job, mark token as used upon completion.
     - If invalid: Notify user (token no longer valid).

4. Log CI job result and token used.
   - Provide feedback to user about job outcome.

Sequence diagram

Token state machine

UI Concepts

Interface specifications. Lo-fi prototypes pending design review.

1) Home

• Big “Get Token” button
• “You have an active token” banner with a sad timer that counts up, not down

2) Queue + Force Issue

• Status + position in line
• Nudge/Bump controls
• Destructive Force Issue modal with “I accept the chaos”

3) Leaderboards + Finance

• Least Tokens Used (weekly)
• Finance panel with “Increase Arcade Capacity (Finance only)”

Workflows

“Happy” path

• Developer requests token
• Gets one
• Runs job
• Token is marked used when job completes

Result: Single-flight behavior. Cheap. Calm. Boring. Perfect.

“Panic refactor” path

• Developer spams commits
• Sees “active token exists”
• Tries Force Issue
• Running job is terminated, token invalidated, new token created
• Runs new job

Result: The Arcade discourages thrash with self-inflicted pain. Finance smiles.

“Oops stale token” path

• Developer tries to run a job with an invalid token
• Gets told it’s invalid
• Must request a new token like a normal human

Result: Order restored. Savings continue.

Pricing Theory

Free Soft concurrency caps. Leaderboard participation. Community norms.

Team — $8/seat/month Hard token enforcement. Audit logs. Manager dashboards. Monthly Arcade Health Report (PDF, branded).

Enterprise — Contact Sales

• Dedicated Arcade Success Manager
• Quarterly “Build Intentionality” workshops (CPD credits available in select regions)
• Custom Efficiency Score weighting aligned to your OKRs
• Concierge terminology review: all system strings audited for growth-positive language
• SLA: token issuance P99 < 45 s (intentional — supports deliberate commit practices)
• Joint “Capacity Planning” briefing with Finance, quarterly

SLOs

• Token issuance P50 under 200 ms
• Queue visibility P95 under 1 s
• Job kill-on-force-issue P99 under 3 s
• Monthly target: Arcade Efficiency Score ≥ 0.72 (see Appendix B for scoring model)

Governance and Compliance Theater

• Audit log stores:
  • user_id
  • token_id
  • job_id
  • action (issued, validated, consumed, invalidated, killed)
  • timestamps
  • reason (human text, e.g., “panic push”)
• Retention: 13 months so you can draw bad trend lines during budget season
• “Separation of duties”: only Finance can increase concurrency ceilings

Exemptions

• Staff+ engineers: token limits apply, but Force Issue is pre-authorized
• Incident responders: tokens auto-issued during active PagerDuty P0/P1 alerts
• Release managers during freeze windows: unlimited tokens, Finance-notified post-hoc

Change Management

Behavioral Design

• Commitment reinforcement: bonus token credits for users who maintain build frequency under 3/day. Encourages deliberate shipping.
• Community recognition: weekly digest highlights top contributors by Arcade Efficiency Score.
• Decision support: pre-confirmation modal on Force Issue surfaces estimated job completion percentage and time remaining. Users make informed choices.

FAQ

Isn’t this just a mutex for humans?
Yes. That’s the point.

Will engineers be slower? No. Engineers will be more intentional. Velocity is a measure of value delivered, not jobs launched. Internal pilots show a measurable reduction in context-switching overhead and a perceived throughput improvement of 12–18%. [n=14, 8 weeks, Platform team]

What about flaky tests?
Great news. You’ll notice them less often because you run fewer jobs.

How do I bypass this?
You don’t. Arcade Capacity is policy, not preference.

Launch Assets

One-pager diagram

Poster copy

• Headline: “Ship less. Save more.”
• Subhead: “Turns, not threads.”
• Footer: “The CI Arcade. One coin per run.”

Slack announcement

Arcade is live. You get one active token. Force Issue kills your job and gives you a new coin. Jobs without valid tokens are bounced. Leaderboards on Friday. Questions in #arcade-support.

How We “Measure Success”

• CI spend down 25–40%
• PRs linger longer but merges still happen
• Engineers report “less chaos” while privately seething
• Finance approves your next pet project because you “found savings”

Appendix: Mindful Builds Workshop Curriculum (90 min)

Facilitated by a certified Mindful Builds practitioner. CPD credits pending accreditation (expected Q2).

Appendix: Forced Issuance Flow