Article

Cognition’s SWE-2 Trains Devin to Spend Effort Where It Pays

Cognition’s SWE-2 turns Kimi K3 into a cost-aware Devin worker. Here’s how to read its benchmarks, effort levels and Terminal-Bench 4 gap.

Cognition SWE-2 cost and benchmark curves across medium, high and max effort inside Devin

Cognition has started training the budget decision into the coding model itself. On September 10, the company released SWE-2 in Devin Desktop and CLI, with Web and Fusion still rolling out. Its headline configuration reaches a 50.0 FrontierCode 1.1 Main score at a reported $1.1761 per benchmark task—less than one score point behind Fable 5.1 medium in Cognition’s launch snapshot, at roughly 64% lower cost.

The tempting conclusion is that Devin now has a cheap frontier model. The evidence supports a narrower and more useful claim. SWE-2 is a coding-focused post-training of Kimi K3 whose medium, high and max policies were learned together under a reward that penalizes inference dollars and rollout time. Cognition is optimizing how an agent spends effort, not merely letting users request a longer answer.

That distinction matters because the same launch table contains the product boundary. SWE-2 scores 27.3% on Terminal-Bench 4, while Fable 5.1 reaches 55.8% and GPT-6 Astra reaches 57.9%. A model can be economical on repository engineering and still be the wrong worker for a broader terminal task. SWE-2 therefore looks strongest as a specialized execution lane inside Devin’s multi-model system, not as proof that every external frontier model can be removed.

The business implication is bigger than a leaderboard rank. An agent company can begin with someone else’s base model, own the reward function and verifiers, ship the result inside its harness, and keep an escalation route for work outside the model’s best distribution. The evaluation implication is equally important: compare accepted engineering changes, including review and rework, rather than turning vendor benchmark dollars into an imaginary customer tariff.

SWE-2’s strongest claim is not “frontier intelligence for less.” It is that effort can become a learned economic policy—and that the harness owner can improve the model by improving what counts as a correct, efficient job.

The launch in six facts, without the marketing blur

  • Lineage: SWE-2 is post-trained from Moonshot AI’s Kimi K3. It is not a newly pretrained Cognition foundation model.

  • Scale: Kimi K3’s technical report identifies 2.8 trillion total parameters and 104 billion active parameters. Those are base-model facts, not a separately published SWE-2 serving specification.

  • Control: Cognition jointly trained medium, high and max effort levels with different cost penalties rather than presenting effort as only an output-token ceiling.

  • Product: Desktop and CLI availability was announced immediately; Web and Fusion were still rolling out at publication time.

  • Economics: The dollar figures in Cognition’s charts are mean benchmark inference cost per task. They are not SWE-2 API prices, Devin subscription totals or guaranteed savings on production tickets.

  • Access boundary: No public standalone SWE-2 weights, derivative license or raw customer-facing inference endpoint was found in the official sources reviewed. Devin’s public API manages agent sessions, which is a different contract.

The Kimi K3 report matters because it prevents a common category error. K3 supplies enormous pretrained and agentic-coding capability; Cognition supplies additional environments, reward design, verifiers and delivery inside Devin. You should not automatically copy K3’s context window, active-parameter behavior or deployment assumptions into an SWE-2 spec sheet.

The predecessor also makes clean causal storytelling impossible. SWE-1.7 used Kimi K2.7 Code, while SWE-2 changes both the base and the post-training recipe. The improvement is a system result, not an isolated experiment proving that one reward equation caused every gain.

Effort is now a policy with a price attached

Cognition describes the training objective in compact form:

Rₑ = S − λₑC

S = task success
C = weighted mix of inference dollars and rollout time
λₑ = effort-specific cost penalty

The interesting term is not success. Every coding model trainer wants more successful rollouts. It is λₑ: each effort level gets a penalty tied to the local slope of the base model’s cost-performance frontier. A penalty that is too weak lets an effort level overspend; one that is too strong can make “high” imitate “medium” without buying more capability. Training the levels together is an attempt to teach distinct spending behavior rather than bolt three limits onto one policy afterward.

This is an economic policy only in a bounded sense. The objective encodes Cognition’s training-time conversion among success, money and elapsed rollout time. It does not reveal a universal value for developer time, outage risk or a missed deadline. If serving prices, cache behavior or tool latency change, the learned tradeoff can drift away from a customer’s production frontier.

The exact static launch chart data makes the marginal tradeoffs visible:

Model / effort

FrontierCode score

Blocker pass

Mean launch $/task

SWE-2 medium

43.09

48.33%

$0.3712

SWE-2 high

47.20

52.35%

$0.7813

SWE-2 max

50.00

55.47%

$1.1761

Fable 5.1 medium

50.91

55.45%

$3.2845

GPT-6 Astra max

53.26

58.75%

$4.4850

Source: Cognition’s SWE-2 launch asset for FrontierCode 1.1 Main. These matched score-and-cost pairs belong to the same static snapshot. “Blocker pass” and “score” are different fields.

Max is excellent marketing and a poor automatic default. Moving from high to max buys 2.80 score points while mean task cost rises about 50.5%. Medium to high buys 4.11 points while cost more than doubles. The right selection depends on the expected value of the task and the cost of a failed attempt, not which row has the largest score.

The comparison with Fable is genuinely interesting when kept inside its frame: SWE-2 max is 0.91 points lower than Fable 5.1 medium and costs about 64.2% less in this snapshot. SWE-2 max also costs about 26.2% as much as Astra max, while trailing by 3.26 points. Neither ratio says your Devin bill will fall by the same percentage. It says Cognition found a favorable point on one vendor-run task distribution.

A 50.0 score is not a 50% merge rate

FrontierCode’s metric needs one sentence of discipline every time it appears. Cognition’s benchmark methodology first checks blocker criteria. A run that fails a blocker receives zero score; a run that clears the blockers is then graded with a weighted rubric covering correctness, regressions, scope, tests and code quality. That is why the chart can show SWE-2 max at a 55.47% blocker pass rate and a 50.00 score.

So 50.0 does not mean that 50 of 100 pull requests were ready to merge. It is not a human acceptance rate, deployment-success rate or probability that a randomly selected company ticket will close. The metric is more informative than test passing alone, but production authority remains a separate decision.

FrontierCode 1.1 also changed how internet use and grading work. The July revision allows legitimate internet access, detects consultation of solution-bearing sources, demoted overly strict blockers after an audit and retired a noisy subset. That is healthy benchmark maintenance. It also means task-set version and evaluator version belong beside every score.

Four benchmarks tell two different stories

Cognition’s headline table uses each model’s reported best configuration. Read horizontally and SWE-2 looks close to the leaders on repository benchmarks. Read the final row and its specialization becomes obvious.

Model

FrontierCode 1.1 Main

DeepSWE 1.1

Terminal-Bench 2.1

Terminal-Bench 4

SWE-2

50.0%

73.0%

92.8%

27.3%

Kimi K3

44.2%

68.5%

88.3%

21.5%

Grok 4.6

48.0%

67.5%

88.4%

20.3%

Fable 5.1

50.9%

67.4%

91.4%

55.8%

GPT-5.6 Sol

47.5%

72.7%

88.8%

37.3%

GPT-6 Astra

53.3%

74.1%

89.9%

57.9%

SWE-1.7

42.0%

37.7%

81.5%

7.6%

Source: Cognition’s September 10 launch table. These are vendor-assembled best-effort results with mixed evaluation provenance, not a uniform independent rerun.

The 92.8% and 27.3% values should not be narrated as a collapse on the same exam. Terminal-Bench 4.0 is a breaking task-and-resource revision published on August 26. It uses an eight-hour timeout, removes eight tasks, fixes nineteen and spans 66 tasks including CAD, formal proofs, scientific computing, databases and web engineering. The maintainers explicitly require reruns rather than score carryover.

But the gap still matters. On this broader distribution SWE-2 trails Astra by 30.6 points and Fable 5.1 by 28.5. We cannot infer which specific capability causes the difference, yet we can infer a deployment rule: a repo-tuned worker needs an escape hatch when the work turns into unfamiliar terminal problem solving.

Terminal-Bench 4 is not an embarrassing footnote. It is the evidence that turns a benchmark article into a routing strategy.

Model, harness, effort and rate card travel together

Appendix A says Cognition imports public results where available and otherwise evaluates models in their associated harnesses, selecting the best reasoning effort. The machine-readable FrontierCode launch asset identifies SWE-2 with Devin, Kimi K3 with mini-swe-agent, SWE-1.7 with chisel, OpenAI models with Codex and Fable with Claude Code. In the DeepSWE launch asset, SWE-2 uses chisel while the external comparators use mini-swe-agent.

That is not automatically unfair. A model-plus-native-harness comparison can approximate the product a buyer will actually use. It simply answers a different question from a controlled model comparison. The result blends checkpoint quality, prompting, context management, tool protocol, retry policy and effort selection. A 73.0 versus 72.7 result across different stacks is not enough to declare a statistically meaningful model win.

The benchmark owner’s DeepSWE v1.1 method evaluates committed patches in clean verifier containers. Its public runner uses mini-swe-agent, and the September 3 board did not yet include SWE-2. It did include Gemini 3.8 Flash high at 74% ±1% and $2.36 per task. That omitted row does not disprove Cognition’s chart; it shows why a selected launch comparison is not the whole market.

There is also a useful contrast with RohitAI’s analysis of Gemini 3.8 Flash. Cheap Flash inference can afford more steps. Cognition says SWE-2 medium takes fewer detours: 58% fewer turns than SWE-1.7, an 81% lower FrontierCode task cost and a median first real edit at 18 steps instead of 48. Cheap steps and fewer steps are different paths to agent efficiency. Build time, tool latency and reviewer attention decide which one wins in your workflow.

A Pareto frontier can move without a new model

Cost charts have a mutable axis. The static launch asset prices Sol max at $6.2938 per FrontierCode task and Astra max at $4.4850. The live FrontierCode dataset observed for this article instead shows $5.1898 and $4.5860. SWE-2 max remains $1.1761 in both. The launch comparison is valid as a dated matched snapshot; presenting its comparator prices as timeless would not be.

Every internal evaluation result should therefore preserve a receipt:

model + checkpoint
harness + version
effort + retry policy
task-set + evaluator
price snapshot + token accounting
final review decision

This is the cost variable teams often forget: the frontier can move because a rate card changed, even if no model generated a single new token.

The compounding asset may be the verifier

Cognition says it tripled its reinforcement-learning environments, broadened repository coverage and added more instruction-following constraints. More rollouts help, but the sharper disclosure is how earlier SWE-2 checkpoints were used to find verifier mistakes. A checkpoint can expose false positives that reward a broken patch and false negatives that reject a valid one; repairing those graders improves the signal for later training.

That loop has compounding value. Better models probe more edge cases. Those edge cases reveal weaknesses in the judge. A repaired judge creates cleaner rewards, which can produce a better model. The scarce asset is not merely a pile of generated code. It is an increasingly accurate definition of acceptable engineering work.

model checkpoint → difficult rollout → verifier failure
        ↑                                  ↓
  cleaner reward ← repaired environment and rubric

This is also where precision about data matters. The documented loop is training rollouts, curated environments, product feedback and verifier repair. The launch does not establish that private customer repositories or customer telemetry are automatically used for training. A plausible data-flywheel story must not be upgraded into an unsupported privacy claim.

For agent companies, verifier ownership can be more defensible than exclusive access to a base model. Cognition can inherit capability from Kimi K3, add its own success-and-cost definition, and deliver the result through Devin. That creates supplier leverage and product differentiation without proving complete independence: the base comes from Moonshot, and harder work can still route to external models.

Throughput has three clocks, not one

The infrastructure appendix reports 10–20% improvements in rollout tokens per minute per GPU and tokens per second per request from prefill batching, while acknowledging increased time to first token. Cognition also reports 15% longer accepted speculative-decoding draft sequences after training and updating a DSpark draft model with SpecForge.

Those are training-serving measurements, not a customer promise for interactive SWE-2 speed. They illustrate why “faster” needs three clocks: first-token latency, generation throughput and completed-task time. Fewer tool turns may improve the third even if batching worsens the first. A team that measures only tokens per second can miss the improvement; a team that measures only the first edit can reward premature changes.

Routing is the product boundary, not a concession

Cognition already describes Devin Fusion as a multi-model harness with persistent main-agent and sidekick contexts plus dynamic mid-session routing. SWE-2 is rolling into that architecture. The TB4 result gives the router a concrete job: keep economical, repo-shaped execution on the specialized lane and escalate when the task distribution changes.

A sensible starting policy would look like this. It is a builder recommendation, not a claim about Devin’s undisclosed production router:

Task signal

First lane to test

Escalate when

Non-negotiable check

Bounded bug fix with clear tests

SWE-2 medium

Verification fails or scope expands

Clean CI plus diff review

Multi-file feature or migration

SWE-2 high

Architecture remains ambiguous

Plan approval and staged commits

High-value, hard repo task

SWE-2 max or paired frontier run

Marginal effort stops paying

Independent judge and human acceptance

Broad or unfamiliar terminal work

External frontier / Fusion route

Capability mismatch persists

Sandbox, timeout and least privilege

The important move is to classify failure instead of retrying every task at more SWE-2 effort. A missing dependency, unclear requirement, verifier defect and out-of-distribution capability gap need different responses. Max is not a universal repair button.

This extends RohitAI’s Astra escalation-model argument: the frontier model is most valuable where its incremental success probability exceeds its incremental cost. SWE-2 creates a new candidate for the economical execution lane. Terminal-Bench 4 supplies a reason to keep the escalation lane alive.

Run a review-inclusive pilot, not a leaderboard bake-off

The unit that matters to an engineering team is an accepted change. A useful cost measure includes the expenses the benchmark chart does not:

accepted_change_cost =
  (model + tools + sandbox + retries + reviewer time + rework)
  ÷ accepted changes

This deliberately keeps benchmark dollars per task separate from actual billing. Devin plans, quotas, shared credits, virtual-machine usage, network tools and post-promotion terms are different units. The pricing page checked for this article advertises promotional SWE-2 use in Desktop and CLI through October 10 under paid-plan features. Treat that as a bounded evaluation window, not a zero all-in agent bill or a published long-term SWE-2 tariff.

  1. Stratify real work. Sample bounded fixes, multi-file features, migrations and broad terminal tasks. Freeze repository commits and acceptance criteria.

  2. Run paired trials. Use the same task, environment, tools and time budget for SWE-2 medium, at least one higher effort and your current baseline. Repeat enough runs to see variance.

  3. Log the full receipt. Record requested and effective model, harness version, effort, steps, token categories, tool and sandbox spend, retries, wall time and pricing date.

  4. Verify independently. Run tests in a clean environment. When the agent writes a regression test, check that it fails on the original bug and passes on the patch. Keep normal review and approval boundaries.

  5. Score the reviewer’s outcome. Track accepted, accepted after edits, rejected and escaped-defect outcomes, plus review minutes and rework. A benchmark rubric cannot authorize a merge.

  6. Tune routing from failures. Choose effort and escalation thresholds from task value and failure cost. Re-evaluate after model, harness, verifier, serving or rate-card changes.

The 18-step first-edit median is worth monitoring, not copying into an objective. An early edit can signal focus, or it can signal that the agent changed code before understanding the repository. Pair time-to-first-edit with final coverage, diff scope and reviewer confidence.

Independent review matters even when the model writes its own tests. As RohitAI argued when Copilot reviews gained approval power, benchmark trust and production authority are separate boundaries. The generator, its reward grader and the identity allowed to merge should not quietly collapse into one system.

RohitAI’s read: what compounds after this launch

SWE-2 is evidence that vertical integration in coding agents does not require pretraining every layer. Cognition can use an open-weight Kimi base, specialize behavior around repository work, improve the verifiers, optimize the serving path and expose the result through a product that can still route elsewhere.

The evidence supports three strategic interpretations. These are RohitAI’s read, not claims Cognition made in the announcement.

  • Post-training as a procurement hedge. Owning the worker policy gives an agent company more control over cost and behavior even when it still depends on a base-model supplier and external frontier routes.

  • Effort as a service target. Users should eventually ask for a budget, latency or success target; the harness should choose effort. A raw medium/high/max switch is an intermediate interface.

  • Verifier ownership as a compounding advantage. A repaired judge improves future training and makes failures more legible. That loop may transfer across successive bases better than any one checkpoint.

FAQ

What is Cognition SWE-2?

SWE-2 is Cognition’s coding-focused post-training of Moonshot AI’s Kimi K3 base for use inside Devin. Cognition reports medium, high and max effort policies, new training environments, cost-aware rewards and verifier improvements.

Is SWE-2 open weight or available through a standalone model API?

No public SWE-2 weights, derivative license or raw inference endpoint were located in the official launch and documentation reviewed for this article. Cognition announced access through Devin product surfaces. Its public API is an agent-session API, not evidence of a standalone SWE-2 model service.

Which SWE-2 effort level should builders use?

Start by testing medium on routine, bounded repository tasks; compare high or max where task value justifies the marginal cost. The launch chart shows clear aggregate gains with effort, but also steep cost increases. Your own acceptance and review data should choose the default.

Is SWE-2 cheaper than Fable 5.1 or GPT-6 Astra?

In Cognition’s static FrontierCode launch snapshot, SWE-2 max has a lower mean inference cost per task than the matched Fable 5.1 medium and Astra max points. That is a benchmark result, not a retail token rate or guaranteed bill comparison. Harnesses and live comparator prices also differ.

Does SWE-2 replace external frontier models in Devin?

The evidence argues for routing, not replacement. SWE-2 is competitive on Cognition’s repo-oriented comparisons and much weaker than Fable 5.1 and Astra on the reported Terminal-Bench 4 row. Cognition’s Fusion architecture is explicitly multi-model.


The useful way to read SWE-2

Cognition did not win every row, disclose every serving detail or establish an independent universal ranking. It did something more strategically coherent: it turned a huge open base into a Devin-native worker, trained effort levels against a cost-and-time objective, and used model failures to improve the verifiers that produce the next round of rewards.

That makes SWE-2 a test of whether the agent company can own the economics of execution without pretending one model should do everything. The launch snapshot says the answer may be yes for a substantial band of repository work. Terminal-Bench 4 says the band has edges. Mixed harnesses say the size of that band still needs independent measurement.

Builders should use the release accordingly: run a bounded pilot, preserve the model-and-harness receipt, measure accepted-change cost, keep independent review, and route broad failures instead of spending max effort blindly. The best outcome is not the highest dot on Cognition’s chart. It is a system that knows when SWE-2 is the economical worker—and when it is time to call someone else.