Agent-authoring-cost study

Agents Are More Token Efficient with Flyte v2

A coding agent reaches a working pipeline in 1.8× fewer tokens on Flyte v2 — and solves patterns Flyte v1 cannot express at all.

48 real subagent trajectories | claude-sonnet-5, fixed across both arms | live oracle · real cluster · no simulation

AbstractCoding agents now author most Flyte pipelines; the DSL a human rarely reads is a DSL an agent must get exactly right on every turn. We benchmark that authoring cost directly: the same Claude Code subagent, same model, same turn budget, primed with an equal-token-budget cheatsheet for Flyte v1 (flytekit) or Flyte v2 (flyte), writes a pipeline for each of 12 framework-agnostic specs against a real cluster, graded by a live oracle — 48 trials total, no simulation. On the nine specs both frameworks can express, v2 reaches a passing run in 1.78× fewer tokens and a 5× lower iteration count, with essentially every v1 failed iteration (54 of 54 logged, vs. v2's 1) being framework-mechanics friction rather than a logic bug. On three specs that require catching a live task failure as control flow, racing concurrent tasks with cancellation, or checkpointing an in-process loop, v1 recorded 0% success (6/6 infeasible) while v2 solved 6/6 — not an efficiency gap but a capability one.

Read the full paper (PDF) ↗

1.78×
fewer tokens to a passing run, groups A+C
lower median iteration count to green
0/6
v1 successes on live, value-dependent control flow
54 vs 1
framework-mechanics failures logged, v1 vs v2
Key results

What the numbers show

Every chart below is drawn straight from the measured data in the paper — hover any bar or point for the exact value.

Mean tokens to first passing run, by spec groupFig. 1 · tokens to green
Flyte v1Flyte v2
0k 23k 45k 68k 90k A — core mechanics 71k tok 41k tok B — v2-only capability INFEASIBLE 53k tok C — applied ML 76k tok 42k tok

Groups A and C: v2 costs roughly half the tokens of v1 at identical 100% success. Group B has no v1 bar — every one of 6 trials recorded infeasible, never producing a run to measure a token count for.

Tokens to green, all nine head-to-head specsFig. 2 · per-spec consistency
Flyte v1Flyte v2
0k 24k 48k 71k 95k etl 67k tok 41k tok fanout_map 63k tok 39k tok conditional 73k tok 40k tok dyn_fanout 71k tok 38k tok fit_eval 81k tok 44k tok etl_join 76k tok 44k tok train_clsf 84k tok 44k tok hpo 73k tok 41k tok batch_inf 70k tok 39k tok

The v1/v2 ratio holds in a tight 1.6–1.9× band regardless of spec content — ETL, ML training, hyperparameter search, or plain control flow all show the same order of gap.

Failed run→fix iterations, by error class (groups A+C)Fig. 3 · error taxonomy
Framework-mechanicsLogic
0 15 30 45 60 Flyte v1 52 2 Flyte v2 1 0

Of v1's 54 logged failures, 52 were framework-mechanics friction — toolchain version mismatches, silent non-packaging, unversioned entity collisions — not conceptual mistakes about the pipeline.

See it for yourself

Spin up a real Flyte cluster in minutes and run the same workloads on your own hardware. No infra to provision, no YAML to write first.