Cline, a coding agent in your editor on your own key

Cline, a coding agent in your editor on your own key

Cline is a coding agent available as an editor extension, as a command line program and as a library. It reads files, runs commands and edits code, asking for approval before it acts. The cline/cline repository holds roughly 66.6 thousand stars under the Apache 2.0 licence, and you pay for inference from your own account with a model provider.

What Cline actually does

Cline is not a model. It is a loop that takes your instruction, adds context from the repository, sends the whole thing to the model you chose, receives a request to use a tool, executes it and returns to the model with the result. That loop keeps turning until the model declares the task finished or you stop it. All the intelligence sits with the model provider, all the mechanics sit with Cline.

The tools the agent holds are concrete and countable. Reading files and directories, searching the project, creating and editing files, running terminal commands, driving a browser, and calling tools exposed by MCP servers. Each of those categories has its own approval switch, which I will come back to separately, because it is the most important part of the configuration.

The tool ships in three shapes and they differ enough that it pays to know which one is meant. The Visual Studio Code extension is published under the identifier saoudrizwan.claude-dev, at version 4.1.11 dated 21 August 2026, with roughly 5.05 million installs and an average rating of 4.07 from 311 ratings. The command line program installs from the npm registry as the cline package and sits at version 3.0.56. The @cline/sdk library at version 0.0.77 is an alias for the @cline/core package and lets you embed the same loop in your own application. Versioning is therefore independent for each of those things, and comparing the extension version with the terminal program version means nothing.

Everything lives in one repository. The apps directory holds the subprojects cli, vscode, cline-hub, vscode-rollout and examples, next to the sdk, evals and docs directories. The terminal program itself has five production dependencies, all from the same family: @cline/sdk, @cline/core, @cline/agents, @cline/llms and @cline/shared.

Installation looks like this.

# the Visual Studio Code extension
code --install-extension saoudrizwan.claude-dev

# the command line program, globally
npm install -g cline

# check the version and the current configuration
cline --version
cline config

# diagnostics when something misbehaves
cline doctor

# configure a model provider and a key
cline auth

Version, licence and project health

The licence is straightforward here, and that alone is good news, because coding agents vary on this point. The LICENSE file in the repository root carries the full Apache License 2.0 text with a copyright notice for Cline Bot Inc. dated 2026. The license field in the npm registry for the cline package reads Apache-2.0, and the same holds for @cline/sdk. The GitHub programming interface reports apache-2.0 for the repository. Three independent sources agree on one value, there is no separate directory carrying commercial terms and no NOASSERTION result that would force a closer investigation.

Apache 2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices on redistribution. You may use the code commercially, modify it and deploy it inside a company without asking anyone. If your organisation keeps a dependency licence list, this entry will not cause trouble.

Project activity is high. The repository was created on 6 July 2024, is not archived, carries 7174 forks and 1048 open issues, and the last change on the main branch is dated 21 August 2026. Stable releases of the cline package appear roughly weekly: version 3.0.55 shipped on 14 August and 3.0.56 seven days later. A nightly channel runs alongside, published daily under its own npm tag. At that pace, pinning an exact version in continuous integration is not overkill, because agent behaviour and default settings can shift between minor releases.

A company stands behind the project rather than a foundation, and the split of features shows it. The client code is open and free for an individual developer, while the Enterprise plan, priced individually after contacting sales, adds things the open version does not have. Its feature list includes a JetBrains extension, single sign-on, centralised billing, team management, role based access control, restricting the list of permitted inference providers, and authentication logs. If you work in IntelliJ IDEA or PyCharm, that settles the matter up front: the free path runs through Visual Studio Code or through the terminal.

Plan and Act modes

The split into two modes is what most distinguishes Cline from agents that run in a single pass. In Plan mode the agent can read code, search the project and discuss an approach, but cannot modify files or run commands. The constraint comes from withholding the relevant tools rather than from a request buried in the system prompt, so it holds.

In Act mode the same agent receives the full tool set and carries out the agreed plan. Conversation history crosses between modes unchanged, which means you do not have to repeat the decisions after switching. That detail decides whether the whole mechanism is useful, because if context were dropped, planning would be money wasted.

You can also assign a separate model to each mode. The settings hold a switch described as using different models for Plan and Act. A sensible arrangement is a stronger reasoning model for planning and a cheaper, faster one for execution, since the planning phase produces few output tokens while the execution phase produces many. The documentation lists example pairs, among them GLM 4.6 for planning with Grok Code Fast for execution in the cost conscious variant, and Claude Opus for planning with Sonnet for execution in the quality oriented one.

For work larger than a single file, the /deep-planning command earns its place. It starts a longer analysis session in which the agent walks the repository systematically, lists the files and dependencies the change touches, builds a detailed plan and asks clarifying questions before doing anything. It costs more than a plain start in Act mode, but on a change spanning a dozen files it repays itself on the first mistake the agent does not make.

In the terminal it looks like this.

# planning mode, the agent will not touch files
cline --plan "review the authorisation layer and propose a migration plan"

# a one-off task in act mode, with an explicit model
cline --model claude-sonnet-4-5 "fix the failing tests under src/auth"

# terminal user interface for a longer session
cline --tui

# resume an earlier session by identifier
cline --id 01JQ8X5K2M "continue from where we left off"

# JSON output, for a pipeline
cline --json --timeout 600 "produce a test coverage report"

One item in that set deserves attention right away. The terminal program defaults to Act mode with automatic approval of every tool, because the --auto-approve flag defaults to true. The default provider is cline, meaning the credit billed service rather than your own key. Both defaults can be changed, but you want to know about them before the first run in a real repository.

Tool approval, or where the brake sits

Approval is checked on every tool call. Before the agent reads a file, writes a change, runs a command or reaches for the browser, the mechanism compares the operation category against your settings. The shape of those settings in the source code looks as follows.

export interface AutoApprovalSettings {
  version: number
  enabled: boolean
  favorites: string[]
  maxRequests: number
  actions: {
    readFiles: boolean
    readFilesExternally?: boolean
    editFiles: boolean
    editFilesExternally?: boolean
    executeSafeCommands?: boolean
    executeAllCommands?: boolean
    useBrowser: boolean
    useMcp: boolean
  }
  enableNotifications: boolean
}

The enabled, favorites and maxRequests fields are marked in the code as leftovers from older versions and no longer affect behaviour. The former cap on the number of requests within one task has been removed, which means there is no built-in counter that halts the loop after a fixed number of model calls.

The default values in that same source file are surprisingly liberal. Reading files inside and outside the project is on, editing files inside and outside the project is on as well, and so are the browser and MCP servers. The executeSafeCommands field is false, but executeAllCommands is true. Notifications are off. The documentation in the same repository recommends the exact opposite arrangement: enable reading project files only, and leave edits, commands, browser and MCP off until a specific reason appears. The gap between the recommendation and the default object in the code is real, and checking your settings before the first run takes a minute.

A separate distinction covers safe commands versus commands requiring approval. Cline keeps no fixed allowlist. The model marks each command with a requires_approval flag based on the command and its arguments. The documentation lists examples usually treated as safe, such as npm run build, git status or ls -la, and examples usually requiring approval, such as npm install, rm -rf, mv or sed -i, and states plainly that these are examples rather than guarantees. The risk is obvious: the decision about what counts as safe belongs to the model, so enabling approval of safe commands without reading the output is trust placed in a classifier rather than in a rule.

A harder constraint comes from the CLINE_COMMAND_PERMISSIONS environment variable, which accepts a JSON policy restricting permitted shell commands. That mechanism sits on the Cline side, independent of the model's judgement, and in shared environments it is a sounder anchor than the interface toggles alone.

At the other end of the scale sits YOLO mode, available in the settings under features. Once enabled it approves everything: file operations anywhere on the system, any terminal command, browser actions, MCP tools, and transitions between Plan and Act. The documentation calls it dangerous and lists the consequences explicitly, including deleted files, overwritten configuration, installed packages and changes pushed to a remote repository. That is a tool for experiments in a throwaway directory, not for work in a company repository.

The safety net is checkpoints, meaning snapshots of workspace state you can return to after a bad change. If you enable automatic approval of edits, checkpoints stop being an extra and become a precondition. Turning on notifications helps too, because the enableNotifications field, off by default, also governs the signal about a command that has been running for more than thirty seconds.

Configuration, rules and MCP servers

Configuration splits across two scopes. The global one lives in your home directory and applies to every shape of the tool, the project one lives in the repository and travels with it.

~/.cline/
  data/
    settings/
      providers.json           # API keys and provider configuration
      global-settings.json     # global settings
      cline_mcp_settings.json  # MCP server configuration
    sessions/                  # session data
    workflows/                 # global workflows
  rules/                       # global rules
  hooks/                       # global hooks
  skills/                      # global skills
  agents/                      # agent definitions
  plugins/                     # plugins, .js and .ts
  cron/                        # schedules

.cline/                        # at the repository root
  rules/
  skills/
  hooks/
  agents/
  plugins/
  cron/

Provider keys sit in a plain providers.json file in the home directory. That is convenient and at the same time worth noting when working on a shared machine or when copying a home directory into a container image. The path can be moved with the CLINE_DATA_DIR variable or the --data-dir flag, which is often the simplest way to isolate a work configuration from a personal one.

Project rules in the .cline/rules directory are a text file appended to the system prompt, meaning a place for conventions the agent should follow. Keep them short, because they attach to every request and you pay for them in tokens on every turn of the loop. Cline also supports the older .clinerules directory and the AGENTS.md file, which the project uses on itself.

MCP servers are added in ~/.cline/mcp.json when working from the terminal, or through the MCP Servers panel in the extension. The format is the standard one for the protocol ecosystem.

{
  "mcpServers": {
    "postgres": {
      "command": "node",
      "args": ["/opt/mcp/postgres-server.js"],
      "env": {
        "DATABASE_URL": "postgres://localhost:5432/app"
      },
      "disabled": false,
      "autoApprove": []
    },
    "docs": {
      "url": "https://mcp.example.com/v1/stream",
      "headers": {
        "Authorization": "Bearer ${DOCS_TOKEN}"
      },
      "disabled": false
    }
  }
}

A local server is described by a command and args pair, a remote one by the url field. Two transports are available: Streamable HTTP, marked in the documentation as recommended, and SSE, described as legacy. The autoApprove field takes a list of tool names approved without asking and is empty by default, which is a reasonable setting. From the terminal the same thing is managed by a wizard started with cline mcp, which lets you list servers, add a new one, edit an existing one, enable it, disable it or delete it.

Where the bill comes from

This is the point where Cline differs most from Cursor or GitHub Copilot. There you pay a fixed monthly amount and the vendor carries the risk of how much you actually consume. Here you pay for tokens from your own account, so the risk moves to you, and in exchange you get freedom of model choice and no attachment to a single supplier.

The mechanism behind the bill is simple, and that is exactly why it can catch people out. Every turn of the loop is a separate model call carrying the entire conversation so far, together with the contents of files that were read, the output of commands, and the descriptions of available tools. A task that closes in twenty turns sends the context twenty times, and the context grows with every turn. Cost is therefore not proportional to the number of changed lines but to the product of turn count and average context size.

Automatic context compaction adds to that. When the conversation approaches the window limit, Cline builds a summary of the whole history so far, swaps the history for that summary and carries on. The documentation notes that the operation appears as a tool call and shows its cost like any other request to the model. Put differently, cleaning up the context is billable too, and in long tasks it happens more than once.

The third multiplier is the reasoning level. The --thinking flag accepts the values none, low, medium, high and xhigh, with medium as the default. Higher levels produce more reasoning tokens, and those are billed as well. Choosing a level makes sense on a task that needs analysis, not on rewriting imports in one file.

The practical conclusions run like this. Start in Plan mode with a cheaper model, so the scope narrows before the real work begins. Keep tasks short and close the session once a step is done rather than carrying one conversation through the whole day. Set --timeout and --retries so the loop does not spin indefinitely after a run of failed attempts. Trim project rules to what is genuinely needed.

Two services from the vendor stand as an alternative to your own keys. The first, described as Cline with usage billing, runs on credits topped up from the dashboard and gives access to a model list without opening an account with every provider separately, with some models tagged as free. The second, ClinePass, is a subscription at 9.99 dollars per month covering selected open coding models, among them the GLM, Kimi, DeepSeek, MiniMax and Qwen families, and by its own description gives two to five times the usage of those models compared with the standard interface rate. Both are optional and both mean billing through an intermediary. If full control over cost matters, that leaves your own provider key or an aggregator such as OpenRouter, and if you want no bill at all, a model run locally through Ollama.

Cline and the alternatives

The choice comes down to a few questions. If you want a predictable monthly cost and no appetite for watching token consumption, a subscription in Cursor or Windsurf will be calmer. If you want to stay in your own editor and decide for yourself which model handles which task, Cline fits better than either. If you are after an open extension with a similar philosophy, Continue is the closest equivalent, and for work confined to the terminal and centred on version history, Aider makes more sense.

Common mistakes

The first is running the terminal program in a real repository without checking the defaults. It starts in Act mode with --auto-approve set to true, so the agent will begin changing files and running commands without asking. Make the first run in a directory you can afford to lose, or pass --auto-approve false explicitly.

The second is treating the safe command category as a guarantee. The classification comes from the model, which marks each command with a requires_approval flag, not from a fixed list of permitted patterns. For a hard limit, use the CLINE_COMMAND_PERMISSIONS variable with a JSON policy.

The third is skipping Plan mode on multi-file changes. An agent that starts editing immediately builds its context along the way and picks the wrong place more often. The planning phase costs few output tokens and saves whole turns of the loop.

The fourth is carrying one conversation across many hours. Context grows, every subsequent request costs more, and at the window limit a billable compaction step joins in. Close the session once a step is done and start a new one.

The fifth is bloated project rules. The rules file attaches to every request, so a few hundred lines of conventions turn into a standing tax on every turn of the loop.

The sixth is counting on the JetBrains plugin in the free version. It appears on the feature list of the Enterprise plan, which is priced individually, so without a contract you are left with Visual Studio Code or the terminal.

The seventh is leaving the autoApprove field empty without checking what a given MCP server can actually do. The useMcp toggle in the approval settings is on by default, and a remote server's tools may reach into production systems.

FAQ

Is Cline free?

The client itself is. The extension, the command line program and the library are under the Apache 2.0 licence with no licence fees and no per-seat charges. You pay only for inference, meaning tokens with the model provider you chose. Separately there is an Enterprise plan priced individually that adds team features.

How does Plan mode differ from Act mode?

In Plan mode the agent can read code and search the project, but has no tools for modifying files or running commands. In Act mode it receives the full set. Conversation history crosses between modes, so decisions do not have to be repeated, and each mode can be assigned a different model.

Can Cline do anything without my approval?

That depends on the settings, and it is the part you need to check yourself. Approval is verified on every tool call, but the default settings object in the code has file reading and editing, the browser and MCP switched on. YOLO mode approves everything, including transitions between modes.

How much does a typical session cost?

No single number applies, because cost depends on the model, on the number of loop turns and on the size of the context sent on each turn. The mechanism is that the bill grows with the length of the conversation rather than with the number of changed lines. You inspect consumption in the usage panel and with your provider.

Does Cline work in JetBrains?

The JetBrains plugin appears on the feature list of the Enterprise plan. The open version offers the Visual Studio Code extension and the command line program, which can be used alongside any editor, including in a mode compatible with the Agent Client Protocol.

Does my data reach Cline's servers?

With your own key, requests go straight to the model provider you chose. When using credit billing or the ClinePass subscription, the vendor's infrastructure sits in between. Configuration and keys stay local, in the ~/.cline/data/settings directory.

You will find the documentation at docs.cline.bot, plan details on the product site, and the source code in the GitHub repository.