Cursor as a Top-Tier Agent Harness: Composer 2.5, Cloud BYOA, and How It Compares to the Models on Critique

PART ONE — WHY CURSOR IS A HARNESS, NOT “JUST A MODEL”

Teams argue about model leaderboards. Staff engineers argue about agent harnesses: Does the loop survive 40 minutes? Does it respect the PR branch? Does it recover from a failed test without rewriting half the repo? Cursor’s moat is the second conversation. The IDE, CLI, Cloud Agents, and the TypeScript SDK all expose the same conceptual object — an Agent with durable state, Runs per prompt, streaming tool events, and cloud VMs that clone your repository.

Critique does not try to replicate that harness inside our sandboxes for Cursor BYOA. We already have Remedy when you want Critique-managed OpenCode on E2B. Cursor BYOA is for orgs that standardized on Cursor execution: same billing relationship, same agent UX in cursor.com/agents, and Composer tuned for the tool schema Cursor actually ships.

PART TWO — COMPOSER 2.5: SPECS AND TRAINING STORY

Composer 2.5 shipped May 18, 2026 as Cursor’s in-house agentic coding model. Public materials describe it as building on Composer 2, with more reinforcement learning on long-horizon coding tasks, better effort calibration (when to keep going vs stop), and stronger tool selection and intent understanding inside Cursor’s agent loop.

The base checkpoint is widely reported as Moonshot’s open Kimi K2.5 lineage — the same architectural family as Kimi K2.6 on Critique’s catalog. Cursor’s differentiation is post-training: Cursor states Composer 2.5 trained on roughly 25× more synthetic tasks than Composer 2, with harder synthetic problems generated dynamically as the model improved (so “easy” tasks did not dominate RL). Third-party summaries also cite a large fraction of total training compute going to Cursor’s own RL stack on top of the open checkpoint.

Composer 2.5 is text-first and tool-native: file edits, terminal, search, MCP when configured in Cursor. It is not on Critique’s OpenRouter review roster — it is exclusive to Cursor surfaces (IDE, CLI, Cloud Agents, SDK). That exclusivity is exactly why BYOA exists: your review can stay multi-vendor while fixes run on the stack you already bought.

PART THREE — BENCHMARKS (VENDOR & THIRD-PARTY TABLES)

PART FOUR — COLOSSUS, CLOUD AGENTS, AND WHERE CRITIQUE RUNS

Cursor’s launch narrative for 2026 also points forward: training collaboration with SpaceX AI on Colossus 2 — public commentary describes an order-of-magnitude step up in training compute versus prior generations. That is foundation-model factory infrastructure, not the runtime path for your Tuesday afternoon PR fix.

Critique Cursor BYOA runs in Cursor cloud agents today: we call the Agent SDK with `cloud.repos[]`, your `prUrl`, `workOnCurrentBranch: true`, and `composer-2.5`. The worker runs on Critique’s backend (QStash → pipeline), but the agent loop executes in Cursor-hosted VMs — the same class of surface as “Queue Cursor agent” in the dashboard. Claude BYOA similarly mounts your repo in Anthropic managed cloud; Codex BYOA uses OpenAI Responses until a fuller Codex agent API is available.

PART FIVE — HOW TO USE IT ON CRITIQUE

Export remains available: `GET /api/review-runs/{reviewRunId}/byoa/cursor` returns the `critique.cursor_agent_handoff` JSON for your own CI or scripts. Most teams use the queue button.