Skillforge Field notes on shipping with AI tools

Claude Agent SDK vs Cline SDK: Which to Embed in 2026

claude-codeai-workflows

If you are choosing an agent runtime to embed in something you ship, the deciding factor is not the feature list. Both of these can read files, run commands, call MCP servers, and spawn subagents. The deciding factors are licensing, model portability, and whether the runtime is allowed to spawn a process where you plan to deploy it.

Short version: Cline SDK is Apache-2.0, pure TypeScript, and works with any major model provider, so it is the one you can fork, audit, run in an edge runtime, and point at whatever model is cheapest this quarter. Claude Agent SDK is Claude-only under Anthropic's commercial terms, ships a native binary it runs as a subprocess, and in exchange hands you the entire Claude Code harness (skills, hooks, subagents, sessions, permissions, .claude/ config loading) already assembled and battle-tested.

Everything below was checked on August 20, 2026 against each project's own documentation and the npm registry. We have not built a production product on either SDK, and the article says so wherever that matters. Where the claim is a fact we pulled from a registry or a docs page, the number is there.

What each one actually is

Claude Agent SDK (@anthropic-ai/claude-agent-sdk) is Claude Code as a library. Anthropic's own framing: the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript. It is not a wrapper over the Messages API; it drives the Claude Code binary. The SDK package bundles that binary through platform-specific npm optional dependencies, and it exposes startup() for pre-warming what the docs call the CLI subprocess.

Cline SDK (@cline/sdk) is the runtime behind the Cline IDE extensions and CLI, published as TypeScript packages you can embed. Its structure is visible from the package layout: @cline/core is the Node runtime (sessions, built-in tools, persistence, automation), @cline/agents is a browser-compatible stateless agent execution loop, @cline/llms is the provider gateway and model catalogs, @cline/shared holds types, schemas, tool helpers, and hooks. @cline/sdk itself is a re-export shim: 946 bytes unpacked, one dependency.

Both are pre-1.0. As of today npm has @cline/sdk at 0.0.75 (published August 19, 2026) and @anthropic-ai/claude-agent-sdk at 0.3.237 (published August 20, 2026). Neither is promising you a stable API surface, and the Claude SDK's patch number tells you how fast it moves.

The license question, which usually ends the argument

This is the part most comparisons skip, and it is the part that decides whether you can ship.

@cline/sdk declares "license": "Apache-2.0" in its package metadata, and the repository's LICENSE file is the Apache License 2.0, copyright 2026 Cline Bot Inc. That is a permissive open-source license: you can fork it, vendor it, patch it, and ship it inside a commercial product, with the usual attribution and patent terms.

@anthropic-ai/claude-agent-sdk declares "license": "SEE LICENSE IN README.md". The Agent SDK docs are explicit that use is governed by Anthropic's Commercial Terms of Service, including when you use it to power products you make available to your own customers, except where a specific component carries a different license. It is a commercial dependency, not an open-source one. That is not a knock: it is a different deal, and you need to know which deal you signed before a customer asks.

Two more constraints on the Claude side that only show up in the docs, both of which have killed product plans before:

  1. You cannot resell claude.ai login. Anthropic's docs state that unless previously approved, third-party developers may not offer claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK. Your users bring an API key, or you bring one and pay for their tokens. There is no "sign in with your Claude Pro subscription" path for your product.
  2. You cannot call your product Claude Code. Branding guidance permits "Claude Agent", or "Claude" inside a menu already labeled Agents, or "{YourAgentName} Powered by Claude". It does not permit "Claude Code", "Claude Code Agent", or visual elements that mimic Claude Code.

Cline imposes none of this, because Apache-2.0 does not work that way.

Architecture: bundled binary versus in-process library

The Claude Agent SDK's base package is 4,587,298 bytes unpacked, and on top of that npm pulls exactly one of eight platform binaries: linux-x64, linux-arm64, linux-x64-musl, linux-arm64-musl, darwin-x64, darwin-arm64, win32-x64, win32-arm64. The musl builds mean Alpine images work, which is more than many native-binary packages manage.

Two practical consequences, both documented:

  • An install that skips optional dependencies (npm ci --omit=optional, a common CI hardening flag) gets no binary. The fix is to stop skipping them, or install Claude Code natively and set pathToClaudeCodeExecutable. Worth knowing before your pipeline fails at 2am.
  • The Python SDK has the same shape: it bundles a binary via platform wheels, and if pip falls back to the source distribution (the docs name ARM64 Windows) you install Claude Code separately and the SDK finds it on PATH.

Cline's runtime is TypeScript that runs in your process. @cline/core is 3,382,684 bytes unpacked with 22 direct dependencies, and @cline/agents is described as browser-compatible.

That difference is a deployment fork, not a preference. A runtime that works by spawning a native binary cannot run where there is no process to spawn: a browser, or a V8-isolate edge platform like Cloudflare Workers. We host our own render API on Workers, so this constraint is one we live with on a different workload, and it is absolute rather than a matter of tuning. If your target is a container, a VM, a Lambda with a big enough package, or a developer's laptop, the binary is a non-issue and you get a heavily exercised agent loop for free.

Node floors differ too, and in Cline's favor for old infrastructure in one direction only: @cline/sdk requires Node >=22, while @anthropic-ai/claude-agent-sdk requires >=18.0.0 (its docs say Node.js 18+ or Python 3.10+).

Model portability

Cline SDK's documented providers are Anthropic, OpenAI, Google, AWS Bedrock, Mistral, and any OpenAI-compatible endpoint, which the docs illustrate with vLLM, Together, Fireworks, and Groq. Provider and model are constructor arguments (providerId, modelId), so switching is a config change.

Claude Agent SDK runs Claude models. You do get four ways to buy them: a direct ANTHROPIC_API_KEY, Amazon Bedrock (CLAUDE_CODE_USE_BEDROCK=1), Claude Platform on AWS (CLAUDE_CODE_USE_ANTHROPIC_AWS=1 plus ANTHROPIC_AWS_WORKSPACE_ID), Google Cloud's Agent Platform (CLAUDE_CODE_USE_VERTEX=1), and Microsoft Foundry (CLAUDE_CODE_USE_FOUNDRY=1). That covers the "our compliance team requires our own cloud account" objection, but it is procurement flexibility, not model flexibility.

If your product's pitch is "works with your model", that is the whole comparison and Cline wins it. If your product's pitch is "this thing is good at coding", model lock-in to the models currently at the top of coding benchmarks is a strange thing to call a weakness.

The API surface, side by side

Claude's entry point is a single async generator. From Anthropic's TypeScript reference:

function query({
  prompt,
  options
}: {
  prompt: string | AsyncIterable<SDKUserMessage>;
  options?: Options;
}): Query;

You iterate messages as the agent works, and Options is where the whole harness lives: allowedTools, disallowedTools, permissionMode, systemPrompt, mcpServers, agents, hooks, skills, sandbox, settingSources, maxTurns, cwd, model, thinking, effort. Alongside query() the package exports startup(), tool(), createSdkMcpServer(), and a set of session functions (listSessions(), getSessionMessages(), renameSession(), tagSession()).

Cline's entry point is a class. From Cline's own SDK README:

import { Agent } from "@cline/sdk"

const agent = new Agent({
  providerId: "cline",
  modelId: "openai/gpt-5.5",
  systemPrompt: "You are a helpful coding assistant.",
  tools: [],
})

const result = await agent.run("Create a REST API with Express and TypeScript")
console.log(result.text)

Their docs also show apiKey and maxIterations as constructor options, an agent.subscribe(callback) for streaming events such as assistant-text-delta, and a createTool() helper that takes a Zod inputSchema and an execute function. Both snippets above are quoted from the vendors' documentation; we did not run either as part of writing this, and you should treat any pre-1.0 snippet as a shape rather than a guarantee.

The stylistic difference is real but small: await agent.run(...) is a nicer first line of code than an async for loop, and the async generator is nicer the moment you need to render progress, interrupt a run, or switch permission mode mid-task (the Query object exposes interrupt(), setPermissionMode(), and setModel()).

What you inherit without building it

This is where the Claude SDK earns its constraints. It loads skills, slash commands, and memory from a project's .claude/ directory and from ~/.claude/, the same as Claude Code does, and it supports plugins that package skills, agents, hooks, and MCP servers. If your users are already Claude Code users, their existing configuration works inside your product on day one, and every skill, hook, or subagent they have already written is a feature you did not build.

Cline's equivalent pitch is its plugin architecture plus the features it lists as included: checkpoints, web fetch, MCP, cron jobs, and subagents. That is a serious list, and hub support and automation appear in @cline/core's own description. What it is not is a config format that thousands of developers already have sitting in their repositories.

Neither one saves you from the part that is actually hard, which is the operational layer: where the agent runs, what it is allowed to touch, what happens when it loops, and who pays for the tokens. We wrote up the scheduling half of that in running an agent on a schedule, and the billing half in how to charge for an MCP server.

Pick this way

Choose Cline SDK when the license has to be permissive, your users need to bring their own provider, you are deploying somewhere a native binary cannot go (browser, V8-isolate edge), you want to read and patch the agent loop yourself, or you are on Node 22+ anyway and want the smaller dependency footprint.

Choose Claude Agent SDK when your users are already Claude Code users whose .claude/ config should keep working, you want the most-exercised agent loop available rather than one you tune, you need enterprise procurement paths through Bedrock, Vertex, Foundry, or AWS, or you are on Node 18 and cannot move.

Reasons that are not reasons: neither is meaningfully "faster to first token" in a way you can predict from these docs, both do MCP, and both do subagents. If someone tells you one is 3x better at coding, ask which model each one was running.

What we could not verify

Three things, stated plainly rather than guessed:

  • Cline's own quickstart uses providerId: "cline", and @cline/llms is described as a provider gateway. We did not verify whether that provider id requires a Cline account or bills through Cline, so do not read this article as saying it is free of one. The directly named providers (Anthropic, OpenAI, Google, Bedrock, Mistral, OpenAI-compatible) are configured with your own key.
  • We have not run either SDK in production, so nothing here is a claim about reliability, token efficiency, or long-run cost.
  • Both packages are pre-1.0 and were published within the last two days as of writing. Any specific option name here can move. The license terms, the branding rules, and the binary-versus-library architecture are the parts unlikely to change on a patch release, which is exactly why they belong at the top of your decision and not the bottom.

FAQ

Is the Claude Agent SDK open source?

No. The npm package declares "license": "SEE LICENSE IN README.md", and Anthropic's documentation states that use of the Claude Agent SDK is governed by Anthropic's Commercial Terms of Service, including when it powers products you offer to your own customers, except where an individual component carries its own license. The Cline SDK is Apache-2.0 (verified in both the package metadata and the repository LICENSE file, copyright 2026 Cline Bot Inc.).

Can I use the Cline SDK with Claude models?

Yes. Anthropic is one of the documented providers, set as a providerId on the Agent constructor with your own API key. You lose the Claude Code harness specifics (the .claude/ skills, commands, and memory loading, and Claude Code's own permission model) and keep Cline's plugin system instead.

Can I build a product on the Claude Agent SDK and let users sign in with their Claude subscription?

Not by default. Anthropic's docs state that unless previously approved, third-party developers may not offer claude.ai login or rate limits for their products, including agents built on the Agent SDK, and direct developers to API key authentication instead. Plan for API keys, your own or theirs.

Which one works in a serverless or edge environment?

Cline is the one with a path there: @cline/agents is documented as a browser-compatible stateless execution loop, meaning no process spawn is required. The Claude Agent SDK works by running a native Claude Code binary, so it needs an environment that can execute one: a container, a VM, or a function runtime with room for the binary, not a V8 isolate.

What languages can I use?

The Claude Agent SDK is a library for Python and TypeScript only; Anthropic's documented path for other languages is to run the CLI as a subprocess with -p and --output-format json. The Cline SDK is TypeScript, and the same subprocess trick applies through its CLI.

Do I still need Claude Code installed?

Usually not. Both the TypeScript and Python Claude SDKs bundle a native binary. The exceptions are documented: a pip install that resolves to the source distribution rather than a platform wheel (ARM64 Windows is the named case), or an npm install that skips optional dependencies. In both cases you install Claude Code natively, and for npm you point pathToClaudeCodeExecutable at it.

Verified August 20, 2026 against code.claude.com/docs (Agent SDK overview, quickstart, TypeScript reference), docs.cline.bot/sdk, the cline/cline repository, and the npm registry metadata for @anthropic-ai/[email protected], @cline/[email protected], and @cline/[email protected].