tinker-nomics

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).

Parametermath_rlGRPO on MATH / GSM8Kcode_rlGRPO on CodeContests / SWE tasksharbor_rlAgentic multi-turn terminal tasksswe_rlSWE-bench agentic RL (DeepSWE-style)osworld_rlGUI computer use in full VMs
ModelQwen3-8BQwen3-4B-Instruct-2507Kimi-K2-Thinking (1T MoE)Qwen3-32BGLM-4-9B (VLM)
AlgorithmGRPOGRPOGRPOGRPOGRPO
Turns / trajectory1 (single-turn)1–2 (max_turns=2)10 (max_turns=10)25 (avg, grows 18→25)15–50 (step-based)
max_tokens (per turn)51224,5768,192350 per turn1,024
max_trajectory_tokens51232,76832,768~20,000~63,488
Avg prompt (tokens)~200~512~512~1,024~4,000 (screenshot + a11y tree)
groups_per_batch (B)641288648
group_size (G)168484
Training steps~180~100~100~200~180–360
Length growth (est.)1.5x2.0x2.5x1.5x2.0x
Sandbox backendNoneSandboxFusion / ModalDaytona / ModalDocker (SWE-bench)Docker + QEMU VM
Avg sandbox time~45s~5 min~5 min~12–20 min
Sandbox timeoutstimeout=6s/testsandbox=600s, cmd=120s, grader=60ssession=300ssession=600s
Reward signalExact matchTest suite pass/failtest.sh verifierTest suite pass/failBinary (custom eval fn)
Cookbook sourceREADME exampleREADME exampleCLI defaultsDeepSWE / SkyRL-AgentComputerRL (arXiv 2508.14040)

math_rl

GRPO on MATH / GSM8K

The 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 tasks

Code 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 tasks

The 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 VMs

The 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.