Sample Workloads
Five reference workloads that span the RLVR landscape — from short single-turn math to long multi-turn agentic tasks and GUI-based computer use. These define the parameters we feed into the cost calculator.
Parameters sourced from tinker-cookbook example configs (README examples, not CLI defaults which use placeholder values).
| Parameter | math_rlGRPO on MATH / GSM8K | code_rlGRPO on CodeContests / SWE tasks | harbor_rlAgentic multi-turn terminal tasks | swe_rlSWE-bench agentic RL (DeepSWE-style) | osworld_rlGUI computer use in full VMs |
|---|---|---|---|---|---|
| Model | Qwen3-8B | Qwen3-4B-Instruct-2507 | Kimi-K2-Thinking (1T MoE) | Qwen3-32B | GLM-4-9B (VLM) |
| Algorithm | GRPO | GRPO | GRPO | GRPO | GRPO |
| Turns / trajectory | 1 (single-turn) | 1–2 (max_turns=2) | 10 (max_turns=10) | 25 (avg, grows 18→25) | 15–50 (step-based) |
| max_tokens (per turn) | 512 | 24,576 | 8,192 | 350 per turn | 1,024 |
| max_trajectory_tokens | 512 | 32,768 | 32,768 | ~20,000 | ~63,488 |
| Avg prompt (tokens) | ~200 | ~512 | ~512 | ~1,024 | ~4,000 (screenshot + a11y tree) |
| groups_per_batch (B) | 64 | 128 | 8 | 64 | 8 |
| group_size (G) | 16 | 8 | 4 | 8 | 4 |
| Training steps | ~180 | ~100 | ~100 | ~200 | ~180–360 |
| Length growth (est.) | 1.5x | 2.0x | 2.5x | 1.5x | 2.0x |
| Sandbox backend | None | SandboxFusion / Modal | Daytona / Modal | Docker (SWE-bench) | Docker + QEMU VM |
| Avg sandbox time | — | ~45s | ~5 min | ~5 min | ~12–20 min |
| Sandbox timeouts | — | timeout=6s/test | sandbox=600s, cmd=120s, grader=60s | session=300s | session=600s |
| Reward signal | Exact match | Test suite pass/fail | test.sh verifier | Test suite pass/fail | Binary (custom eval fn) |
| Cookbook source | README example | README example | CLI defaults | DeepSWE / SkyRL-Agent | ComputerRL (arXiv 2508.14040) |
math_rl
GRPO on MATH / GSM8KThe simplest RLVR workload: single-turn math problem solving. The model generates short chain-of-thought completions (~512 tokens), and reward is binary exact-match against ground truth answers. No sandbox, no multi-turn, no environment interaction.
This is the bread-and-butter of RLVR research — MATH and GSM8K are the most commonly used benchmarks. The tinker-cookbook math_rl recipe achieves 0.768 MATH accuracy at ~180 steps with Qwen3-8B.
Completions grow ~1.5x over training as the model learns to produce longer chain-of-thought reasoning. The cost structure is dominated by rollout token generation (short completions but very large batch × group).
Token gen / step
524K
64 × 16 × 512
Rollouts / step
1,024
64 × 16
Bottleneck
Rollout gen
Memory-bound decode
GPU idle
None
No sandbox to wait for
Cost drivers
- •Dominated by rollout token generation — 1,024 concurrent sequences per step
- •Short completions (512 tok) mean the KV cache stays small, so batched decode is efficient
- •No sandbox cost — reward is exact-match string comparison
- •Length growth is moderate (1.5×) since chain-of-thought doesn't explode for math
- •Large batch (64 prompts × 16 rollouts = 1,024) gives strong gradient signal per step
code_rl
GRPO on CodeContests / SWE tasksCode generation with sandbox verification: the model writes a solution, then a sandbox compiles and runs it against a hidden test suite. Reward is binary pass/fail. The cookbook uses Deepcoder tasks and CodeContests with SandboxFusion (local Docker) or Modal as the sandbox backend.
The cookbook sets max_turns=2 — the model gets one attempt plus one optional retry. Completions are long (~24K tokens for full programs with chain-of-thought reasoning). Each test gets a 6-second timeout, keeping sandbox execution fast.
Length growth is 2× as the model learns to write longer, more elaborate solutions with detailed reasoning. The SkyRL-Harbor integration validates with CodeContests as the reference benchmark.
Token gen / step
25.2M
128 × 8 × 24,576
Rollouts / step
1,024
128 × 8
Bottleneck
Token gen + sandbox
Long completions + test execution
Sandbox time
~45s/rollout
Compile + run tests
Cost drivers
- •Long completions (24K tok) dominate cost — 48× more tokens per rollout than math_rl
- •Sandbox cost is small per-rollout (~$0.001 Modal CPU) but adds up: 1,024 rollouts/step × 100 steps = $140
- •GPU idle time from sandbox: ~45s/step × 100 steps = 1.25h of idle (sync RL). Async can mostly hide this
- •2× length growth means late-training steps generate twice the early-training token volume
- •test_timeout=6s per test keeps sandbox fast; the model's code generation dominates wall-clock
harbor_rl
Agentic multi-turn terminal tasksThe most complex RLVR workload: multi-turn agentic interaction with a sandboxed terminal. The model iteratively issues bash commands (max_tokens=8192 per turn), observes output, reasons, and issues more commands — up to 10 turns per trajectory with a 32K token cap.
This is the SkyRL + Harbor integration. Harbor manages sandbox lifecycle (Daytona or Modal), the agent loop, and reward verification via test.sh scripts. SkyRL handles GRPO training. Each Harbor task is a simple directory: instruction.md + Dockerfile + test.sh. Tasks span SWE, sysadmin, security, data science — anything verifiable in a terminal (TerminalBench).
The cookbook defaults to Kimi-K2-Thinking (1T total params, 32B active MoE) — a frontier model requiring 70+ H100s or 30+ B200s for inference. Sandbox timeouts are generous: 600s session, 120s per command, 60s for grading. This is where managed infrastructure shines: you pay per token, not per GPU.
Length growth is 2.5× — the highest of all workloads. Growth comes from two compounding sources: the model learns to use more turns (SkyRL-Agent: turns grew 18→25, +39%) and produces longer responses per turn. The 32K trajectory cap provides a hard ceiling. The SkyRL blog highlights "high variance in rollout times" and "stragglers that dominate batch completion" as key systems challenges.
Token gen / step
655K
8 × 4 × 20,480
Rollouts / step
32
8 × 4 (small batch — big model)
Bottleneck
Sandbox idle
~5 min/trajectory of env execution
Sandbox time
~300s/rollout
10 turns × ~30s/turn
Cost drivers
- •Sandbox idle dominates self-hosted cost: 300s/step × 100 steps = 8.3h of GPU idle time (sync RL)
- •Async RL is essential — without it, GPUs sit idle ~60% of wall-clock waiting for sandbox
- •Model size (1T params) requires massive GPU allocation just for inference: 70× H100 or 30× B200
- •Small batch (32 rollouts/step) due to model size — less gradient signal per step than math/code
- •2.5× length growth means token costs nearly triple between early and late training
- •Multi-turn means prompt tokens grow per turn (observation history), increasing prefill cost
- •Straggler problem: variable-length trajectories mean the slowest rollout in each batch determines step time
swe_rl
SWE-bench agentic RL (DeepSWE-style)Multi-turn agentic SWE-bench RL: the model acts as a coding agent — reading files, editing code, running tests — over 25 turns per trajectory. Based on the DeepSWE (Agentica) setup using a 32B model, matching the batch/group configuration used by both DeepSWE and SkyRL-Agent (B=64, G=8).
Unlike harbor_rl, the agent has longer conversations with substantial tool output at each turn (~750 observation tokens per turn from bash/grep/cat output). The model produces ~350 output tokens per turn. Conversation context grows quadratically — each turn prefills all prior turns.
This workload highlights the multi-turn prefill cost problem. On Tinker, prefill is billed per rollout (not per group), so the G=8 rollouts sharing a prompt each pay full prefill. With 25 turns of growing context, prefill dominates total cost. Self-hosted with KV caching pays ~8% of raw prefill compute.
No tinker-cookbook recipe exists for this workload — parameters are derived from DeepSWE (Agentica, 2025) and SkyRL-Agent (arXiv 2511.16108). DeepSWE used Qwen2.5-Coder-32B-Instruct with 512 Docker containers per RL iteration across 1,000+ CPU cores. SkyRL-Agent observed turns growing from 18→25 over training.
Token gen / step
~4.5M
64 × 8 × (350 × 25)
Rollouts / step
512
64 × 8
Bottleneck
Prefill + sandbox
Quadratic context + Docker exec
Prefill cost share
~87% (Tinker)
No prefix caching in billing
Cost drivers
- •Multi-turn prefill dominates Tinker cost: 25 turns × growing context × G=8 × per-rollout billing = 87% of total
- •With prefix caching in billing (planned), prefill drops 8× — total Tinker cost from $39.7K to $9.4K
- •Self-hosted benefits from KV caching: 92% cache hit rate → pays ~8% of raw prefill compute
- •Docker sandbox: ~5 min per trajectory, 512 rollouts/step — requires 500+ concurrent containers
- •32B dense model needs 8× H100 minimum — larger than math/code but much smaller than harbor_rl's 1T MoE
- •1.5× length growth is modest (agentic mode already models turn growth separately)
- •50% failure rate early in training — failed trajectories run 50% longer, wasting tokens
osworld_rl
GUI computer use in full VMsThe most infrastructure-heavy RLVR workload: multi-step GUI interaction inside full Ubuntu desktop VMs. The agent observes screenshots (1920×1080), decides mouse/keyboard actions via a VLM, executes them, and repeats for 15-50 steps per episode. Reward is binary success/failure evaluated by 134 task-specific functions (file diffs, pixel comparison, perceptual hashing).
OSWorld (NeurIPS 2024) provides 369 tasks spanning LibreOffice, GIMP, web browsing, system administration, and cross-application workflows. Unlike terminal-based benchmarks, the agent must interpret visual state — making this inherently multimodal and much more expensive per step (screenshot encoding dominates prompt tokens).
The key tradeoff vs. simpler benchmarks: environment overhead completely dominates. Each rollout requires a full QEMU-based VM (~25 GB image), application initialization (LibreOffice alone takes ~1 min on first boot), and screenshot capture at every step. ComputerRL ran 1,024 parallel Docker containers to make training feasible, and still reported system freezes and network bottlenecks under load.
Sparse binary rewards with no intermediate signal make credit assignment across 15-50 steps extremely challenging. ComputerRL found that extended RL training causes entropy collapse — the model degenerates to repetitive actions — requiring a novel 'Entropulse' strategy alternating RL with SFT to maintain exploration. Per-step latency grows linearly with context (accumulated screenshot history), so later steps are ~3x more expensive than initial ones.
Token gen / step
~33K
8 × 4 × 1,024
Rollouts / step
32
8 × 4 (VM-bound, not GPU-bound)
Bottleneck
VM overhead
12-20 min per episode
Observation cost
~4K tok/step
Screenshot + a11y tree encoding
Cost drivers
- •VM environment dominates: each rollout needs a full Ubuntu desktop VM (QEMU), ~25 GB image, with app-specific initialization
- •Episode length (12-20 min wall-clock) dwarfs token generation time — GPUs sit idle waiting for VM interaction
- •Multimodal input: screenshots at 1920×1080 are expensive to encode; prompt length grows linearly per step as observation history accumulates
- •1,024 parallel VMs required for reasonable training throughput — massive infrastructure overhead (ComputerRL reported instability at this scale)
- •Sparse rewards: binary success/failure at episode end. No intermediate signal across 15-50 steps makes learning extremely sample-inefficient
- •Entropy collapse risk: RL training degenerates without periodic SFT recovery (Entropulse). Adds SFT data pipeline as extra dependency
- •~10% of tasks rely on live internet data, introducing non-deterministic reward noise
Cookbook defaults vs. our estimates
The tinker-cookbook CLI defaults use placeholder values (e.g. max_tokens=5) that are meant to be overridden. The parameters in the table above come from the README example commands— the configs that actually produce good results:
- •math_rl: README MATH example —
group_size=16 groups_per_batch=64 learning_rate=2e-5 max_tokens=512 - •code_rl: README example —
group_size=8 groups_per_batch=128 learning_rate=4e-5 max_tokens=24576 - •harbor_rl: CLI defaults match —
groups_per_batch=8 group_size=4 max_tokens=8192 max_turns=10 - •swe_rl: No cookbook recipe — derived from DeepSWE (Qwen2.5-Coder-32B, B=64, G=8) and SkyRL-Agent (turns 18→25)
Length growth factors (1.5×, 2×, 2.5×) and sandbox timing (~45s, ~5 min) are our estimates based on published data (SkyRL-Agent, DeepSeek R1, Earl) — not directly from the cookbook. These will be replaced with measured values as we accumulate real run data.
How these feed into the calculator
Each workload maps directly to a preset in the cost calculator. The parameters above become the inputs: model size, batch size, completion length, sandbox backend, and length growth. The cost model then computes token counts, throughput, and dollar costs for both Tinker and self-hosted.
We plan to add real training run data here as we accumulate results — actual wall-clock times, token counts, and costs from running these workloads on Tinker and on rented GPUs.