Cline, reviewed: an open coding agent that gives you every model and none of the guardrails

Cline is a coding agent that runs where engineers already work, and it does not try to own the model. It ships as a VS Code and JetBrains extension, a CLI, a desktop app and an SDK, all built on one agent core published under Apache-2.0, and every one of them will connect to whatever provider the team has already bought. The position here is that this is the right default for anyone who has to justify the bill, and the wrong default for anyone who wants a guardrail they can rely on, because the permission model is softer than it looks.

It competes directly with Claude Code, Cursor and the hosted coding assistants. Unlike those, it is not a product with a model attached but a harness with a model slot: the documentation lists Claude, GPT, Gemini, OpenRouter, AWS Bedrock, GCP Vertex, Groq, Cerebras, DeepSeek, local runtimes through Ollama and LM Studio, and anything speaking the OpenAI-compatible shape. That breadth is the feature, and it is also why comparing it to a closed product on quality is close to meaningless: most of what people praise or criticise about a coding agent is the model underneath.

What Cline is

• Apache-2.0, roughly 70,000 GitHub stars, 7,600 forks and 250-plus contributors, published as the cline CLI package and the @cline/sdk library.
• The same agent core behind four surfaces: IDE extension, terminal CLI, desktop app for macOS, Windows and Linux, and a TypeScript SDK for embedding it elsewhere.
• Plan mode and Act mode as separate states, with the option to run a different model in each.
• Checkpoints on by default, committing a full snapshot of the workspace to a separate shadow Git repository after every tool call.
• Per-category auto-approve toggles for reads, edits, commands, browser and MCP tools, plus a YOLO mode that turns all of them off.
• MCP support with local STDIO servers and hosted Streamable HTTP endpoints, and rule files read from .clinerules, .cline/rules, .cursorrules, .windsurfrules or AGENTS.md.

Plan and Act, and why the split matters

Plan mode is not a prompt. In that state the agent can read files, search and discuss, but it cannot modify a file or execute a command, and the conversation history carries over unchanged when Act mode starts. That makes the plan something the tool enforces rather than something the model is asked to remember, which is a materially better design than instructing a model to propose first.

Checkpoints are the other half of the design and deserve more attention than they get. After each file edit or command, Cline commits the current state of the working files to a shadow Git repository that is entirely separate from the project's real history. Three restore modes follow from that: restore the files and keep the conversation, restore the task and keep the code, or reset both. It is the reason auto-approve is defensible at all, and the documentation is candid that on very large repositories the snapshots cost storage and slow the agent down.

Plan and Act can also point at different models, which is the cheapest cost lever in the whole product: a strong reasoning model for exploration and a cheap fast one for applying the plan. For small tasks the documentation recommends skipping planning entirely, because the planning pass is pure overhead when the answer is obvious.

Getting started

The CLI is the surface worth learning first, because it is the only one where the approval defaults are visible and where the agent can run unattended. Headless mode switches on by itself when you pass --json, pipe stdin, or redirect stdout, which is a nice property for CI.

# Read every failing test and fix what caused them, then stop.
set -euo pipefail

npm test 2>&1 | tee /tmp/failures.log || true

# Plan-only pass: no writes, no commands, just an analysis to review.
cline -p "Explain why these tests fail and what the smallest fix is" \
  --json < /tmp/failures.log > /tmp/plan.jsonl

# Apply pass on a clean branch, with a hard stop so a loop cannot burn the budget.
cline "Apply the fix for the failures listed in /tmp/failures.log" \
  --auto-approve true \
  --timeout 600 \
  --retries 3 \
  --model anthropic/claude-sonnet-4-6 \
  | tee /tmp/run.log

# Fail the job when the suite is still red, so the pipeline does not ship a broken tree.
npm test

Three defaults in that invocation deserve scrutiny. --auto-approve defaults to true in the CLI, so unattended runs are the out-of-the-box behaviour, not the exception. --retries caps consecutive mistakes, which is the only guard against an agent looping on the same failing edit. And --timeout is the wall-clock stop that keeps a scheduled job from running until the budget is gone.

What it costs

The software is free and the inference is not. The extension, CLI, desktop app and SDK carry no seat fee, so the marginal cost of running Cline is whatever the chosen provider charges for the tokens an agentic loop burns, and an agent loop burns many times more tokens than a chat because every tool result comes back into the context. There is no seat price to negotiate and no invoice from Cline for the open-source path.

• Bring your own key: pay the provider directly, under a contract and a spend limit the organisation already controls.
• Cline usage-billing: one account, prepaid credits, one balance across the models Cline fronts, with some models tagged free for limited periods.
• ClinePass at $9.99 a month, a flat subscription that the documentation advertises as two to five times the usage on a curated set of open coding models against standard API rates.
• Enterprise: SSO, role-based access, centralised billing, audit logs, VPC deployment and OpenTelemetry, none of which exists in the free tier.

The practical consequence is that cost control moves out of the tool and into the provider console. A team that wants a hard ceiling on agent spend needs either a provider that enforces one or a wrapper around the CLI that fails the run on a token or dollar budget, because Cline exposes usage in its session history and its enterprise dashboard but does not itself stop a run when a threshold is reached.

The permission model, honestly

This is the part worth being blunt about. Auto-approve is evaluated per tool call against a category toggle, but there is no fixed allowlist of commands. The model marks each command as safe or requiring approval based on the command and its arguments, and the documentation gives examples rather than guarantees: build and test commands are usually safe, while installs, deletions, moves and in-place edits usually need approval. A security control that is implemented by asking a language model to classify a shell string is a speed bump, not a boundary.

• YOLO mode auto-approves everything: file operations anywhere on the machine, all terminal commands, browser actions, MCP tools and even the Plan to Act transition.
• The read and edit toggles have an all-files variant, which extends access outside the workspace when the base toggle is on.
• Scheduling, agent teams and subagents exist in the SDK, CLI and Kanban but not in the IDE extensions, so a control tested in one surface may not exist in another.
• Subagents are read-only by construction, which is the one part of the tool where a capability limit is real rather than advisory.

Where it shingle

The fragmentation is the tax. Features land in the SDK and CLI first and reach the extensions later, which the documentation states outright for scheduling, agent teams and subagents. The JetBrains plugin is the sharpest version of the problem: the repository states plainly that JetBrains plugins are not being open-sourced, so the IDE that a large part of the European developer base runs on is the one surface a reviewer cannot audit.

Context handling is the other soft spot, and it is not specific to Cline. An agent that reads files, runs tests, reads the failures and reads the diff again will spend most of its budget re-reading. The documented answer is subagents, which explore in parallel with their own context windows and return a short report, and memory bank files for structure. Both help, and neither changes the fact that an agentic session on a large repository is expensive in tokens relative to the value of the change.

Finally, the tool's own security surface deserves the same scrutiny as any other agent: the repository has a security policy, and a project that lets an agent read files and run commands on a developer machine is a dependency with a shell. Treat the version as a pinned dependency, review the changelog before upgrades, and keep the provider keys scoped.

Verdict

Cline is the best answer available for a team that has to choose its model, keep its data inside an existing provider contract, or automate agent work in CI without a vendor's permission system in the way. It is not a better version of a closed coding agent, and reviews that rank the two are comparing a harness to a model.

1. Teams whose provider choice is a procurement decision rather than a preference.
2. Engineers automating repository work in CI, where the headless CLI and the SDK are the reason to adopt it.
3. Anyone building on top of an agent runtime, because @cline/sdk is the agent core rather than a wrapper.
4. Do not adopt it on the assumption that checkpoints make autonomy safe. They make it recoverable.
5. Do not adopt it where the command surface must be provably bounded without writing hooks, or where an unauditable IDE plugin disqualifies the tool.

Sources

1. Cline docs: Overview
2. Cline docs: Plan and Act mode
3. Cline docs: CLI reference
4. Cline docs: Auto Approve and YOLO mode
5. Cline docs: Checkpoints
6. Cline docs: MCP
7. Cline docs: Rules
8. Cline docs: ClinePass
9. Cline pricing
10. cline/cline on GitHub