The Local Coding Agent Stack: Aider, Continue, Cline, and OpenHands

The coding assistant market split cleanly in 2025. One side: polished, subscription-based products (Cursor, Windsurf, GitHub Copilot) that own your context window and charge per seat. The other side: open-source agents you wire to your own models — cloud APIs via your own keys, or weights running locally on your own hardware. The second category is where things get interesting for homelab operators and privacy-conscious engineering teams.

This post is a field guide to the four tools that define the BYOK/local category: Aider, Continue, Cline, and OpenHands. It covers what each one actually is (architecture, not marketing copy), where each sits on the autonomy spectrum, how they perform with local models at the 32B–70B tier, and the honest trade-offs against Claude Code and Cursor for day-to-day use.

The Autonomy Spectrum

Before comparing tools, it helps to map the space. “AI coding assistant” covers an enormous range of behaviors — from “suggests a completion as you type” to “rewrites your entire codebase while you sleep.” These four tools occupy distinct positions:

  Low autonomy                                          High autonomy
  (you drive)                                           (agent drives)
       |                                                      |
  Continue -------- Aider -------- Cline -------- OpenHands
  (inline          (REPL,          (agentic        (fully sandboxed,
  suggestions,     file edits      VS Code ext,    Docker runtime,
  @mentions)       per request)    approval gates) multi-agent)

Continue is closest to “smart autocomplete with a chat panel.” OpenHands is closest to “give it a ticket, come back in twenty minutes.” Aider and Cline occupy the productive middle ground where most developers actually spend their time.

Aider

39K GitHub stars · 4.1M installs · Terminal-based · MIT license

Aider is the oldest and most opinionated tool in this group. It runs in your terminal, it thinks in git, and its core value proposition has been consistent since 2023: every AI edit is a commit you can review, revert, or cherry-pick. Nothing happens to your files without going through the normal version control path.

Architecture: The Repo Map

The technical differentiator is the repo map. When you add files to an Aider session, it doesn’t just read those files — it builds a symbol-level graph of your entire repository using tree-sitter to parse every source file and extract definitions and references. That graph is then ranked with a PageRank algorithm that weights nodes by how many other parts of the codebase depend on them.

The result is a compressed, token-budgeted summary of the most relevant code context beyond the files you explicitly added. By default, Aider allocates 1K tokens to this map (--map-tokens flag) but you can push it higher. The practical effect is that the model understands your project structure without needing every file in context — critical when working in codebases that exceed any reasonable context window.

1
2
3
4
5
6
7
8

# Basic session
aider src/api/handlers.py src/models/user.py

# Adjust repo map size for larger projects
aider --map-tokens 4096 src/api/handlers.py

# Run without repo map (faster for single-file work)
aider --no-map src/utils/string_helpers.py

Architect/Editor Mode

Aider’s most practically useful configuration for complex tasks is architect/editor mode. The architect model (ideally a strong reasoning model) proposes the changes in plain English. The editor model (a cheaper, faster model) turns that proposal into precise file diffs.

1
2
3
4
5
6
7

# Use claude-opus-4-7 as architect, sonnet as editor
aider --architect --model claude-opus-4-7 --editor-model claude-sonnet-4-6

# Local variant: Qwen3-Coder as architect, qwen2.5-coder:7b as editor
aider --architect \
  --model ollama/qwen3-coder:32b \
  --editor-model ollama/qwen2.5-coder:7b

The architecture exists because frontier models reason brilliantly but sometimes mangle structured diff output, while smaller models are reliable at diff format compliance but weaker at planning. Splitting the job measurably reduces multi-file edit errors. On typical workloads, architect-mode runs cost 30–50% less than using the architect model alone for both reasoning and editing.

Edit Formats

Aider supports multiple edit formats, which matters when you’re running local models that don’t all handle the same output format:

udiff      — unified diff format (most reliable on fine-tuned coding models)
diff       — search-and-replace style diffs (good for instruction-tuned models)
whole      — full file rewrite (expensive but robust for weaker models)
editor-diff / editor-whole — used in architect/editor mode

For local models, whole format trades token efficiency for reliability. If your 32B model is producing malformed diffs, switch to whole and accept the extra tokens.

Model Support

Aider supports any OpenAI-compatible API endpoint plus native integrations for Anthropic, Ollama, LM Studio, llama.cpp, and most cloud providers. The --model flag accepts litellm-style model strings.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Anthropic cloud
aider --model claude-sonnet-4-6

# Local Ollama
aider --model ollama/qwen2.5-coder:32b

# Custom OpenAI-compatible endpoint (e.g., vLLM)
OPENAI_API_BASE=http://192.168.1.50:8000/v1 \
OPENAI_API_KEY=none \
aider --model openai/qwen3-coder-32b

Where Aider Works Well

• Multi-file refactors where git history matters for code review
• Projects where you want AI edits integrated into your existing PR workflow
• Teams running private API endpoints who want to avoid cloud-only tooling
• Complex architecture tasks using the architect/editor split

Where Aider Falls Short

• No IDE integration — you’re switching between terminal and editor constantly
• The REPL model means one conversation per session; context doesn’t carry across sessions naturally
• Slower feedback loop than IDE-embedded tools for exploratory work
• Web browsing, tool execution, and multi-step autonomous tasks are outside its design scope

Continue

31K GitHub stars · VS Code + JetBrains · Apache 2.0 license

Continue is the most configurable tool in this group. It lives inside your IDE as an extension, provides inline autocomplete, a chat panel, and a rich @mention system for pulling context into prompts. The key pitch is model freedom: you choose any LLM for any task, and you configure exactly what context gets sent for each use case.

Configuration: config.yaml

Continue migrated from JSON to YAML configuration in late 2024. The config lives at ~/.continue/config.yaml and controls models, context providers, prompts, and rules. New installations should use YAML — it has full feature support and is the path forward.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# ~/.continue/config.yaml
models:
  - name: claude-sonnet-4-6
    provider: anthropic
    model: claude-sonnet-4-6
    apiKey: $ANTHROPIC_API_KEY
    roles:
      - chat
      - apply

  - name: qwen2.5-coder-32b
    provider: ollama
    model: qwen2.5-coder:32b
    roles:
      - autocomplete

  - name: claude-haiku-4-5
    provider: anthropic
    model: claude-haiku-4-5-20251001
    roles:
      - embed
      - summarize

context:
  providers:
    - name: code
    - name: docs
      params:
        sites:
          - startUrl: https://docs.rust-lang.org/std/
            title: Rust std docs
    - name: web
    - name: diff
    - name: open-files
    - name: codebase

rules:
  - name: "Rust style"
    rule: "Use idiomatic Rust. Prefer Result<> over panics. Document public APIs."
    globs: ["**/*.rs"]

Context Providers and @mentions

The @mention system is Continue’s most practical feature. In the chat panel, you can pull in specific context without manually copying:

@file src/api/handlers.rs         — attach a specific file
@code UserService.authenticate    — attach a specific function definition
@docs Rust std HashMap            — search pre-indexed documentation
@web                              — perform a web search
@diff                             — include the current git diff
@codebase                         — run semantic search across the whole repo
@terminal                         — include recent terminal output

Each context provider runs its own retrieval logic. The codebase provider runs embedding-based semantic search; diff pulls the current working tree diff from git; docs uses pre-crawled and indexed external documentation. You configure which providers are available and their parameters.

Slash Commands / Prompt Files

Custom slash commands are defined as prompt files in .continue/prompts/:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<!-- .continue/prompts/review.md -->
---
name: review
description: Review the selected code for bugs and security issues
---
Review the following code for:
1. Logic errors and off-by-one bugs
2. Security vulnerabilities (injection, auth bypass, unsafe deserialization)
3. Missing error handling
4. Performance anti-patterns

Code:
{{{ input }}}

Invoke with /review in the chat panel. The {{{ input }}} template variable receives selected code or typed input.

Model Routing by Role

The roles system lets you assign different models to different tasks, which is the right pattern when you’re mixing local and cloud resources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

models:
  # Local fast model for autocomplete — latency-sensitive
  - name: local-autocomplete
    provider: ollama
    model: qwen2.5-coder:7b
    roles: [autocomplete]

  # Cheap cloud model for embeddings and summarization
  - name: haiku-embed
    provider: anthropic
    model: claude-haiku-4-5-20251001
    roles: [embed, summarize]

  # Capable cloud model for actual coding conversations
  - name: sonnet-chat
    provider: anthropic
    model: claude-sonnet-4-6
    roles: [chat, apply, edit]

This keeps autocomplete fast (local 7B responds in under 200ms on a decent GPU), embeddings cheap (Haiku), and complex reasoning high quality (Sonnet).

Where Continue Works Well

• Teams that need a uniform tool across VS Code and JetBrains
• Projects with well-maintained external documentation you can pre-index
• Environments with strict data residency requirements (fully offline with local models)
• Developers who want fine-grained control over what context is sent to which model

Where Continue Falls Short

• Configuration depth is real overhead — it takes time to tune correctly for your stack
• Autocomplete quality at the 7B–13B local tier is noticeably weaker than Copilot/Cursor Tab
• No autonomous multi-step task execution — it’s a conversation tool, not an agent
• The @codebase semantic search requires an indexing step that can be slow on first run

Cline

58K GitHub stars · VS Code extension · Apache 2.0 license · 5M+ installs

Cline is the highest-autonomy tool in this group that still runs inside your IDE. It became the fastest-growing open-source AI project in 2024 by being the first VS Code extension to do what Claude Code does in the terminal: read and edit files, run shell commands, browse the web, and work through multi-step tasks — all from within the editor you’re already in.

The defining design choice is explicit approval gates. Every action Cline wants to take — create a file, edit a file, run a command, make a browser request — requires your explicit approval. This makes sessions slower but fully auditable. Nothing happens without you seeing it.

How It Actually Works

When you give Cline a task, it enters a loop:

1. Plan: What needs to happen?
2. Act: Propose the next action (file edit, command execution, etc.)
3. Request approval: Show the diff / command / action to the user
4. Execute (on approval): Apply the change
5. Observe: Did it work? Check stderr, file content, test output
6. Loop or finish

The “observe” step is critical. Cline reads back the results of commands it ran, checks that file edits applied correctly, and adjusts the plan based on actual output. This is what makes it genuinely agentic rather than just “a chatbot that can write to files.”

Tool Capabilities

Cline has access to:

read_file          — read any file in the workspace
write_to_file      — create or overwrite files
replace_in_file    — apply targeted search-and-replace edits
execute_command    — run shell commands (with approval)
browser_action     — control a headless browser (Puppeteer)
use_mcp_tool       — invoke tools from connected MCP servers
search_files       — grep across the workspace
list_files         — directory traversal
attempt_completion — signal that the task is done

The MCP integration is significant: Cline can connect to any MCP server, which means tools for database access, external APIs, GitHub operations, and custom domain-specific tools all flow through the same approval UI.

Custom Instructions and Modes

Cline supports a .clinerules file in the project root for persistent instructions:

1
2
3
4
5
6
7
8
9

# .clinerules

You are working in a Rust workspace. Rules:

- All public functions must have doc comments
- Use `thiserror` for error types, not hand-rolled enums
- Run `cargo clippy` before considering any change complete
- Never use `unwrap()` in library code; use `?` or explicit error handling
- The main crate is in `crates/core/`; integration tests live in `tests/`

You can also define custom modes (via cline_docs/) that change Cline’s behavior for specific contexts — a strict “read-only review mode” for auditing, an “architect mode” for high-level planning without file writes, etc.

Local Model Performance

Cline works with any OpenAI-compatible endpoint, Anthropic, and Ollama. The practical constraint is that agentic behavior requires models that reliably produce well-formed tool-use calls. At the 32B tier with current models:

Qwen2.5-Coder-32B   — solid; produces valid tool calls ~90% of the time
Qwen3-Coder-32B     — excellent; SWE-bench verified ~55%+ with agentic scaffold
DeepSeek-Coder-V2   — good for code generation, inconsistent tool-use format
CodeStral 22B       — fast, good for smaller tasks; sometimes drops tool params
Llama-3.3-70B       — works but general-purpose; weaker at multi-step planning

At 70B+ (Q4 fits in ~48GB VRAM), quality approaches the frontier models for most practical tasks. The gap versus Claude Sonnet on autonomous coding narrows considerably at 70B.

1
2
3
4
5
6

# Configure local Ollama in Cline VS Code settings
{
  "cline.apiProvider": "ollama",
  "cline.ollamaBaseUrl": "http://localhost:11434",
  "cline.apiModelId": "qwen2.5-coder:32b"
}

Cost Reality

The fully local setup costs zero per token beyond electricity. For teams that run Cline against cloud APIs:

5 developers, Claude Sonnet 4.6, active use:    ~$50–150/month
10 developers, same:                             ~$100–300/month
Cursor Pro (10 seats):                           $200/month flat

The BYOK model pays off at team scale, especially when usage patterns are uneven — high-use developers don’t penalize light users.

Where Cline Works Well

• Feature development where you want an agent that can execute, test, and iterate
• Projects where every file change being reviewed and approved is a requirement
• Teams already in VS Code who want agentic capability without leaving the editor
• Offline/air-gapped environments using local Ollama models

Where Cline Falls Short

• The approval-gate UX creates friction for routine tasks — you click approve a lot
• Performance degrades with weaker local models that produce malformed tool calls
• Long tasks with many steps can lose coherence as context fills up
• No native CI/CD integration — you need to orchestrate that yourself

OpenHands

68K GitHub stars · Docker-based · MIT license · Backed by All Hands AI ($18.8M Series A)

OpenHands (formerly OpenDevin) is the most ambitious tool in this group. It’s not an IDE extension or a terminal REPL — it’s a platform. The agent runs in a Docker sandbox with full filesystem access, a browser, a shell, and MCP tool access. You give it a task, and it works through it autonomously with minimal human interaction.

Architecture

The core runtime model is isolation through Docker. Each OpenHands session gets its own container:

┌─────────────────────────────────────────────────────┐
│  OpenHands Controller (Python, port 3000)           │
│  ┌──────────────────────────────────────────────┐   │
│  │  Agent (CodeActAgent, default)               │   │
│  │  - Plans using LLM                           │   │
│  │  - Issues actions: IPythonRunCellAction,      │   │
│  │    CmdRunAction, BrowseInteractiveAction       │   │
│  │  - Reads observations from sandbox           │   │
│  └──────────────────────────────────────────────┘   │
│                      │ socket                        │
│  ┌──────────────────────────────────────────────┐   │
│  │  Sandbox Container                           │   │
│  │  - /workspace volume mount                  │   │
│  │  - ActionExecutionServer (FastAPI)           │   │
│  │  - IPython kernel for code execution         │   │
│  │  - Chromium (Playwright) for browser         │   │
│  └──────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘

The controller communicates with the sandbox over a socket. The agent sends structured actions (IPythonRunCellAction to run Python, CmdRunAction for shell commands, BrowseInteractiveAction for browser operations) and receives structured observations (stdout, stderr, browser screenshots, file content).

This architecture is the reason OpenHands can do things Cline can’t: long-running test suites, dependency installation, environment setup from scratch. The sandbox is disposable and reproducible.

Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Basic local deployment
docker pull docker.all-hands.dev/all-hands-ai/openhands:main

docker run -it \
  --pull=always \
  -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/openhands-runtime:main \
  -e LOG_ALL_EVENTS=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.openhands-state:/.openhands-state \
  -p 3000:3000 \
  --add-host host.docker.internal:host-gateway \
  --name openhands-app \
  docker.all-hands.dev/all-hands-ai/openhands:main

Note the Docker socket mount: OpenHands needs to spawn its own sandbox containers. This is the security surface area to be aware of. The controller process has full Docker control on the host.

Microagents

OpenHands supports microagents — specialized sub-agents that handle specific domains. There are two types:

Knowledge microagents inject relevant documentation when specific keywords appear in a task:

.openhands/microagents/
├── cargo.md    — triggered when "cargo" or "Rust" appear in the task
├── django.md   — triggered on Django-related tasks
└── k8s.md      — triggered for Kubernetes work

Task microagents are agents for specific structured tasks (like “run tests”, “open a PR”, “deploy to staging”). They’re invoked via @agent_name in the task description.

v1.6 and Planning Mode

OpenHands v1.6 (March 2026) shipped Kubernetes support for multi-tenant deployments and a Planning Mode beta. Planning Mode adds a structured pre-execution phase where the agent produces a written plan for the task and requests confirmation before starting execution. This addresses one of the common failure modes in fully autonomous agents: large irreversible changes that don’t match the user’s intent.

Headless Mode / API

For CI/CD integration, OpenHands exposes a REST API for programmatic task submission:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import requests

response = requests.post(
    "http://localhost:3000/api/conversations",
    json={
        "task": "Add comprehensive unit tests for all functions in src/utils/",
        "model": "claude-sonnet-4-6",
        "max_iterations": 30,
    },
    headers={"Authorization": f"Bearer {API_KEY}"}
)

conversation_id = response.json()["conversation_id"]

# Poll for completion
import time
while True:
    status = requests.get(
        f"http://localhost:3000/api/conversations/{conversation_id}/status"
    ).json()
    if status["state"] in ("finished", "error"):
        break
    time.sleep(5)

This is what enables OpenHands in a CI pipeline: submit a task, wait for completion, inspect the resulting diff.

Where OpenHands Works Well

• End-to-end feature development: “implement user authentication with JWT, add tests, update the README”
• Automated PR review and refactoring on CI
• Tasks that require real environment setup: installing dependencies, running database migrations, testing against real services
• Research and prototyping where you want to explore solutions without hands-on driving

Where OpenHands Falls Short

• Cold start overhead is non-trivial — spinning up a sandbox container takes 10–30 seconds
• Long tasks in weak models produce runaway loops that consume tokens without progress
• Docker socket dependency is a security concern in shared environments
• Less interactive than Cline for exploratory work where you’re figuring out what you want as you go

The Comparison Table

vs. Claude Code and Cursor

Claude Code (the tool you’re likely reading this on) sits in a different class for users who are already in the Anthropic ecosystem. It’s not open-source, it’s terminal-based like Aider, and it’s built exclusively around Claude models. The specific advantages over the open-source stack:

• Significantly faster per-edit throughput (3x more edits per minute vs Cline in benchmarks)
• Deep Claude model optimization — the tool calls are designed by the same team that designed the models
• Agent SDK for building custom sub-agents and orchestration
• No configuration required — it works immediately with correct defaults

The open-source tools win when model freedom, data residency, or cost structure matter. If you’re paying for Anthropic API access and happy with Claude, Claude Code is the right call. If you need fully local inference with no external dependencies, Cline or Aider against Ollama is the answer.

Cursor is the most polished IDE experience in the coding assistant market but occupies a different trade-off point: excellent UX, no local model support, subscription pricing. There is no BYOK option — Cursor runs all inference on its own infrastructure. For teams where code must not leave the network, Cursor is off the table. For teams where convenience and per-seat subscription are acceptable, Cursor is genuinely very good.

Local Model Reality at 32B–70B

The practical question for homelab use: do local models actually work for these tools, and at what tier does quality become acceptable?

Hardware requirements (rough Q4 quantization):

7B model    →  ~5–6 GB VRAM   (RTX 3060, any modern gaming GPU)
13B model   →  ~9–10 GB VRAM  (RTX 3080/3090)
32B model   →  ~22–24 GB VRAM (RTX 3090, RTX 4090, dual 3080)
70B model   →  ~48 GB VRAM   (dual 3090, A100, multiple 4090s)

Model quality for coding tasks (ordered, as of May 2026):

Tier 1 (competitive with Claude Sonnet for coding):
  Qwen3-Coder 480B/A35B    — MoE, requires serious hardware
  Qwen3-Coder-32B          — best single-node local option, SWE-bench ~55% verified

Tier 2 (useful for most practical tasks):
  Qwen2.5-Coder-32B        — 73.7 on Aider benchmark (comparable to GPT-4o)
  DeepSeek-Coder-V2        — strong on generation, weaker on agentic tool use
  Llama-3.3-70B            — good general-purpose; not fine-tuned for code

Tier 3 (acceptable for simple tasks, rough edges on complex ones):
  CodeStral 22B            — fast, 1.4s avg response, limited context
  Qwen2.5-Coder-7B         — fast for autocomplete, not for autonomous coding

The honest assessment: at 32B with Qwen3-Coder, you can handle most routine development tasks autonomously. Multi-file refactors work. Unit test generation works. Explaining complex code works. What breaks down is: novel algorithmic problems, large-scale architecture decisions, and tasks that require reasoning about implicit constraints your codebase has accumulated over years. For those, routing to cloud APIs is the right call, and the BYOM tools support exactly that hybrid pattern.

Token throughput comparison:

Consumer GPU (RTX 4090), 32B Q4:      ~25–35 tokens/sec
Cloud API (Claude Sonnet 4.6):        ~60–80 tokens/sec
Cloud API (Claude Opus 4.7):          ~30–50 tokens/sec

For long outputs (200+ lines of code), cloud APIs are significantly faster. Local inference is competitive on short-to-medium responses where startup latency isn’t diluted by generation time. For Aider-style autocomplete where the response is a targeted diff, local 32B is perfectly usable.

Setup Patterns

Pattern 1: Pure Local (Air-Gapped)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Install Ollama
curl -fsSL https://ollama.ai/install.sh | sh
ollama pull qwen2.5-coder:32b

# Aider against local Ollama
pip install aider-chat
aider --model ollama/qwen2.5-coder:32b --no-show-model-warnings

# Cline: set provider to "ollama" in VS Code settings
# Continue: add ollama provider in config.yaml

Pattern 2: Hybrid (Local for Routine, Cloud for Hard)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Continue config.yaml — local for speed, cloud for quality
models:
  - name: local-autocomplete
    provider: ollama
    model: qwen2.5-coder:7b
    roles: [autocomplete]

  - name: cloud-reasoning
    provider: anthropic
    model: claude-sonnet-4-6
    roles: [chat, apply, edit]
    apiKey: $ANTHROPIC_API_KEY

1
2
3
4

# Aider architect mode — local architect, cloud editor
aider --architect \
  --model ollama/qwen3-coder:32b \
  --editor-model claude-haiku-4-5-20251001

Pattern 3: Team Self-Hosted

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# docker-compose.yml for team-shared Ollama + OpenHands
services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama-data:/root/.ollama
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    ports:
      - "11434:11434"

  openhands:
    image: docker.all-hands.dev/all-hands-ai/openhands:main
    environment:
      - LLM_API_KEY=ollama
      - LLM_BASE_URL=http://ollama:11434
      - LLM_MODEL=ollama/qwen2.5-coder:32b
      - SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/openhands-runtime:main
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /workspace:/workspace
    ports:
      - "3000:3000"
    depends_on:
      - ollama

volumes:
  ollama-data:

Picking the Right Tool

The decision tree is relatively clean once you know what matters to you:

Use Aider if: You live in the terminal, you want every AI edit to be a git commit, and you’re working on multi-file refactors where repo-wide context matters. The tree-sitter repo map is genuinely useful at scale.

Use Continue if: You want a configurable IDE extension with precise control over what context goes to what model, and your primary use case is chat-augmented editing rather than autonomous task execution. Especially good if you need JetBrains support.

Use Cline if: You want VS Code-embedded agentic behavior with explicit approval gates, and you’re working on feature development where the agent needs to read, write, run, and iterate. The best middle ground between autonomy and oversight.

Use OpenHands if: You need fully autonomous execution on reproducible, sandboxed environments — CI/CD integration, large refactoring jobs, or tasks that involve environment setup and real command execution. Accept the Docker complexity.

Use Claude Code if: You’re already paying for Anthropic API access, you work primarily in the terminal, and you want the tool that’s most tightly optimized for Claude models without configuration overhead.

None of these tools are permanent. The space is moving fast — Roo Code forked Cline to improve autonomy, Kilo Code forked both, and several new entries appear monthly. The architecture and local model guidance above will hold up longer than specific version comparisons. What’s stable: the four categories (terminal REPL, IDE extension, autonomous agent, platform), the local model tier recommendations, and the fundamental trade-off between control and autonomy.