Cline SDK: The Modular Agent Runtime Powering 7M Developers

TL;DR

• Cline rebuilt its entire agent runtime from scratch as @cline/sdk — a pluggable, open-source framework
• The new harness scores 74.2% on Terminal Benchmark with Claude Opus 4.7, outperforming Claude Code's 69.4%
• Layered TypeScript architecture separates runtime from UI — sessions survive restarts, agents run across surfaces
• Ships with plugins, multi-agent teams, MCP connectors, and provider flexibility built in — no orchestration layer needed

The Big Picture

Cline was early. Before "agents" became a buzzword, it shipped the first real agentic coding experience as a VS Code extension. That head start came with a cost: the agent loop grew inside the product itself. Terminal integration, computer use, subagents, custom tools — each new capability made the runtime harder to separate from the IDE around it.

The architecture that got Cline to 7 million developers was not the foundation they wanted for what comes next. So they rebuilt it. The new Cline SDK (@cline/sdk) abstracts the core agent harness into a pluggable runtime that powers VS Code, JetBrains, and the CLI. It's open-source, installable via npm, and designed so any team can build on the same foundation Cline uses internally.

This is not a refactor. It's a ground-up rewrite that treats the runtime as a shared service, not an implementation detail. Sessions can move across surfaces. Long-running work survives UI restarts. The agent loop stays stateless and reusable while the runtime around it becomes durable, portable, and product-agnostic.

How It Works

Cline 2.0 is a layered TypeScript stack. Each layer has a single responsibility and depends only on the layer beneath it. Install @cline/sdk when you want the full stack. Use individual packages when you need a smaller surface — the provider layer for an LLM proxy, the stateless loop for a serverless runtime. You can start small and add the stateful runtime only when you need it.

The redesign centers on an improved agent harness. Cline rewrote the prompts, simplified the loop, tightened context management, improved feedback loops and error handling, and rethought how tools are defined and surfaced to the model. Those gains carry across every Cline surface because they live in the runtime, not the app.

The results show up in benchmarks. On Terminal Benchmark 2.0, Cline CLI with Claude Opus 4.7 scores 74.2% — ahead of Claude Code's 69.4%. With GPT-5.3-Codex, Cline hits 73.0%, close to Codex CLI's 75.1% and Droid's 77.3%. For open-weight models, Cline with kimi-k2.6 scores 55.1%, outperforming OpenCode's 37.1% and Pi-Code's 45.5%. With deepseek-v4-pro, Cline reaches 53.9% versus OpenCode's 51.7% and Pi-Code's 52.9%.

Internal runs show the new CLI completes the same tasks faster and at lower token cost than the old one. The harness improvements are not theoretical — they ship in every product built on the SDK.

Plugins are how teams add domain-specific behavior without forking the runtime. A plugin can register tools, observe lifecycle events, add rules and commands, and shape what the agent sees. Plugins load from configured paths or workspace locations. They can start as a local .ts or .js module and later become a package directory with a cline.plugins manifest. Prototype locally, package reusable capabilities when they harden. Working examples live under examples/plugins/ in the repo.

Beyond plugins, the SDK provides custom tools, MCP connectors, and skills as extensibility points. The provider layer supports Anthropic, OpenAI, Google, AWS Bedrock, Mistral, LiteLLM, and OpenAI-compatible endpoints like vLLM, Together, and Fireworks. Switching providers is a config change. Provider logic lives in @cline/llms, keeping model catalogs and handler behavior out of the agent loop. To add a custom provider, implement an ApiHandler and register it with llms.registerHandler("my-provider", handler).

Some work is too large or too ambiguous for a single agent. The SDK includes agent teams and subagents natively. A session can delegate to specialists, track progress, and exchange handoff notes inside the same core runtime. No separate orchestration layer needed. Subagents run with their own model, tools, and prompts. The bundled plugin exposes tools for starting subagents, messaging them, reading status, and storing handoff notes. Teams can experiment with multi-agent workflows without building orchestration from scratch.

Scheduled CRON jobs, checkpointing, web search, and MCP connectors all work out of the box. The SDK also introduced experimental connector channels to easily connect agents with Telegram, WhatsApp, Slack, and other platforms. Setup via the Cline CLI interactive wizard: cline connect.

What This Changes For Developers

Pulling the engine out of the extension changes Cline's role. The runtime is no longer locked inside one product. Cline is one product built on top of the same SDK they're opening up. The CLI already migrated to the new SDK architecture. VS Code and JetBrains extensions are in progress.

This shift unlocks use cases that were hard before. Build the support bot that reads your codebase before answering. Build the nightly agent that audits dependencies, opens PRs, and assigns reviewers. Build the multi-agent workflow that turns a one-line bug report into a tested fix. Build the IDE integration, internal tool, or connector Cline hasn't shipped yet. The runtime is open because the use cases should not be limited to the surfaces Cline ships itself.

The layered architecture means you can compose what you need. Use the provider layer if you're building an LLM proxy. Use the stateless loop if you're running agents in a serverless environment. Use the full stack if you need durability, plugins, and multi-agent teams. The SDK is designed so you can start small and add layers as requirements grow.

For teams already using Cline's VS Code extension, the migration to the new SDK means better performance, more extensibility, and a runtime that survives UI restarts. For teams building their own agents, it means a battle-tested harness with plugins, provider flexibility, and multi-agent support built in.

Try It Yourself

# Install the SDK
npm install @cline/sdk

# Install the CLI globally
npm i -g @cline

# Add the Cline SDK skill to your agent
npx skills add cline/sdk-skill

Working examples live in the repo. Check sdk/apps/examples/ for full applications built on the SDK. Check sdk/examples for plugin, hooks, and cron examples. Docs are at docs.cline.bot/sdk. Join the Discord at discord.gg/cline.

The Bottom Line

Use this if you're building agents that need to run across surfaces, survive restarts, or delegate to specialists. Use this if you want a harness that ships with plugins, provider flexibility, and multi-agent teams instead of building orchestration yourself. Skip it if you're prototyping a single-shot agent that runs once and exits — the SDK's durability and statefulness add overhead you don't need.

The real opportunity is that Cline is no longer the only place this runtime can live. The SDK is open-source, modular, and designed for reuse. The risk is that the architecture is new — Cline is still migrating its own extensions to the SDK. Early adopters will hit rough edges. But the foundation is solid, the benchmarks are strong, and the team is learning from the people building with it.

If you're building agents that need to do more than one thing at a time, this is worth your attention.

Source: Cline