Cursor Model Selection in 2026: When to Use Composer 2.5 Standard, Fast, or Frontier

The Cursor 3.0 article rested on an economic claim: orchestrating many agents amplifies error propagation faster than it amplifies useful output. Composer 2.5 breaks one input to that equation — the price of a model call just fell by an order of magnitude on the Standard tier. The rest of the equation held. This is what changed, and how to plan around it.

Six weeks after the 3.0 rewrite, the shape of Cursor's bet is clear. The 3.0 article framed the Agents Window, git worktrees, and the MCP ecosystem as the architecture of parallel autonomous agents. What's shipped since — releases 3.3, 3.4, and Composer 2.5 — is the part that makes that architecture economically serious: a proprietary model cheap enough that running ten agents in parallel stops being a budget decision, and cloud infrastructure that runs them outside your laptop, in your deployment topology, with enterprise governance attached.

The interesting question for anyone running an engineering org isn't whether this is impressive. It is. The question is whether cheaper, faster agents change the conclusion the 3.0 article reached — that the bottleneck is judgment, not generation. They don't. But they move the line, and where it moves to changes how you should route work, budget spend, and gate merges.

What shipped: the six-week timeline

The progression is coherent. The enterprise updates give admins spend and model governance; 3.3 gives you visibility into what's consuming your context budget; 3.4 moves agent execution into reproducible Dockerized environments that can span repositories; Composer 2.5 makes the model running inside those environments cheap. Each step lowers the marginal cost of dispatching an agent. That's the thesis Cursor is executing against — drive the per-agent cost toward zero and the parallel-agent workflow becomes the default rather than the experiment.

Composer 2.5: Kimi K2.5 Post-trained at Cursor Scale

Composer 2.5 is built on Moonshot AI's open-weight Kimi K2.5 checkpoint — the same base as Composer 2 — then post-trained at scale by Cursor's own team. Understanding what was changed, and how much, explains why the price could drop while the benchmark numbers held (Cursor, 2026a).

Cursor spent 85% of the total compute budget for this model on its own post-training pipeline — not on pretraining the base model. That pipeline included reinforcement learning with textual feedback, continued pretraining, and targeted training on 25× more synthetic coding tasks than Composer 2 used. One notable scheme: "feature deletion," in which a working feature is stripped from a codebase and the model must rebuild it with only the test suite as the reward signal. No human evaluation, fully automated verifiable reward. The model also received deliberate reward-hacking research to improve robustness on long unattended sessions — a real failure mode once agents run for minutes rather than seconds (Cursor, 2026a).

Benchmark results

These are Cursor-published numbers, so treat them as a signal to evaluate against, not a final verdict. CursorBench v3.1 is Cursor's internal suite of underspecified real-world tasks where no single right answer exists. The fact that Composer 2.5 leads Opus 4.7 on the task type most representative of actual agentic work — while matching it within fractions of a point on the external benchmarks — is the relevant signal (Cursor, 2026a).

The price break

Two pricing tiers ship with Composer 2.5. The distinction matters and most coverage glosses it.

The independent benchmark is the cleanest signal. Artificial Analysis's Coding Agent Index — which prices a fixed task mix end-to-end rather than per token — put Composer 2.5 in third place overall, behind only the highest-effort variants of Claude Opus 4.7 and ChatGPT 5.5 (Artificial Analysis, 2026). The index is a composite of SWE-Bench-Pro-Hard-AA, Terminal-Bench v2, and SWE-Atlas-QnA — a harder and more varied set than any single benchmark.

Cursor is on the cost-quality Pareto frontier for the first time. The prior Composer versions were competitive on cost but sat meaningfully behind on external evals. Composer 2.5 closes that gap to within statistical noise on two of the three benchmarks, which means the tier decision is genuinely about latency and spend trade-offs — not about quality sacrificed.

What this breaks in the 3.0 math

The 3.0 article assumed best-of-n — running one prompt across multiple agents — was a deliberate, costly choice reserved for high-stakes refactors. At Standard-tier prices, sampling the solution space across several parallel agents stops being a special occasion. Ten Composer-Standard candidates cost roughly what one Opus 4.7 candidate does. That genuinely lowers the generation side of the equation.

It does nothing to the review side. Cheaper generation does not make a diff easier to inspect, a security boundary easier to reason about, or a cross-service dependency easier to detect. Ten cheap candidates is ten things to review, not one. If your review capacity is fixed, lowering the cost of generation doesn't raise your throughput — it raises your queue. The leverage is in scaling review at least as fast as you scale generation.

A routing framework for technical leads

The operating-model shift is the real story, and it's where a tech lead earns their keep. A cheaper model isn't "use it for everything" — it's a routing decision, and the routing maps directly onto the task taxonomy the 3.0 article ended on: spec-clear, machine-verifiable work goes to the cheap model; judgment work stays with the frontier or stays with a human.

The rule of thumb worth internalising: a cheap model is only cheap if the resulting diff is scoped, testable, and easy to inspect. The moment you route work to Composer that produces a large, hard-to-review change touching trust boundaries, the token saving is dwarfed by the review and incident cost. Route on verifiability, not on confidence.

One way to encode this routing strategy is an agent-instructions file your Cursor rules inherit. Here's a minimal pattern:

# Agent Routing Policy
# This file is read by Cursor agents as a system instruction.

## Model selection

Use Standard tier (lower latency acceptable) for:
- Generating or expanding test files
- Scaffolding new files from an existing pattern
- Mechanical refactors (rename symbol, extract constant, update import paths)
- Documentation updates and inline comment additions
- Schema migrations matching a documented pattern

Use Fast tier (interactive, latency-sensitive) for:
- Multi-file feature work with a clear spec
- Iterative bug-fixing where you expect several rounds

STOP and ask a human for any task involving:
- Changes to authentication, authorisation, or session management
- Cross-service API contracts (adding / removing fields another service reads)
- Infrastructure or Dockerfile changes
- Any file in /secrets, /certs, or /.github/workflows

The pipeline: generate → gate → select

When parallel generation is cheap, the productive configuration becomes breadth-first: generate several candidates, let CI eliminate the broken ones, then select the best passing diff for human review. The pipeline below compresses what was a serial "write → review → iterate" loop into a parallel "generate many → gate hard → review one" loop.

The gate step is load-bearing. A CI pipeline that runs fast and covers the right things is now a core part of your agent infrastructure, not just your human developer workflow. Here's a GitHub Actions workflow that implements the key agent PR checks:

name: Agent PR Gate
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  agent-gate:
    runs-on: ubuntu-latest
    if: startsWith(github.event.pull_request.title, '[agent]')
    steps:
      - uses: actions/checkout@v4

      - name: Run test suite
        run: npm test --ci

      - name: Enforce diff size limit
        run: |
          FILES=$(git diff --name-only origin/main...HEAD | wc -l)
          if [ "$FILES" -gt 20 ]; then
            echo "Agent PR touches $FILES files — exceeds 20-file limit"
            exit 1
          fi

      - name: Block trust-boundary files
        run: |
          if git diff --name-only origin/main...HEAD | grep -qE \
            '^(\.github/workflows|secrets/|certs/|infra/)'; then
            echo "Agent PR touches a protected path — requires human author"
            exit 1
          fi

            # Bugbot integrates via GitHub webhook — configure in Cursor dashboard.
      # High-effort review is recommended for all agent-authored PRs.

The cost that didn't move

Cheaper inference helps exactly where the 3.0 article said agents already worked. It does nothing for the category where they fail: architecture decisions, security boundaries, cross-service consistency, performance at scale. Those failures aren't priced in tokens. A wrong architectural assumption costs the same to generate whether the model is Opus 4.7 or Composer-Standard, and it costs far more than either to detect and unwind. Lowering generation cost doesn't touch that line item — it just makes it a larger share of the total.

The self-driving experiment, read carefully

Cursor's own research is the best evidence for the limits. In February 2026 the team published "Towards self-driving codebases," describing an internal multi-agent system that ran for one continuous week and peaked at ~1,000 commits per hour across hundreds of agents and 10 million tool calls, with no human intervention once started. The project: building a web browser from scratch. It's a genuinely striking result (Cursor, 2026b).

It's also, read closely, the strongest argument for the 3.0 thesis — because of the trade-offs Cursor had to make to hit that throughput:

A thousand commits an hour is a generation rate. The relaxed-correctness policy is the verification tax made explicit. The disk-I/O wall is a reminder that your build system and monorepo structure are now performance-critical infrastructure for agents, not just for humans. Drive generation toward infinity and these three things don't shrink — they become the entire job.

The structural changes underneath the model

Three shifts in the six weeks matter more for enterprise adoption than the benchmark numbers.

Bugbot: review billed by the run

Bugbot moved from subscription to usage-based billing — effective at the next renewal after June 8 for existing customers (Cursor, 2026c). The $40/seat/month plan is replaced by per-run pricing with configurable effort levels.

This isn't a pricing footnote — it's Cursor monetising review as a metered service. The company that sells you the generation engine now also sells you the verification engine, by the run. Read against where the bottleneck actually sits, that's a clear-eyed bet on where the spend is going.

Cloud agents: real environments, not sandboxes

Release 3.4's cloud agents run in real deployment-topology environments, not sandboxes that approximate them. Dockerfile-based configuration, multi-repo support, environment version history with rollback, and build-scoped secrets mean an agent can operate against your actual stack. Crucially, build secrets are scoped to the build step and never reach the running agent — which closes the most common foot-gun in agent infra, an API key baked into a running container.

# Build stage: secrets available here via --mount, not in the final image
FROM node:22-slim AS builder
WORKDIR /app
COPY package*.json ./

# Secret is mounted at build time only — never written to a layer
RUN --mount=type=secret,id=NPM_TOKEN \
    NPM_TOKEN=$(cat /run/secrets/NPM_TOKEN) npm ci

COPY . .
RUN npm run build

# Runtime stage: only the compiled artifact, zero build-time credentials
FROM node:22-slim AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules

# Agent process has no access to NPM_TOKEN — it was never written here
CMD ["node", "dist/server.js"]

Hands-on reports are positive on caching: cached Dockerfile rebuilds dropped from around nine minutes to under two when only the application layer changed, collapsing the local Docker loop entirely. For a microservices org, the multi-repo support is the unlock — an agent confined to one repo can't reason across the services a real change spans. NVIDIA's scale shows what the underlying platform can carry: 30,000 developers using Cursor, committing 3× more code across a sprawling multi-repo codebase (Cursor, 2026d).

Governance: finally enough to matter

The May 4 enterprise updates added enough controls that "governed deployment" stops being theoretical. The key additions:

The trust surface expanded with the capability

Every one of these gains widens what an agent can touch, and the security model is still catching up. The clearest illustration is CVE-2026-26268, fixed in Cursor version 2.5 of the underlying application.

The enterprise governance controls above aren't optional polish for a regulated org — they're the mitigation layer for exactly this class of risk. Practical posture: pin versions and patch promptly (the agent runtime has shipped a double-digit count of CVEs across the 2025–2026 window). Govern MCP connections with explicit per-server approval. Scope credentials to the build step. And treat any repository you didn't author as untrusted input to the agent, not just to the human reading it.

The 3.0 article's "judgment stays expensive" now has a security corollary: trust boundaries stay expensive too.

The senior-engineer verdict, updated

The 3.0 article's conclusion was: delegate mechanical work to agents in worktrees, review the clean diffs, and keep tight control of architectural decisions. Composer 2.5 sharpens that rather than overturning it. When agent runs cost cents, the productive configuration tilts further toward "generate many scoped candidates, evaluate selectively" — the economics now favour breadth of generation in a way they didn't in April.

Cursor's own dogfooding is the proof of concept. The team reports that 35% of pull requests merged internally are now written by autonomous agents — but inside strong CI, a code-review culture, and real test suites. The agents work within the engineering process, not around it.

That caveat is the whole strategy. Ten cheap candidates is ten things to review, not one. The conductor that picks a winner is itself a judgment surface that can be wrong, and a confidently-wrong selection is more dangerous than no selection. Cheaper generation makes the front of the pipeline faster and the back of the pipeline busier.

The real constraint

Composer 2.5 is the most important thing Cursor has shipped since the 3.0 rewrite, and it changes the cost math in a real, independently-verified way. It does not change the conclusion. Generation got an order of magnitude cheaper — on the Standard tier. The judgment got no cheaper at all. There's just more of it to do, and a wider trust boundary to do it across.