Dividing the dollars by the steps shows where the tie actually comes apart. Opus works out to roughly USD 0.0152 per step and Gemini to roughly USD 0.0046, a ratio of about 3.3x on one loop iteration [4]. That is not the longer profile doing less per dollar: it is buying 87 more attempts at under a third of the unit price [1][4].
What a step buys depends on the harness. Junie takes an issue and a repository, then lets the model inspect files, search for symbols, edit code, run commands, and execute tests [6]. So a step is one inference round trip plus one tool call against your codebase. If that call is a symbol search, 87 extra of them cost seconds. If it runs a full test suite on your CI, the token bill is the smaller line item.
Transfer needs the same tool surface, since steps are counted against Junie's action set rather than the model's. It needs a similar context policy, because per-step cost tracks how much history gets resent each turn. And it needs a similar task mix: the JetBrains Research post cited in the writeup warns that gains may not transfer to other tasks even inside the same codebase, and that rankings move with task type [10]. The writeup reports steps and dollars for this pair while defining efficiency to also cover tokens, model calls, tool calls and seconds [8], so a reader outside JetBrains cannot turn the profile into a latency estimate.
The part worth copying is the failure taxonomy. A run can fail because the agent never found the relevant code, misread the cause, edited the wrong layer, implemented only part of the fix, or stopped without adequate validation [15]. Those are different bugs with different owners. A pattern of repeated searching points at repository navigation or tighter prompting [12]; a correct diagnosis attached to an incomplete patch points at implementation or task completion [13]. Resolve rate collapses all of that into a percentage of tests passed [5], and a percentage has no opinion about who pays for the run.
Patch scope is the other cost that lands on a person. Two patches can implement the required behavior and still differ in scope, complexity and fit: one edits a single relevant function, the other adds helpers, state, branches and unrelated files, and both go green [11]. The second one costs a reviewer an afternoon. Trajectory data is what lets you see it coming, because the trace shows whether the model localized the problem before editing, repeated the same searches, tested its assumptions, and kept the patch contained [7]. None of that requires access to the model's private reasoning [7]. It requires logging the tool calls you already make.
