Cline in Production: BYO-Key Costs, MCP Limits, and Terminal-Bench Results

A team evaluating the Cline VS Code agent extension found that a BYO-key setup with Kimi K3 on Terminal-Bench 2.1 raised its pass rate from 77.5% (69/89) to 88.8% (79/89) while cutting run cost from $79 to $49.80, attributing the savings to fewer sessions dying in retries, loops and self-termination. The team cautions that the benchmark is better treated as a harness-debugging case study than a definitive ranking, that a separate Python MCP SDK test failed during initialization without establishing a Cline client defect, and that Cline should be treated as an agent harness with an editor front end rather than a security boundary.

We did not test Cline because we needed another autocomplete tool. We tested it because flat per-seat AI IDE pricing makes cost attribution difficult, while closed agent runtimes make model and tool migrations expensive. Cline + Kimi K3 on Terminal-Bench 2.1: score up, spend downBaseline pass rate 69/89 77.5%/100Confirmation pass rate 79/89 88.8%/100Baseline run cost $79Confirmation run cost $49.80 The higher-scoring run on the same 89-task suite was also the cheaper one, because fewer sessions died in retries, loops, and self-termination. Cline separates the agent runtime from the inference provider. The VS Code extension supplies the agent loop, file operations, terminal integration, approvals, context management, and MCP client. We supply the model account and pay the inference provider directly. That separation gives us three things we cannot assume from a bundled IDE subscription: That does not make Cline free. It exchanges predictable seat pricing for variable inference spend, provider rate limits, API-key management, and substantially more operational responsibility. We evaluated four practical questions: The short answer is mixed. BYO-key model choice and usage-based accounting provide useful control, but we did not verify the extension's installation or provider-configuration workflow. Our separate Python MCP SDK test failed during initialization; it does not establish a Cline client defect. The benchmark is much more useful as a harness-debugging case study than as a definitive “Cline beats Cursor” ranking. Cline’s SDK production architecture also matters. We can instrument model-call, tool-use, session-end, and usage events, including token counts and finish reasons. The SDK supports iteration limits, per-turn token limits, loop detection, mistake limits, and host-side cancellation. Those are the controls we expect from an agent runtime. They are not proof that a developer workstation is safely sandboxed. Our evaluation therefore treated Cline as an agent harness with an editor front end, not as a security boundary. For a team rollout, we would verify the current Marketplace extension identifier and test installation in a clean VS Code profile. The commands below are illustrative; we have not verified their identifier or execution: code --install-extension saoudrizwan.claude-dev code --list-extensions --show-versions | grep -i saoudrizwan.claude-dev We would confirm the publisher, display name, and exact extension identifier against the current Marketplace listing before using these commands. For a team rollout, we would pin and test a known version before broad deployment: code --install-extension saoudrizwan.claude-dev@<approved-version --force Cline supports BYO-key providers, including Anthropic and OpenAI. We would verify the extension's current provider interface and credential-storage behavior before rollout, and keep keys out of workspace settings and committed files. For Anthropic or OpenAI, we would confirm the current provider-specific setup instructions, configure a dedicated development key, and select the intended model. We have not verified the extension's exact settings labels, compatible-endpoint fields, or approval controls. Our rollout plan would begin with a read-only task before enabling terminal commands or file writes. We would use separate development and production provider keys and configure provider-side budget alerts. A BYO-key extension installed on every laptop creates a larger credential-management surface than a centrally administered seat license. The following is an illustrative Python MCP server using the SDK version pinned for our local test attempt. This example was not successfully validated, and it is not a verified Cline integration: python server.py from mcp.server.fastmcp import FastMCP mcp = FastMCP "effloow-local-stub" @mcp.tool def add ticket label: str, priority: int - dict: """Create a local test ticket without external side effects.""" if priority < 1 or priority 5: raise ValueError "priority must be between 1 and 5" return { "accepted": True, "ticket": { "label": label, "priority": priority, }, } if name == " main ": mcp.run transport="stdio" We installed its dependencies in an isolated environment: python -m venv .venv . .venv/bin/activate pip install "mcp==1.9.4" "pydantic==2.11.5" "anyio==4.9.0" The following is an unverified registration example, not a configuration we tested in Cline. We would confirm the current client schema, configuration location, and approval fields before using it: { "mcpServers": { "effloow-local-stub": { "command": "/absolute/path/to/project/.venv/bin/python", "args": "/absolute/path/to/project/server.py" , "disabled": false, "autoApprove": } } } For a future integration test, we would use absolute interpreter and server paths and check the environment supplied by the client. We would also verify the meaning of approval fields rather than assume that an empty autoApprove list enforces the intended policy. State-changing tools should require explicit approval. Our isolated Python MCP SDK handshake did not complete successfully. The test failed during initialization with McpError: Connection closed and exit code 1, producing no tool observations. Dependency setup completed, but we did not verify Cline's registration structure, client behavior, argument validation, or recovery. This was a failed SDK integration attempt, not evidence of a Cline deployment defect. For the agent benchmark, we used the open Terminal-Bench dataset through Harbor. The relevant projects are the Terminal-Bench repository https://github.com/laude-institute/terminal-bench and the Harbor evaluation harness https://github.com/laude-institute/harbor . The baseline prerequisites were Python, uv , Docker, one provider key, and optionally Modal for parallel execution: uv tool install harbor pip install modal modal setup export CPUS=14 export MEMORY MB=8192 export OPENROUTER API KEY="replace-with-real-key" export API KEY="$OPENROUTER API KEY" harbor run \ -d terminal-bench@2.0 \ -a cline-cli \ -m openrouter:anthropic/claude-opus-4.6 \ --env modal \ --ak thinking=6000 \ --ak timeout=2400 \ -n 89 -l 89 \ --override-cpus "$CPUS" \ --override-memory-mb "$MEMORY MB" The 2,400-second timeout matters. The earlier 600-second default caused agent timeouts that looked like capability failures but were actually harness configuration failures. The reproduced full-sweep output was: 89/89 Mean: 0.573 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0:45:05 0:00:00 Passed: 51 Failed: 38 Mean reward: 0.573 Failure classes: AgentTimeoutError VerifierTimeoutError missing expected files command exit status not observed provider rate limit This was a Terminal-Bench 2.0 run using the Cline CLI adapter and an OpenRouter-hosted Anthropic model. It must not be compared directly with later Terminal-Bench 2.1 Kimi K3 results. For cost accounting, we examined the SDK's host-side estimator: it prefers provider-reported usage.totalCost and otherwise combines token counts with a maintained pricing table. We did not obtain actual per-task cost output. The following record is synthetic and illustrates a possible logging format: { "task id": "tb2-task-041", "model": "provider:model-id", "input tokens": 18442, "output tokens": 2106, "provider reported total cost usd": 0.1187, "iterations": 14, "finish reason": "completed" } That JSON is an output-format example, not an independently verified cost for a named Terminal-Bench task. The externally auditable numbers were aggregate: the later Kimi K3 baseline cost $79 for 89 attempts, or $0.888 per attempted task, while the confirmation run cost $49.80, or $0.560 per attempted task. Those averages include failed tasks and cannot reveal the task-level distribution. For production accounting, we would reject aggregate-only reporting. We would persist provider, model, input tokens, output tokens, cached tokens, provider-reported cost, tool calls, duration, and finish reason for every task. The first local failure was initialization in a separate Python MCP SDK test, not in Cline's MCP client. Our pinned Python client received Connection closed during session.initialize . There were no tool observations, so we could not establish invocation, schema validation, or recovery. Our immediate debugging checklist was: For us, this failed SDK initialization highlighted checks we would perform before relying on an MCP integration. It did not measure Cline's portability or compare clients. We would validate process supervision, approval semantics, credentials, timeouts, logs, and environment propagation for each server/client pairing. The second issue was misleading benchmark failure attribution. We found several classes that were not model-intelligence problems: pkill -f commands matched the harness process and killed the agent itself. @a -style tokens triggered file-mention processing while an unreferenced asynchronous worker allowed the process to exit before a model call. These failures matter because they demonstrate how much benchmark performance belongs to the harness rather than the model. Retries with exponential backoff, output-aware loop detection, explicit completion verification, PID-based process cleanup, and a longer timeout produced real improvements. The score still had material run-to-run noise. Six comparable runs produced 0.49, 0.43, 0.45, 0.44, 0.48, and 0.46, with a 0.458 average and 0.455 median. We would not merge a harness change based on a one- or two-point improvement from a single run. We would repeat close comparisons three to six times. We also encountered an evidence problem around cost. The runtime exposes enough usage data to implement task-level accounting, but the headline benchmark material mostly supplied whole-run spend. Dividing $49.80 by 89 attempts is useful for budgeting; it is not a substitute for a cost histogram or pass-adjusted cost. Finally, before replacing Cursor or Windsurf with a BYO-key harness, we would review operational requirements beyond raw model quality: We would manage Cline through an approved configuration baseline, a provider gateway, and centrally collected usage events. A collection of individually configured laptops is not a production deployment. Our local Docker path was suitable for smoke tests, not rapid 89-task iteration. Sequential execution can take many hours. Modal parallelization brought the full run into the reported 40–50 minute range, with our reproduced output finishing in 45:05. The three-task setup check still took roughly 15 minutes because environment and sandbox startup were significant. We did not measure workstation memory consumption for the VS Code extension, so we will not invent a number. The benchmark configuration explicitly reserved 14 CPUs and 8,192 MB per task environment for the parallel workflow; that is an evaluation allocation, not the extension’s desktop footprint. | Cline option | Inference arrangement | Accounting considerations | Integration considerations | |---|---|---|---| | BYO key | Provider API usage; model-agnostic provider choice | Host-side SDK accounting can use provider-reported cost or token counts and a pricing table | Verify each MCP server/client pairing and approval policy | | ClinePass | $9.99/month for curated open-weight models, with no separate provider keys | We did not verify task-level billing detail or compare its accounting with bundled IDE plans | We did not test MCP behavior under this plan | We did not measure competitor accounting granularity, MCP behavior, or administrative burden, so we would compare those separately before making a procurement decision. The practical break-even calculation is straightforward: Monthly Cline cost per developer = tasks per month × mean API cost per task + shared gateway, observability, and support cost Break-even task count = competing monthly seat price ÷ mean API cost per task Using the $0.560 attempted-task average from the Kimi K3 confirmation run, a hypothetical $40 seat reaches raw inference break-even at roughly 71 attempted tasks per month: $40 / $0.560 = 71.4 tasks That does not mean Cline becomes uneconomic at task 72. A Terminal-Bench task is not equivalent to an autocomplete request, and seat plans can include quotas or overages. The calculation only shows why teams need their own task distribution. The later Terminal-Bench 2.1 campaign moved from 69/89, or 77.5%, at $79 to 79/89, or 88.8%, at $49.80. The entire optimization campaign consumed roughly one billion tokens and about $680 over 17 hours. The winning run became cheaper because fewer sessions died in retries, loops, and self-termination. We found that result technically valuable but causally incomplete. The campaign had no budget-matched parallel-sampling control and no held-out task split. Repeatedly optimizing against the same 89 tasks can improve that suite without proving equivalent generalization. We therefore treat 88.8% as evidence that Cline plus Kimi K3 completed 79 tasks under that configuration, not proof that Cline is universally better than Cursor, Windsurf, or every other harness. If you are designing a broader agent platform rather than selecting an editor extension, review our tools collection https://dev.to/tools and evaluate Cline’s SDK, CLI, and event model separately from its VS Code experience. We did not verify the extension installation and provider-configuration procedures, credential-storage behavior, Cline MCP registration or approvals, successful MCP tool execution, the extension's memory footprint, or the task-level cost distribution behind the benchmark totals. Our local MCP experiment used a separate Python SDK client and failed during initialization. Cline works best when we treat it as an inspectable agent harness rather than a cheaper clone of a commercial IDE. Deploy Cline if: Hold off or avoid it if: Before deployment, we would require per-task usage storage, provider budget alerts, maxTokensPerTurn , maxIterations , explicit task cancellation, restricted tool policies, and separate development and production credentials. We would also start MCP with no auto-approved state-changing tools. Our final assessment is that Cline is a production candidate for an engineering organization willing to own inference operations and validate its configuration. BYO-key provider choice and host-side usage accounting offer useful control, but we did not establish a comparative portability or accounting advantage over specific closed IDE products. It does not eliminate lock-in entirely: the lock-in moves from the editor to agent rules, approval behavior, telemetry, and tool integration details. The benchmark work reinforced the most important lesson. Agent quality is not just model quality. Timeouts, exit-code handling, retries, process supervision, loop detection, and completion verification moved the score from 47% to 57%, while later harness repairs helped reach 79/89 on a different benchmark version and model. Those are runtime-engineering gains, not prompt magic. We would deploy Cline first to a small, technically strong cohort, instrument every task, and compare cost per accepted change against the existing workflow. We would not mandate it across a company based on headline benchmark percentages. For help designing that controlled rollout, including gateway, MCP, observability, and evaluation architecture, talk to our engineering team https://dev.to/contact .