De-composer

If you've been following agentic coding lately, you've probably heard about Cursor Composer 2.5. It's a fine-tune of Moonshot's Kimi K2.5, the same family as the last Composer release, and Cursor says Kimi K2.5 checkpoint right in the announcement.

The reason people got worked up, in a good way for once, is that this felt less like a leaderboard fine-tune with a press release stapled to it. The story is the post-training: Cursor took a strong open base model and put serious RL muscle behind it, and the result feels like a different beast altogether. As someone who has downloaded dozens of user-uploaded post-trained GGUFs from HuggingFace like they were WinAmp skins in 2002 and been relatively disappointed, it's encouraging to see how different this model feels from Kimi. Composer 2.5 was trained on xAI's Colossus, speculative reports say Cursor allocated something like 85% of the compute budget to RL and synthetic coding tasks, and this is where that post-training story starts to feel real from the user side.

Chinese AI labs keep dropping models with stats that say they are one hair behind Opus or GPT, and the models are impressive, especially for the price, but the user reviews tell a messier story than the obligatory benchmark chart on every lab's release announcement. Setting aside the fact that they inexplicably highlight the numbers in their own column even when it isn't the highest, which insults MY intelligence, no one has really cared about benchmaxxed scores for a good while now. People still feel that little sigh of relief when their Claude or Codex quota resets and they can finally hand the ugly ticket back to a model they trust, which is a pretty good tell that the cheaper models have not quite crossed over for a lot of real workflows.

Composer 2.5 is interesting because, for me at least, it interrupts that reflex. Cursor seems to have cracked some of that feel here, and they did not make you pay frontier prices for it: the standard tier is fifty cents per million input tokens and two-fifty per million output, roughly an order of magnitude cheaper than Opus-class pricing and often cheaper than plain API access to the models people keep comparing it against. More importantly, it is useful in the boring ways that matter; it is fast, cheap enough to leave running, and willing to grind through long agent work where a benchmark-good cheap model starts sounding plausible while quietly losing the plot.

The 262k context window is not impressive on paper anymore, especially in a world where everyone is yelling about million-token ceilings, but Composer 2.5 is better than the spec sheet makes it look. The win is behavioral: sustained tool use, decent compaction behavior, good effort calibration, and less of that cheap-model habit where it wanders off right before the boring part gets hard. I would not call it Opus tier, but for workflows with a lot of interacting pieces, where a cheaper model can waste the whole afternoon by missing one relationship three steps back, it is a real tool for the job.

So for a minute there, agentic coding was cheap again, and that is why I cared enough to chase this instead of benchmarking it for a day and moving on with my life. Composer 2.5 is the first cheap model in a long time I would call an actual daily driver, and once a model crosses that line I stop wanting it in one app and start wanting it everywhere: in my harnesses, inside Claude Code, inside the terminal workflows I have spent years wiring together, with the local tools and MCP servers I already trust.

The catch is structural. As of right now Composer 2.5 is only available in Cursor, the desktop app and the Cursor CLI. They are not doing the whole "paste this base URL anywhere, put in your API key, and go have fun" thing. And to be clear, this is not a complaint about the surfaces: I live in a terminal, and the Cursor CLI in particular is a genuinely great agent client, the thing I point people at when they tell me agentic coding never clicked for them inside an editor. If I were starting from zero, I could happily run my whole day through it. But I am not starting from zero. I have years of harnesses, scripts, and muscle memory built around Claude Code and an Anthropic-shaped API, and those workflows are not decoration; they are how I actually ship.

That is the actual itch: you can love Composer 2.5, love the Cursor CLI, and still spend most of your day inside workflows that predate both. Every time I stepped back into one of my Claude Code harnesses, I was reaching for Opus or Codex pricing again while the Cursor subscription I already pay for sat idle. If the model were mediocre, I would not have bothered. Since it is fast, cheap, and weirdly good at the exact long-running agent work I care about, I wanted it in every workflow I have, not just the ones with a Cursor client in front of them.

This is exactly the sort of gap my CLIProxyAPI fork exists to close. CLIProxyAPI is a Go proxy server with one job: take whatever pile of AI subscriptions and OAuth logins you already pay for, Claude Code, Codex, Gemini, and the rest of the circus, and expose them behind one OpenAI- or Anthropic-shaped API on your machine. Instead of every CLI inventing its own auth circus, you point your tools at localhost, pass a key your config trusts, and say which model you want.

My fork exists because I wanted more providers and a hosted route. I added Copilot OAuth back when that was the best deal around, then Railway deployment with auth bundling so you can log in locally once and hit the proxy from a laptop, iPad, or whatever happens to be in front of you. I also added pass-through models for random OpenAI- or Anthropic-compatible endpoints and first-class Chutes support, which is basically serverless compute for open-source models; the fork fetches Chutes' model list, normalizes the names, and automatically exposes explicit chutes-* routes so I do not have to hand-maintain whatever model happens to be cheap and useful this week. Apparently my hobby is collecting AI billing relationships and pretending that is infrastructure.

The next feature was obvious: Cursor Composer via your Cursor subscription and your Cursor API key. Same theme, one base URL, many providers, many tools, now with Cursor. And there is an official answer here, a good one: Cursor publishes @cursor/sdk, a real agent runtime you can build on, and their own launch post pitches exactly this kind of use: custom harnesses, CI agents, Cursor embedded in your own products, running "on your machine or on Cursor's cloud." For anything new I write, that is the obvious path, and it is where my newer workflows are headed. But I have a pile of existing ones I have not yet been able to migrate — some are wired into tools that only speak Anthropic- or OpenAI-shaped APIs, some are load-bearing harnesses that work today and do not justify a rewrite this month, and some are simply further down the list than the work they exist to do. I wanted Composer in those workflows now, not at the end of a migration backlog. I also did not want the sketchy alternative, where I reverse-engineer Cursor's private protobuf and OAuth dance and pretend to be their app. The version I wanted put the SDK in exactly one place: let the published @cursor/sdk talk to Cursor inside the proxy, then make Claude Code's tools show up in the shape Composer knows how to call, so every workflow I already have gets Composer without changing a line.

That got the model talking, but not working. Cursor's SDK can run the Composer agent loop, but Cursor's side does not accept arbitrary Claude-style tools. It accepts MCP servers. So CLIProxyAPI has to dynamically present Claude Code's local tools as fake MCP servers, keep the SDK run alive across tool calls, and route every shell command, file read, edit, grep, and local MCP call back to the machine where Claude Code already lives.

It works now. Several wrong designs, one embarrassing filesystem leak, and a few test failures later, Composer can sit inside Claude Code without turning back into a chat box that talks about edits instead of making them.

I gave myself two rules before I started, both of them reasonable in isolation and annoying the second they met each other. The first rule was that I would not call Cursor's private API myself. I wanted Cursor's own published SDK to own auth, streaming, recall, and the protocol details I did not want to clone, because reverse-engineering a private endpoint and dressing myself up as the IDE is exactly the kind of cleverness that ages into a support burden and, depending on how spicy you get with it, a terms-of-service problem.

Rule two was that every tool had to run on the user's machine. If Composer wants to inspect or change the repo, that work needs to happen where Claude Code is running, against the user's files and configured tools. A proxy can translate and route; it cannot become the computer the agent is operating.

The clean path was also the trap: the SDK was the right way to talk to Cursor, but its default tool loop wanted to run wherever the Node process lived.

The box below is the short version of what failed.

Running the official SDK in agent mode is the failure that mattered. The @cursor/sdk package was the obvious way to talk to Cursor without cloning their private API, because it already knew how to authenticate and manage a real Composer run. Then I ran it on a Railway box, pointed Claude Code at it, and Composer cheerfully told me it was operating inside a remote container with HOME=/root, not where my repo lives unless my laptop has been doing some very ambitious lying.

After the Railway pwd output, I was debugging tool execution location, not provider wiring. Every read and shell call had to run on my laptop through Claude Code.

Claude Code was running on my laptop, the Node sidecar was running on Railway, and the official Cursor SDK was doing the Composer run when I asked the agent something ordinary about my repo. Composer answered like a helpful little server process: its working directory was /app, its home directory was /root, and /home/jmn did not exist.

One config line caused it: Agent.create({ local: { cwd: WORKDIR } }). In the SDK's world, "local" means "run the agent's tools in this process's local filesystem," and since the process lived on Railway, the agent's local filesystem was the Railway container. Those were real commands against Railway's disk, not hallucinated paths.

That is an easy mistake to dismiss as a config bug until you watch the agent act on it. A coding agent with tools pointed at the wrong filesystem is worse than a chat bot, because it will grep and narrate a tree for a repo your machine does not have. Composer understood the request well enough; I had accidentally handed it the wrong machine.

Removing local: just swings the pendulum too far the other way, because now the SDK no longer has the local tool loop I need. I had to intercept tool dispatch and send each call back to the client before the server touched disk.

The Railway leak left one requirement: tool calls leave the SDK process and finish on the machine where Claude Code runs.

I did not want Composer as a cheaper text box. I wanted it inside Claude Code with the same repo tools and MCP servers I already run locally. The annoying constraint is that Cursor Composer does not accept arbitrary Claude-style tools over the API; it accepts MCP servers, so CLIProxyAPI has to make Claude Code's tools look like MCP servers for the duration of the run.

That is why the Node sidecar exists in the first place. CLIProxyAPI stays the local API facade; the sidecar is the little SDK host whose job is to let Cursor's own code handle auth, recall, streaming, and the protocol furniture I do not want to clone by hand.

Composer still needs tools in its own shape. CLIProxyAPI builds a fake MCP catalog from Claude Code's current tool inventory, including file reads, edits, shell, grep, and any real MCP servers already configured locally. When Composer calls one of those fake MCP tools, the SDK run pauses until Claude Code returns the result.

These are MCP-shaped entries, not a little zoo of spawned MCP subprocesses. Composer sees server-shaped tools because that is the contract it understands; the bridge maps those calls back to Claude Code's existing tool inventory, which is the whole reason the same local MCP setup keeps working.

Composer also needs to be told that repo paths come from the client harness, not from the directory next to the Node process on Railway. That sounds like a small prompt detail until you watch an agent confidently explain a directory tree from the wrong machine.

The boxes are boring on purpose. Claude Code owns the tools, the Go proxy translates requests, the Node sidecar owns the Cursor SDK run, and Cursor only hears from its own SDK. The useful seam is where the SDK's unary and streaming tool paths both end up at the same executor shape, with stable protobuf oneof cases like shellArgs, grepArgs, and mcpArgs surviving minification well enough to anchor the redirect.

The bridge hooks that SDK tool path, emits a tool_call to CLIProxy, parks the Composer run, and resumes it when the client sends the matching result. The important bit is that the thing Cursor sees is MCP-shaped, while the thing that actually executes is still Claude Code's normal local tool. If the hook is missing, the call refuses instead of quietly falling back to the SDK's native executor.

Result shape took more care than the diagram admits. Cursor serializes these tool messages through protobuf, and some of the useful fields sit inside nested oneof cases, which means a plain JSON object can look right in a log and still lose the exact branch the SDK expects when it goes back into the run. The bridge has to rebuild the proper message shape before resuming Composer, which feels too fussy until the agent hangs forever because the one field it needed dissolved in transit.

CLIProxy fronts a Composer run in Cursor's SDK, fabricates the MCP surface Composer is willing to use, and lets Claude Code execute every tool locally. Because the hook itself is process-global, the sidecar carries the current session through the async chain with AsyncLocalStorage; without that, two conversations can share one hook and suddenly a tool result lands in the wrong paused run.

/v1/messages wants one shot per request; the SDK agent can pause for tools. The bridge stores the live run id so the next request continues the same Composer run instead of faking a new transcript.

The broad architecture was the clean part. The time went into little mismatches that are boring to describe until one of them leaves an agent run hanging forever or quietly routes a tool toward the wrong executor. I am putting them here as notes instead of making you walk through every commit, because if you have ever debugged glue code between two agent runtimes you already know the shape of the misery.

Most of the time went to ESM vs CJS loading the wrong bundle, tool ids getting rewritten, and streaming vs non-streaming returning different shapes. Any of those can route a tool to the wrong place without throwing.

The bad failure mode is simple: miss one tool case and the server starts executing it. The safety layer catches that, so if the bridge hook is missing, tools reject; if the SDK no longer exposes the expected dispatch shape, the sidecar refuses to boot instead of guessing and hoping nobody notices.

The self-test took longer than I wanted because the first version was lying to me. It pinged the bridge hooks directly, which proved that the hooks existed, and proved nothing about whether the SDK's rewritten hook ever called them. That is a green check that tests the wrong thing.

The version I trust exercises the actual rewritten hook in the SDK bundle. It turns routing off so native execution is reachable, then turns routing on so tools go to the client. A test that has never failed for the real risk does not count.

CI installs a fresh @cursor/sdk, runs the hook check with routing off so native execution is reachable, then with routing on. If the bad path never fails, the test is worthless.

For a few hours I thought I was done: live API, tools routing to the client, tidy commit. Review and edge cases disagreed.

I had been calling it done when CI went green and the demo path worked. The streaming path and the non-streaming path had diverged, and two conversations could share a session key if they started with the same message.

I made server-side execution a test failure you have to see before the suite passes, and I diffed the two response paths until they matched.

Patching the SDK hook took an afternoon; trusting it took longer.

None of this is new computer science. CLIProxy fronts a Composer run in Cursor's SDK, turns Claude Code's local tools into fake MCP servers because Cursor only accepts MCP-shaped tools, and sends the actual execution back to Claude Code, which is the only way one server process does not both talk to Cursor and touch the filesystem.

I care that Cursor traffic stays on their SDK, tools stay on my machine, and nothing in the middle executes shell or file ops.

This depends on an unsupported hook in @cursor/sdk. The adapter is small so a version bump is a contained fix, and CI has to show server-side execution before we call it safe. The self-tests have one job: if the SDK bundle moves the dispatch anchor, the bridge fails before a tool quietly runs on the sidecar. Cursor should expose this as a supported mode eventually; for now it is the bridge I wanted badly enough to build.

If you already run my CLIProxy fork, you add the Node sidecar and a Cursor key, then point Claude Code at Composer. Setup is fiddly but the failure modes are obvious when you hit them. And the payoff is exactly what I wanted at the start: the model I could not stop thinking about, running in every workflow I have, including the ones still waiting on their SDK migration.

-- Jeff