Cline SDK

What is Cline SDK?

Cline SDK (@cline/sdk) is a TypeScript agent runtime foundation extracted from Cline, intended to power agentic coding workflows across multiple surfaces (including IDEs and the CLI). Its core purpose is to provide a modular, reusable “agent harness” and architecture so teams can build and extend agents without being tied to a single app’s UI lifecycle.

Instead of keeping the agent loop coupled to a VS Code extension, Cline’s redesign treats the runtime as a shared service. That enables long-running work to continue independently of UI restarts, and supports moving sessions across surfaces while keeping the low-level agent loop reusable and stateless.

Key Features

• Shared agent runtime architecture: Separates the runtime from a specific IDE implementation so work is less dependent on UI restarts.
• Reusable agent harness (stateless loop): Keeps the low-level agent loop stateless and reusable, while a surrounding runtime can be durable and portable.
• Layered TypeScript stack: Uses a layered design where each layer has a single responsibility, and you can choose the full stack or individual packages depending on needs.
• Plugin system at the runtime layer: Plugins can register tools, observe lifecycle events, add rules/commands, and shape what the model sees.
• Flexible plugin loading and packaging: Plugins can be loaded from configured paths or workspace locations and can start as local .ts/.js modules before evolving into packaged modules using a cline.plugins manifest.
• Provider-layer LLM support (open choice): The provider layer supports multiple providers and OpenAI-compatible endpoints; switching providers is intended to be configuration-driven.

How to Use Cline SDK

1. Install the SDK: Install the full stack with npm i -g @cline/sdk.
2. Select the surface: Use Cline SDK to power agents in VS Code, JetBrains, and the CLI (Cline’s own surfaces are built on the SDK).
3. Extend behavior with runtime plugins: Create a plugin module (or package one) that can register tools and react to lifecycle events.
4. Configure model/provider access: Use the provider layer to select which model/provider an agent should call via configuration.

Use Cases

• Long-running agent work across restarts: Run agent tasks without having them “die” when a UI is restarted, since the runtime is designed to be durable and not tied only to a single UI lifecycle.
• Building agents that persist across multiple surfaces: Move sessions across different interfaces (e.g., IDE and CLI) while keeping the agent loop stateless and reusable.
• Team-specific agent customization via plugins: Add domain-specific behavior—such as additional tools, rules, or commands—by loading plugins without forking the runtime.
• Prototype locally, package later: Start with a plugin implemented as a local .ts/.js module, then package it into a reusable directory when the team hardens the capability with a cline.plugins manifest.
• Serverless or composable agent runtimes: Use smaller parts of the layered stack (e.g., provider logic or the stateless loop) when you want to embed the agent behavior into another runtime model.

FAQ

• Is Cline SDK tied only to the VS Code extension? No. The SDK is intended to power Cline across VS Code, JetBrains, and the CLI, and it is designed so teams can build on the runtime rather than reuse only an IDE-specific implementation.

• What is meant by “stateless” in the agent loop? The redesign keeps the low-level agent loop stateless and reusable, while the surrounding runtime provides durability and portability.

• How do plugins affect the model’s behavior? Plugins can register tools, observe lifecycle events, and shape what the agent sees (including rules and commands) before or during execution.

• Can I switch LLM providers without rewriting the agent? The provider layer is described as configuration-driven, with support for multiple providers and OpenAI-compatible endpoints.

• Do you need the full SDK stack to start? The SDK is described as layered: you can install the full stack or use individual packages (such as the provider layer or stateless loop) for smaller surfaces.

Alternatives

• Use an existing agent framework with a custom runtime: If you need full control over session persistence and tool orchestration, alternative agent framework approaches may be better suited when you already maintain your own runtime.
• Build on an IDE-specific agent extension model: Some solutions keep the agent loop inside an IDE plugin; these can be simpler to start but may keep runtime behavior more coupled to the UI lifecycle.
• Use a general LLM tool orchestration layer: Instead of an agent harness + runtime architecture, a tool orchestration approach focuses on calling models and tools, typically leaving session persistence and lifecycle management to your application code.