* feat(core, llms): Cline custom provider & web search
* fix(llms): preserve reasoning model token parameter
* fix(llms): keep ClinePass provider options on the wire in the shared Cline provider
The shared Cline provider hardcoded the AI SDK provider name to "cline",
but the openai-compatible model reads request-body passthrough options from
providerOptions[<name>]. Option routing emits ClinePass options under the
"cline-pass"/"clinePass" buckets, so gateway reasoning (extended thinking
budgets) silently stopped reaching the wire for cline-pass after it moved
off the generic openai-compatible module.
Thread the gateway provider id through as the provider name, and restore
strictJsonSchema: false for the new "cline" provider-options target so the
wire format matches the previous openai-compatible behavior. Add cline-pass
coverage at both the option-routing and request-body levels.
* feat(sdk): persist provider-executed tool activity (#13077)
* feat(core, llms): Cline custom provider & web search
* fix(llms): preserve reasoning model token parameter
* feat(sdk): persist provider-executed tool activity
* fix(vscode): restore state proto and settings section reverted by merge
The merge of origin/bee/websearch into this branch resolved conflicts by
keeping this branch's pre-#13126 copies of apps/vscode files, which
deleted the auto_approve_all_toggled = 174 proto field (without reserving
the number) and dropped a formatting line in FeatureSettingsSection.tsx.
Neither file is in scope for this PR. Restore both to main's content so
the proto source matches the checked-in generated code again.
* chore(vscode): match main byte-for-byte in FeatureSettingsSection.tsx
The pre-commit biome hook strips a blank line that exists on main, which
kept this out-of-scope file in the PR diff. Commit the exact main content
with --no-verify so the PR no longer touches apps/vscode at all.
---------
Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
* refactor(llms): key ClinePass provider options to the shared cline bucket
Both Cline gateway ids (cline and cline-pass) are served by the same
shared "cline" AI SDK provider and hit the same Cline API, so threading
the gateway provider id through as the AI SDK provider name (78dc6f3e7)
was unnecessary indirection. Revert the name threading and instead
normalize option-routing bucket keys: buildProviderAndAliasPatch now
keys both Cline gateway ids to the shared "cline" providerOptions
bucket, which is the only bucket the openai-compatible model reads for
request-body passthrough.
Also tighten the regression coverage that motivated the original fix:
the previous effort-based test rows were vacuously satisfied through the
portable-reasoning early return (effort reasoning never reaches provider
option buckets by design). The rows now use explicit reasoning budgets,
which do flow through the gateway bucket path, and the wire-level test
composes real provider options end to end instead of hand-feeding
buckets.
* revert(llms): drop the cline strictJsonSchema special case in generic-compatible
Restores buildCompatibleProviderOptions to its pre-78dc6f3e7 state. The
strictJsonSchema passthrough is verified inert for the gateway (nothing
in @cline/llms sets a response format), so keeping a hardcoded provider
target in the generic helper bought nothing. If structured outputs are
ever added, strictness for the cline target can be decided deliberately
then.
* fix(llms): claim native web search for openai-native, not the openai alias
supportsModelTool listed "openai", but that id aliases to
openai-compatible (PROVIDER_ID_ALIASES), whose module has no native web
search. The actual native OpenAI builtin id is "openai-native", which is
served by the OpenAI Responses module that does implement
buildModelTools with provider.tools.webSearch(). Without this, the
web_search tool was never offered to native OpenAI users, and was
wrongly offered for the compatible alias.
* refactor(llms): declare model tools in provider manifests
* feat(sdk): project provider tool activity in session history
---------
Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
Cline SDK Examples
Learn how to build with the Cline SDK through working examples, ordered from simple to complex.
SDK Skill
If you use a coding agent (Claude Code, Codex, Cline, etc.), install the Cline SDK skill to give your agent context on the SDK's APIs and best practices to help you build with the Cline SDK.
npx skills add cline/sdk-skill
Prompt it to scaffold agents, create custom tools, wire up plugins, configure providers, and more.
Getting started
All examples live in this directory. Each is a standalone project with its own package.json and README. To run any example:
cd apps/examples/<example-name>
bun install
bun run build:sdk
export CLINE_API_KEY="cline_..."
bun dev
Requires Node.js 22+.
Examples
Beginner
| Example | Description | Concepts |
|---|---|---|
| quickstart | Send one prompt, stream the response. ~15 lines of code. | Agent, subscribe, run() |
| cli-agent | Interactive terminal chat with a shell tool. | createTool, multi-turn run()/continue(), streaming |
| cline-core-cli-agent | Interactive terminal chat powered by ClineCore. | ClineCore.create(), cline.start(), cline.send(), built-in tools, streaming |
Intermediate
| Example | Description | Concepts |
|---|---|---|
| code-review-bot | AI code reviewer that reads git diffs and produces structured comments. | Multiple tools, completesRun lifecycle, systemPrompt, zod schemas |
| multi-agent | Web app that fans out to three specialist agents in parallel, streams results via SSE, then synthesizes a unified answer. | Concurrent agents, Promise.all, per-agent subscribe(), SSE streaming, agent composition |
Advanced
| Example | Description | Concepts |
|---|---|---|
| desktop-app | Full Tauri + Next.js desktop app for running and inspecting chat sessions. | Sidecar runtime, websocket transport, session persistence |
| menubar | macOS menu bar app with Tauri. | Native app integration, compact UI |
| vscode | VS Code extension with chat panel. | Extension API, webview, workspace context |
SDK packages
When building your own app, install the public SDK package:
npm add @cline/sdk
@cline/sdk re-exports everything from @cline/core. You only need @cline/agents or @cline/llms if you want lower-level control over the agent runtime or model gateway directly.
Learn more
- SDK package docs
- Architecture guide
- Plugin examples - extend the Cline SDK and CLI with custom tools and event hooks
- Hook examples - lifecycle hooks for logging, blocking, and injection for Cline SDK and CLI