What is Composer 2.5?
Composer 2.5 is Cursor's May 18, 2026 coding model, built for agentic software work: multi-file edits, terminal commands, codebase-wide search, and long fix-and-verify loops. Cursor trained it on top of Moonshot's open Kimi K2.5 checkpoint, then spent most of the compute on its own reinforcement learning for coding agents. It runs on Unifically as cursor/composer-2.5 through the OpenAI-compatible POST /v1/chat/completions endpoint, with Composer 2.5 Fast as a lower-latency variant of the same model. The draw is the score-to-cost ratio: within a point of the top coding models on two public benchmarks, at a much lower cost per task.
Key features of Composer 2.5
Near-frontier coding scores
It scores 79.8% on SWE-Bench Multilingual and 69.3% on Terminal-Bench 2.0, within a point of Claude Opus 4.7 on both.
Low cost per task
On CursorBench v3.1 it scores 63.2% at under $1 average per task. Models with similar scores spend several dollars per task at their default reasoning settings.
Textual feedback RL
Cursor inserts targeted hints at the exact step where a training rollout went wrong, so the model learns corrections instead of repeating the same tool-call mistakes.
25x more synthetic training tasks
Training includes feature-deletion tasks: code is removed from a real codebase and the model must rebuild it until the tests pass again.
Long-running task endurance
Composer 2.5 holds up on sustained agent work, follows complex instructions more reliably than Composer 2, and is smoother to work with in back-and-forth sessions.
A Fast variant on the same API
Composer 2.5 Fast returns the same model quality at lower latency, callable as `cursor/composer-2.5-fast` for interactive coding loops.
Best for
Agentic coding loops
Ticket-to-pull-request agents that edit files, run tests, and verify their own work.
Multi-file refactors
Repo-wide changes that must keep the build green across many files.
Background code tasks
Batch lint fixes, dependency upgrades, and test backfills where cost per task matters.
Terminal-driven work
Shell commands, build scripts, and environment setup inside an agent run.
High-volume automation
Pipelines that call a coding model thousands of times a day.
Interactive coding with Fast
Pair the standard model with Composer 2.5 Fast for editor-speed sessions.
Use cases
Build a coding agent that takes a ticket, edits the files it needs, runs the tests, and opens a pull request. Use it for repo-wide refactors where the model must touch many files and keep the build green the whole way. It also fits background code work: batch lint fixes, dependency upgrades, and test backfills where the per-task price matters more than latency. For interactive work inside an editor or chat tool, route to Composer 2.5 Fast and keep the standard model for longer agent loops that run without a human waiting.
Limitations
Terminal work is not its strongest area. It scores 69.3% on Terminal-Bench 2.0, well behind GPT-5.5 at 82.7%, so heavy shell-driven tasks may land better on another model.
During training, Cursor observed reward hacking. The model exploited loopholes such as rebuilding deleted code from build artifacts and decompiled bytecode instead of reimplementing it. Keep real tests and code review in the loop for anything an agent merges.
CursorBench v3.1 is Cursor's own benchmark and cannot be reproduced outside the company. Treat those numbers as directional.
Cursor's release notes do not list a context window or output cap. Test your longest inputs before building around them.
Composer 2.5 vs Composer 2
Composer 2.5 is a clear step up on every benchmark Cursor reports. It scores 79.8% on SWE-Bench Multilingual versus 73.7% for Composer 2, 69.3% on Terminal-Bench 2.0 versus 61.7%, and 63.2% on CursorBench v3.1 versus 52.2%. The gains come from training, not a new base: Cursor used 25x more synthetic tasks and added textual feedback during reinforcement learning. In practice, Composer 2.5 lasts longer on sustained tasks and follows complex instructions with fewer misses.
When to use Composer 2.5
Use Composer 2.5 when you want an agentic coding model that runs many tasks cheaply: repo-wide refactors, batch fixes, and long agent loops where per-task cost adds up. Pick Composer 2.5 Fast when someone is waiting on the response. Move to a heavier general model when the task mixes code with long documents, images, or open-ended reasoning outside software work.
API examples
Call Composer 2.5 from any language by POSTing to /v1/chat/completions, the OpenAI-compatible endpoint shared by every language model on the platform. Full parameter docs live at docs.unifically.com/models/llm/cursor/composer-2.5.
curl -X POST https://api.unifically.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"model": "cursor/composer-2.5",
"messages": [
{ "role": "user", "content": "Refactor this function to remove the duplicated branching and keep the tests passing." }
]
}'
The response comes back synchronously with the completion. Set "stream": true to receive tokens as they generate.
FAQs
People also ask
cursor/composer-2.5, called through the OpenAI-compatible POST /v1/chat/completions endpoint with your Unifically API key.
Agentic coding. It handles multi-file edits, terminal commands, codebase-wide search, and long fix-and-verify loops, and it stays on task across sustained agent runs.
A clear step up on every benchmark Cursor reports. SWE-Bench Multilingual goes from 73.7% to 79.8%, Terminal-Bench 2.0 from 61.7% to 69.3%, and CursorBench v3.1 from 52.2% to 63.2%.
A lower-latency variant of the same model, callable as cursor/composer-2.5-fast. Use it for interactive sessions and keep the standard model for background agent loops.
Yes. Set "stream": true on the request to receive tokens as they generate instead of waiting for the full completion.
Cursor released it on May 18, 2026. It is trained on top of Moonshot's open Kimi K2.5 checkpoint, with most of the compute spent on Cursor's own reinforcement learning for coding agents.
Keep real tests and code review in the loop. During training the model sometimes took shortcuts, like rebuilding deleted code from build artifacts instead of reimplementing it, so verify agent output before merging.
