I knew Cline as a VS Code extension — the thing that reads your codebase, proposes diffs, asks before touching anything. Apparently that’s now just one of four things it is.

They pulled the actual agent runtime out into @cline/sdk, an open-source TypeScript package, and that same package now runs the VS Code extension, a JetBrains plugin (IntelliJ, PyCharm, WebStorm, GoLand — the whole family), a standalone CLI, and a new web Kanban board where you can apparently run several agents at once, each with its own git worktree so they don’t step on each other.

Bundled in with that: what they’re calling Cline 2.0, which isn’t just repackaging — they rewrote the prompting and agent loop from scratch. Makes sense once you think about it. The original prompts were tuned for Claude 3.5 Sonnet back in 2024. Running that same setup against Opus 4.7 or Kimi K2.6 today just wasn’t getting the most out of either model, so they redid it rather than let years of prompt-tuning debt quietly cap how good the tool could get.

The actual latest release is smaller stuff, mostly reliability fixes rather than new features:

  • Scheduled agent tasks now live in one place (~/.cline/schedules) instead of scattered across whatever folder created them
  • A finished scheduled run now shows its real result instead of you having to dig for it
  • Cancelling a session now cancels everything it spawned too — no orphaned subagents left running
  • The Codex sign-in bug where it used to just hang if a port was already taken now fails with an actual error message

None of that sounds exciting written out like that, I know. But it’s the kind of thing that only matters once you’re running scheduled or multi-agent stuff unattended, which — if the SDK pitch works — is presumably where this is headed.

Worth noting how this compares to the other “pull the runtime out and let people build on it” moves I’ve covered: OpenCode took the opposite path, building server-client separation in from day one rather than extracting it after the fact, and DeepSeek Harness went further still by making every single layer swappable, not just the entry point. Three different teams converging on roughly the same instinct — the runtime is the actual product, the interface is just whichever shape you happen to be using it in today — suggests this isn’t one company’s idiosyncratic bet.

Model-agnostic, and now apparently platform-agnostic too. Feels like a pattern I keep running into writing this: the tools doing well right now aren’t betting on one model or one interface, they’re betting on being underneath whichever one you happen to pick. Apache 2.0, so the SDK itself is free to build on if you want to.

npm install -g @cline/sdk