Cline is an open source coding agent that lives in VS Code or your terminal and does the thing everyone now expects such tools to do, which is read your codebase, propose changes, run commands and iterate until something works. The documentation covers it competently and shares the weakness of everything written about agentic coding, which is that the mechanics are easy to write down and the judgement is not. Setup and model access are handled well and honestly. You can use Cline's own billing, take a flat ClinePass subscription, or bring your own API key from any provider you like.
The bring your own key path being fully supported and documented rather than grudgingly tolerated is worth noting, because it means you can see exactly what you are spending and switch models freely. The docs list a lot of providers and the setup instructions generally work. The plan and act separation is Cline's most useful design decision and the documentation gives it appropriate weight. In plan mode the agent explores your codebase and proposes an approach without touching files.
In act mode it implements. This maps onto how the work should go, which is understand the problem, agree the approach, then execute, and the failure mode of coding agents is almost always that they start writing code before they have understood the situation. Forcing a planning step catches a large share of expensive mistakes before they become diffs. The documentation explains the mechanism clearly and could go further in explaining why it matters, because the people who most need to hear it are the people who will skip straight to act mode.
MCP server documentation is a strength. Model Context Protocol lets the agent reach out to external systems, your database, your issue tracker, a browser, your documentation, and Cline's implementation and its explanation of it are both practical. Setting up a server, understanding what the agent can then do, and thinking about what you are exposing are all covered. The security discussion around what an MCP server gives an agent access to could be more prominent, because connecting an agent to a production database is a decision people make casually and should not.
Checkpoints get proper coverage and deserve it. The agent snapshots your workspace as it goes so you can roll back when it heads in a bad direction, which it will. This is the safety net that makes it reasonable to let an agent make multi file changes, and understanding it early will save you from a bad afternoon. Rules and custom instructions are where I want considerably more.
You can give Cline persistent instructions about your codebase, conventions, preferred libraries, testing approach and everything else, and the quality of those instructions is the single biggest determinant of whether the agent is useful or exhausting. The documentation explains where the files go and the syntax. It says much less about what to put in them. A worked example of a well written rules file for a real project, with commentary on why each instruction earns its place, would be worth more than several existing pages.
What is missing entirely, and this is the honest criticism of the whole category rather than of Cline in particular, is any guidance on when not to use it. Agentic coding is excellent for well specified changes in a codebase with good tests, for boilerplate, for mechanical refactors, for exploring unfamiliar code and for writing the tests you were going to skip. It is poor at architectural decisions, at problems where the specification is the hard part, and at anything requiring context that exists only in your head or in a conversation from three weeks ago. It also has a genuine cost, which is that a developer who delegates everything stops building the mental model of their own codebase.
None of this appears in the documentation, and it is what separates people who get real leverage from these tools from people who generate large volumes of code they do not understand. Cost management is underplayed relative to the reality. Cline shows token usage and cost per request, which is good and is more transparency than several competitors offer. What the documentation does not do is prepare you for how quickly costs accumulate when an agent iterates on a large codebase with a frontier model, or teach the habits that keep it reasonable, such as scoping tasks tightly, keeping context small, using a cheaper model for mechanical work and reserving the expensive one for genuinely hard problems.
People discover this from their invoice. The three access models are a source of confusion. Cline's own billing, ClinePass at a flat monthly rate, and bring your own key are each documented, and the trade offs between them are not compared in one place as clearly as they should be. Pages also go out of date.
The product ships frequently, the interface changes, and the documentation catches up afterwards. Expect some mismatch. My three point six is for clear, honest setup documentation on a good open source tool with a genuinely well judged plan and act design, marked down because the material teaches configuration far better than it teaches practice, and because the judgement about what to delegate is the entire skill and is absent.