DEV Community: TerminalBlog

What developers actually say about Claude Code vs Cursor

TerminalBlog — Fri, 31 Jul 2026 04:33:16 +0000

Originally published at terminalblog.com.

Community threads about Claude Code vs Cursor are noisy, but the same patterns show up across Hacker News, Reddit, Discord, and team chats. This page compresses what developers repeat—not marketing claims—and turns it into an operator checklist.

For a full product matrix and default-versus-specialist call, read the main Claude Code vs Cursor comparison. This article is about how people talk about the trade-off when they have used both for real work.

Quick verdict from the community pattern

Crowd says…	When it holds	When it fails
Cursor wins for day-to-day typing speed	IDE-native edits, tab-heavy workflows	Multi-hour unattended terminal jobs
Claude Code wins for long tool loops	Migrations, CI babysitting, multi-file planning	Orgs that ban terminal agents
Hybrid is common	IDE for interactive, terminal for deep work	Shared branches without isolation
“Just use both” needs policy	AGENTS.md names default + specialist	Two tools fight over lockfiles

What people praise about Cursor

Developers who prefer Cursor repeatedly cite:

Inline speed inside a familiar IDE
Lower friction for small refactors and UI work
Strong “stay in flow” feeling for senior and mid-level engineers who live in the editor

The complaint pattern is also consistent: when work becomes a long autonomous loop (many shell steps, overnight jobs, heavy PR generation), Cursor fans often add a terminal agent rather than force the IDE to be a fleet worker.

What people praise about Claude Code

Developers who prefer Claude Code repeatedly cite:

Strong planning and multi-file tool use in the terminal
Feeling “agent-like” rather than “autocomplete-like”
Good fit for migrations, repo-wide chores, and iterative fix loops

The complaint pattern: onboarding and IDE integration feel heavier if your whole culture is VS Code-first and nobody wants a second surface. Some teams also report review debt when Claude Code produces large multi-file PRs without worktree discipline.

When to choose which path (community-informed)

Choose Cursor-first when

Most of the team’s day is interactive editing in an IDE
Leadership optimizes for time-to-first-keystroke productivity
Multi-file agent autonomy is still politically hard

Choose Claude Code-first when

Tickets are multi-step, tool-heavy, and measured by mergeable outcomes
Terminal culture already exists (scripts, CLIs, CI debugging)
You need deeper agent loops more than tab-complete speed

Choose hybrid when

You already hear both praise patterns inside the same team
You can write policy: Cursor for interactive, Claude Code for long jobs
You can enforce separate worktrees and human merge gates

Failure modes the community actually reports

Ignore pure brand warfare. Trust reports that include what broke:

Merge hell — two agents (or agent + human) on one branch without isolation.
Cost surprise — agent retries and full-repo context dumps dominate the bill.
False confidence — green demo, red CI after human review finds invented files.
Permission sprawl — shell and network access without a written deny-list.
Tool thrash — switching defaults every week because Twitter changed mood.

If a thread does not mention one of these, treat it as entertainment.

How to convert anecdotes into a team decision

Do not vote with emoji reactions. Run a one-week protocol:

Pick three production-like tickets (one UI, one migration, one CI failure).
Assign half the pilot group Cursor-first, half Claude Code-first.
Measure: time-to-mergeable draft, review comments, incidents, and spend.
Interview for friction (“where did you leave the tool?”).
Write the default, the specialist, and forbidden actions into AGENTS.md.

Community consensus is a prior, not a verdict. Your monorepo, OS fleet, and compliance rules can flip the default.

Quotes you can use in an RFC (paraphrased patterns)

These are composite patterns, not attributed quotes:

“Cursor makes me faster at the work I already knew how to do.”
“Claude Code is what I open when the ticket is a project, not a keystroke.”
“We use both; the mess started when both wrote the same branch.”
“Autocomplete is not an agent—stop comparing seat prices as if they were.”

If your RFC cannot answer those four lines with a policy, you are not ready to standardize.

Bottom line

Developers do not agree on a single winner—and that is the useful signal. Cursor tends to win interactive IDE days; Claude Code tends to win long tool-using jobs; hybrids win when policy is written down. Standardize from measured tickets and AGENTS.md, not from the loudest thread of the week.

- Coding agents vs GitHub Copilot: autocomplete is not an agent

Related: feature matrix, security checklist.

Operator close: what devs say claude code vs cursor

For what devs say claude code versus cursor, treat the earlier verdict as a default, not a religion. Run three production-like tickets on both tools the same week: one small interactive edit, one multi-file change, and one recovery from a red CI log. Score mergeability, review debt, secret/tool incidents, and spend. Prioritize unattended safety (logs, caps, human gates) if cron is in scope.

Write the outcome in AGENTS.md for this pair: default tool, specialist tool, worktree policy, and forbidden actions (force-push, production secrets, unattended deploys without a human gate). Revisit when headcount, compliance, or model pricing changes. Prefer updating this URL (what-devs-say-claude-code-vs-cursor) with a fresh updatedDate over inventing a near-duplicate slug.

If both still look equal after three real tickets, pick clearer permissions UX and better recovery from red CI—not the louder social thread. Keep human merge gates for production. Agents accelerate drafts; they do not replace review culture on what devs say claude code / cursor work.

Measurement notes for what-devs-say-claude-code-vs-cursor

Record the model pin, token/spend cap, OS used, and ticket IDs for the three pilot tasks on this pair. Without those fields, “we tried both” is not evidence. Re-run the pilot when either product ships a major agent-loop change.

Document the rollout: default tool, specialist tool, worktree policy, secret policy, and a quarterly review date. Prefer one strong updated URL over ten thin near-duplicates. Measure jobs, not brand heat.

If the two tools still look equal after three real tickets, pick the one with clearer permissions UX and better recovery from a red CI log—not the one with more social proof.

Keep human merge gates for production. Agents accelerate drafts; they do not replace review culture.

Adoption signals from the leaderboard are relative context. A quieter tool with better permissions can beat a louder brand on your monorepo.

Coding agent features in 2026: who actually has cron, subagents, and multi-provider routing

TerminalBlog — Fri, 31 Jul 2026 04:32:22 +0000

Originally published at terminalblog.com.

Feature pages fail when they are marketing tables with no operator meaning. This guide maps capabilities that change how you work—scheduling, subagents, multi-provider routing, local-first—across the agents terminalblog tracks. Use it before you standardize a team default.

For ranked adoption (stars, commits, package downloads), see the open-source leaderboard. For “which agent for my job,” start with the 2026 decision guide.

Quick verdict

There is no single “most featured” winner. Pick by the missing row that blocks your workflow:

Need overnight jobs → require cron / scheduling (e.g. Hermes, pi.dev-class tools).
Need fan-out tickets → require subagents (Claude Code, Hermes, Cursor-class).
Need escape from one model vendor → require multi-provider (Hermes, OpenCode, Goose, many OSS CLIs).
Need IDE-native edits → Cursor-class IDE agents beat pure terminal tools for day-to-day typing.

Everything else is preference and polish.

Feature matrix (operator-relevant)

Flags below summarize terminalblog’s agents.json positioning (not a live probe of every release). Always verify on upstream docs before you buy a process.

Capability	Why it matters	Typical owners
Vision / screenshots	UI bugs without paste hell	Hermes, Oh My Pi, some desktop agents
Cron / scheduling	Unattended fleets	Hermes, pi.dev
Multi-provider routing	Model churn + cost control	Hermes, OpenCode, Goose, many OSS
Git integration	PR loops without glue scripts	Claude Code, Codex, Cursor, most serious CLIs
Plugins / skills	Team-specific workflows	Claude Code, Hermes, OpenCode, Goose
Subagents / teams	Parallel work with review debt	Claude Code, Hermes, Cursor, Codex
Background tasks	Long jobs without babysitting	Varies widely
Local-first	Data residency / offline	Most OSS terminal agents

How to read “Yes” without getting burned

A Yes is not automatic superiority.

Cron without logs and budget caps is a foot-gun: you discover failures after deploy is already broken.
Subagents without worktree isolation create merge hell and double token bills.
Multi-provider without policy becomes random model roulette mid-PR.
Plugins without pin/versioning are a supply-chain risk (especially MCP).
Vision without a secrets policy means screenshots of staging dashboards can leave the building.

Pair this matrix with the security checklist.

When to choose which path

Choose a capability-first shortlist when

You already know your job-to-be-done (cron, IDE, multi-provider, security)
You need a default tool class before comparing two brands

Choose a specific pair page when

You have narrowed to two agents and need a default-versus-specialist call
You are writing AGENTS.md policy for a team

Choose to wait or stay on autocomplete when

Your organization cannot absorb multi-file agent risk yet
You only need faster typing inside the editor

Capability-first shortlists

If you need unattended automation

Prioritize agents with cron + background tasks + credential discipline. Interactive-only CLIs should stay as pair tools, not fleet workers. Require:

Separate API keys for unattended jobs
Logs that survive terminal close
Hard step or dollar caps
A human gate for force-push and production changes

If you need deep multi-file refactors in a polished terminal

Prioritize strong planning/subagents and git integration (often commercial terminal agents). Budget for seats or high token use. Measure on a real migration ticket, not a toy repo.

If you need provider neutrality

Prioritize multi-provider OSS CLIs. Accept more configuration in exchange for not dying when one vendor rate-limits you. Document which models are allowed for which job classes (cheap for drafts, strong for merge-ready work).

If you need IDE speed

Prioritize IDE-native agents for daily edits; keep a terminal agent for migrations and CI babysitting. Hybrid is normal. Do not force one surface to do every job poorly.

Job-to-capability mapping

Use this table in planning meetings so brand debates stay grounded:

Job	Must-have capabilities	Nice-to-have
Overnight dependency bumps	Cron, background tasks, git PR loop	Multi-provider for cost
UI bugfix from a screenshot	Vision, multi-file edit	Local-first if data is sensitive
Parallel ticket fan-out	Subagents, worktree isolation	Team/review workflows
Escape a model outage	Multi-provider routing	Cached prompts / skills
Air-gapped or regulated code	Local-first, pinable versions	Offline docs / plugins

If a candidate tool is missing a must-have for your top job, it is not a finalist—no matter how popular it is on social feeds.

How to keep this matrix honest over time

Features ship weekly. Re-validate cron, subagents, and multi-provider claims against upstream release notes before a company-wide rollout. Prefer a short internal table of “we verified on date X” over a permanent belief that a marketing checkbox is still true.

When two agents both claim the same capability, break the tie with failure modes:

Who recovers better from a red CI log?
Who invents fewer phantom files?
Who asks before destructive shell commands?
Who behaves sanely on Windows path edge cases if that is your fleet?

Adoption signals on the leaderboard (stars, commits, package downloads) are relative context. They do not prove fitness for your monorepo.

Related pair deep-dives

Individual pair pages (for example Hermes vs Claude Code, OpenCode vs Codex, Kilo vs pi.dev) apply this matrix to two products with a default-versus-specialist verdict. Prefer updating those URLs over inventing new near-duplicate slugs.

When you standardize, write into AGENTS.md:

Default tool and specialist tool
Required capabilities for unattended jobs
Forbidden actions and merge gates
A quarterly re-check of the matrix rows you depend on

Evaluation protocol (one afternoon)

Pick three production-like tasks (one migration, one CI failure, one small feature).
Shortlist two tools that cover the must-have rows.
Run both tools on the same tasks with the same model budget where possible.
Score: time-to-mergeable draft, review debt, secret/tool incidents, cost.
Publish the default/specialist decision and the date you will re-open it.

If you skip the protocol, you will re-litigate brands every quarter without improving delivery.

Bottom line

Choose the missing capability first, brand second. Re-check the matrix quarterly—agent harnesses ship faster than most internal standards. Cron, subagents, multi-provider routing, and local-first are the rows that change architecture; the rest is packaging.

- Coding agents vs GitHub Copilot: autocomplete is not an agent

Building multi-model workflows? *aiFiesta** can simplify access while you evaluate agents.*

Orchestration Topology Is the New Bottleneck in Agentic Coding

TerminalBlog — Fri, 31 Jul 2026 04:32:15 +0000

Originally published at terminalblog.com.

There's a quiet shift happening in agentic coding that most developers haven't noticed yet. It's not about a new model release. It's not about a better prompt template. It's about something far more structural: the topology of how agents coordinate now matters more than which model powers each agent.

If you've been chasing the "which model is best" question in 2026, you've been asking the wrong question. The real lever has moved up a level.

The convergence problem

In mid-2025, choosing between Claude, GPT-4, Gemini, or DeepSeek for your coding agent felt like a genuine decision. Each model had clear strengths. Claude was better at long-context refactors. GPT-4 was faster at boilerplate. Gemini excelled at specific tool-calling patterns.

By July 2026, that differentiation has largely collapsed. Claude Opus 4.7, GPT-5.4, Gemini 2.5 Pro, and DeepSeek V4 Pro all score within single-digit percentage points of each other on SWE-bench Verified. The benchmark era of "one model to rule them all" is ending — not because models got worse, but because they all got good enough.

This convergence creates an awkward reality: when every model can solve the problem, the model isn't the bottleneck anymore.

Enter orchestration topology.

What is orchestration topology?

Orchestration topology is the structural pattern you use to coordinate multiple agents working on the same task. It answers the question: given a complex task that needs decomposing, how do you assign, parallelize, and recombine the work?

The AdaptOrch framework (published earlier this year on arXiv) formalized four canonical topologies:

Topology	Structure	When it wins
Parallel	Multiple agents work on independent subtasks simultaneously	File-boundary tasks, test generation, documentation
Sequential	Each agent's output feeds the next agent's input	Pipelines with clear handoffs (lint → test → deploy)
Hierarchical	One coordinator agent delegates to specialist workers	Complex multi-domain tasks needing architectural consistency
Hybrid	Mix of parallel workers with hierarchical coordination	Most real-world repos with coupled and uncoupled zones

The framework's key finding: topology-aware orchestration achieves 12–23% improvement over static single-topology baselines, even when using identical underlying models. That's a larger performance gap than most model upgrades deliver.

Put differently: switching from Claude to GPT-5.4 might give you 5% on a benchmark. Switching from flat parallel to topology-aware routing gives you 23%. The optimization target has shifted.

The git worktree revolution (yes, from 2015)

Here's the delicious irony at the center of this trend: the foundational infrastructure for parallel agent orchestration isn't new AI tooling. It's git worktrees — a feature that shipped in Git 2.5, back in August 2015.

A worktree lets you check out multiple branches simultaneously in separate directories, all sharing one .git object database. It was designed for the boring use case of cherry-picking from two branches without stashing. Nobody imagined it would become the load-bearing primitive for AI agent isolation.

But here's why it works so perfectly for agents:

Isolation without duplication. Each agent gets its own working directory, its own branch, its own index. It can read, write, delete, and refactor files without touching another agent's workspace. Yet all agents share one git history, so merging results is trivial.

Atomic boundaries. The filesystem boundary maps cleanly to task boundaries. If Agent A is refactoring src/auth/ and Agent B is rebuilding src/api/, they literally cannot conflict. The worktree enforces what coordination protocols struggled to guarantee.

Zero new infrastructure. No message bus. No shared state database. No distributed locking. Git already solved concurrent file editing for humans; it solves it for agents too.

The tool ecosystem caught on fast. By Q2 2026, nearly every major coding agent had shipped worktree support:

Claude Code added --worktree mode for parallel task isolation
Codex uses dedicated worktrees for background automations
Agent Orchestrator (8.5k stars) manages fleets of agents across isolated worktrees with a TUI
Conductor, Claude Squad, Vibe Kanban, and a dozen others built entire orchestration products on top of this primitive

The conductor pattern

The dominant orchestration pattern in July 2026 isn't the elaborate multi-agent choreography that dominated 2025 research papers. It's simpler and, frankly, more honest.

The conductor pattern works like this:

Decompose the work into independent tasks (by file boundary, not by feature)
Dispatch one agent per task into its own git worktree
Run agents in parallel, unattended
Review each diff as it lands
Merge the good, discard the bad, re-prompt the salvageable
Repeat

The human holds the baton. The agents execute in isolation. Git handles convergence.

This is a radical departure from the "agents talking to each other" vision that defined 2024-2025 multi-agent research. The breakthrough insight: the agents stopped talking. That was the upgrade.

Why? Because agent-to-agent communication was the primary failure mode. Context bleeds. Contradictory state updates. Cascading hallucinations across message boundaries. When you remove the communication channel and let git handle coordination, the failure modes collapse to the familiar: bad diffs that humans know how to review.

The Conductor app (macOS, used at Linear, Vercel, Notion, Spotify per community reports) popularized the name. But the pattern transcends any single tool.

The real bottleneck is decomposition, not execution

Here's the uncomfortable truth for anyone adopting parallel agent workflows: the bottleneck has moved from the model to the human.

When you dispatch five agents to work on five subtasks, you need to decompose the work so those subtasks are genuinely independent. This is harder than it sounds. Developers naturally think in features ("build the checkout flow"), but parallel agents need task boundaries defined by file ownership and dependency, not feature scope.

A study on cohesion-aware task partitioning (Co-Coder, published on arXiv) formalized this: build dependency graphs from static analysis, isolate structural hub files (the ones everything depends on), partition by community detection, then dispatch with a dependency-aware scheduler.

The practical heuristic: if two subtasks touch the same file, they're not independent. Split by module, by directory, by concern — not by user story.

Teams that master decomposition see 2x throughput improvements and 35% cost reductions (because agents don't waste tokens on shared context they don't need). Teams that decompose poorly get six half-conflicting pull requests and an afternoon of merge archaeology.

Self-evolving agents: the next frontier

While parallel orchestration is the practical present, a more speculative trend is gaining momentum: agents that improve their own source code.

Three distinct approaches are emerging:

Source-level rewriting (MOSS)

The MOSS framework (published May 2026) lets agents identify gaps in their own tool-calling logic and patch them autonomously. The agent fails on a task, analyzes why, generates a patch to its own Python or TypeScript modules, runs its test suite, and deploys the fix. The companion paper Ratchet provides monotonic improvement guarantees — each modification must maintain or improve performance.

Skill crystallization (GenericAgent)

GenericAgent (13.5k stars, Python) takes a different approach: every time the agent solves a task, it crystallizes the execution path into a reusable Skill. The longer you use it, the more skills accumulate, forming a personal skill tree. At ~3K lines of core code, it claims a fraction of the token consumption of heavier agents.

Trace-based self-evolution (Socratic-SWE)

The most academic approach: Socratic-SWE distills historical solving traces into an Agent Skill Registry — a structured representation of recurring failures and effective repair patterns. These skills then generate targeted training tasks, creating a closed loop where solving traces become the substrate for improvement. It reached 50.4% on SWE-bench Verified after three iterations.

All three approaches share a common philosophy: the agent that solves the problem should also be the agent that learns from it. This closes the gap between runtime behavior and training signal.

What this means for developers

For solo developers

Start with two agents in two worktrees. Run git worktree add twice, dispatch two agents to independent subtasks, and review the diffs side by side. You'll learn decomposition instinctively — the skill every orchestrator tool assumes you already have.

Set iteration limits and per-agent token budgets before you dispatch. Parallelism multiplies your velocity and your bill by the same factor; only the velocity shows up in the demo.

For teams

The conductor pattern maps naturally to team workflows: one person decomposes and reviews, agents execute in parallel. The decomposition skill is the same one good tech leads already use for breaking down sprints — just applied at a finer granularity.

Consider mixing tools across a fleet. A dedicated orchestrator (like Agent Orchestrator or amux) works with any terminal-based agent. Use Claude Code with Opus for architecture, Aider with DeepSeek for bulk refactors, and Codex CLI for OpenAI-specific tasks — all in one parallel run. Tool-agnostic orchestration is a real advantage over built-in multi-agent features that lock you into one ecosystem.

For the industry

The optimization target has officially shifted. Model selection is table stakes. Orchestration topology is the new first-class optimization target. Teams that master decomposition, parallel dispatch, and efficient merge workflows will pull ahead of teams still debating which model to use.

Expect this gap to widen. As the Anthropic 2026 Agentic Coding Trends report puts it: "Organizations that figure out how to scale human oversight without creating bottlenecks are better positioned to maintain quality while moving faster."

The tools to watch

Tool	What it does	Stars	Sweet spot
Agent Orchestrator	Fleet IDE with tmux sessions, worktree isolation, CI feedback loops	8.5k	Full orchestration with monitoring
Claude Squad	Terminal-native tmux wrapper for parallel agents	Growing	Quick setup, zero overhead
Vibe Kanban	Kanban board = worktree = agent, cross-platform	Open source	Visual task tracking
amux	Single-file Python server with SQLite task board	Utility	DIY orchestrators
Conductor	macOS GUI with unified diff review	Reference	UX-first workflow

The bigger picture

Every time we discover what agents are genuinely good at, some intelligence migrates down — from the agent layer into version control, into the shell, into the human's decomposition decisions. The agents didn't get demoted. They got specialized: pure execution units, isolated and disposable, while coordination went back to the tools that have handled concurrent human engineers for decades.

The most important multi-agent advance of 2026 isn't a smarter coordination protocol. It's a 2015 git feature plus human judgment, beating two years of elaborate agent choreography for the most common case.

And the most important optimization you can make right now? It's not switching models. It's learning to decompose.

Cursor Router Automatically Picks the Best Model for Every Coding Task

TerminalBlog — Fri, 31 Jul 2026 01:52:37 +0000

Cursor, the AI-powered code editor from Anysphere, launched Cursor Router on July 22, 2026. It is an intelligent model router that automatically decides which AI model handles each coding request. Instead of every prompt going to the same expensive model, Cursor Router classifies the task first and sends it to the model best suited for the job — saving teams 30 to 50 percent on their AI coding costs without losing output quality.

If you have ever stared at a model picker wondering which model to pick for a quick variable rename versus a complex architecture refactor, Cursor Router is the feature that removes that decision from your workflow entirely.

How Cursor Router works

The core problem Cursor Router solves is simple: most developers pick one model and stick with it. According to Cursor, roughly 60 percent of developers using Cursor choose a single model as their daily driver. That means routine tasks — renaming a variable, updating a comment, fixing a typo in documentation — get processed by the same expensive frontier model used for hard problems. AI spend grows fast while output quality does not.

Cursor Router fixes this by analyzing each request before a model runs. It looks at four things:

The query itself. What you typed and what you are asking for.
The context. The codebase, file types, and project structure around the request.
Task complexity. Whether this is a simple edit or a multi-step reasoning problem.
Domain. Whether the work involves frontend, backend, infrastructure, or something else.

Cursor trained the routing classifier on over 600,000 live coding requests and evaluated it in online A/B tests across millions of real requests. The system optimizes for user satisfaction — measured by whether the developer moves on to the next task (a positive signal) or corrects the agent (a negative one).

The practical result: simple edits go to cheaper, faster models. Complex reasoning tasks go to frontier models like Grok 4.5 or Opus 4.8. UI-focused work goes to models Cursor has identified as strong at that specific task. You do not pick the model. The router does.

Three optimization modes

Cursor Router offers three modes that let you control where you sit on the cost-versus-quality tradeoff:

Intelligence mode aims for frontier quality. It routes to the most capable models available, matching the performance you would get from manually selecting the most expensive option. Cursor reports this mode achieves comparable satisfaction to Fable 5 at roughly 60 percent lower cost, and about 15 percent higher satisfaction than Opus 4.8 at nearly the same cost.

Balance mode targets strong quality at a lower price. It routes to models that most developers would happily use as their daily driver. Cursor says this mode delivers comparable satisfaction to GPT-5.6 Sol at lower cost, and beats Opus 4.8 on satisfaction while costing about 36 percent less.

Cost mode prioritizes token efficiency. It reaches for the best available intelligence but optimizes for lowest spend. This is the mode for teams watching their budget closely.

All three modes bill at the routed model's actual rate — you pay for what was used, not a flat fee.

What the cost data looks like

Cursor shared per-commit cost data from early access testing with enterprise customers:

Metric	Cursor Router (Intelligence)	Cursor Router (Balance)	Opus 4.8	Fable 5	GPT-5.6 Sol
Cost per commit	$6.76	$4.63	$7.34	$12.69	Similar to Intelligence

Three high-volume enterprise accounts with thousands of users saved 30 to 50 percent on routed requests compared to sending everything to Opus 4.8, with no decrease in output quality. The savings come from routine tasks landing on cheaper models while hard tasks still get frontier treatment.

These are not offline benchmark numbers. Cursor measured them using online A/B tests across millions of real coding requests in production, including cache misses from model switching.

Admin controls for teams

Cursor Router is designed for team and enterprise deployment, with granular admin controls:

Enable per team or group. Not everyone has to use the router. Admins choose which teams get it.
Restrict optimization modes. If you want everyone on Balance but not Cost, you can lock that down.
Set the default mode. Choose which mode is pre-selected for team members.
Allow or block specific models. Control which underlying models the router can use.
Show or hide the routed model. By default, the specific model chosen is hidden from the user. Admins can make it visible.

The router is on by default for Teams plans. Enterprise admins can enable it from the dashboard. It is available across desktop, web, iOS, CLI, and Cursor's SDK.

How this compares to other coding agents

Model routing is becoming a theme across coding agents. Here is how Cursor's approach differs:

Claude Code lets you switch models mid-session with /model and supports fallback models configured in settings, but the routing is manual — you pick, the system does not decide for you.

GitHub Copilot CLI supports multiple models including Grok 4.5 and Claude Opus 5, but again relies on the developer choosing which one to use.

OpenAI Codex defaults to its own model family and does not offer cross-provider routing.

Cursor Router is the first coding agent to offer automatic, per-request model routing across multiple providers with configurable optimization modes. The closest analogy is what cloud load balancers do for web traffic — but applied to AI model selection.

What is next

Cursor says it plans to improve the router as new models launch. The classifier is designed so that adding a new model to the routing pool does not require retraining from scratch. Dynamic tool calling — where tool descriptions are loaded on demand instead of in every prompt — is another efficiency improvement running alongside the router.

For teams spending real money on AI coding tools, Cursor Router is worth evaluating. Turn it on in Balance mode for a week, check your usage dashboard, and compare the cost and output quality against your current manual model selection. The data Cursor has published suggests the savings are real and the quality tradeoff is minimal for most daily coding work.

Claude Code Gets Opus 5 as the Default — What the 1M-Context Model Changes for You

TerminalBlog — Fri, 31 Jul 2026 01:51:34 +0000

On July 24, 2026, Anthropic shipped Claude Code v2.1.219 — and it is not a typical patch release. This version makes Claude Opus 5 the default Opus model inside Claude Code, meaning every user on a Max, Team Premium, or API plan now gets Opus 5 without changing a single setting. If you have been waiting for a reason to try Claude Code, or wondering whether to update, this is the version that changes the math.

This guide walks through what Opus 5 actually is, what changes when you update, and which gotchas matter if you are new to Claude Code or coding agents in general.

What is Claude Opus 5?

Claude Opus 5 is Anthropic's most capable model. It replaces Opus 4.8 as the top-tier option inside Claude Code. The headline specs:

1 million token context window — both the default and the maximum. No smaller variant exists. You get the full window without asking for it.
128K max output tokens — the model can write very long responses without hitting the output ceiling.
Thinking on by default — the model decides when and how deeply to reason on each turn. You no longer need to enable thinking manually.
Fast mode — a research-preview speed tier priced at $10/$50 per million tokens (input/output), available on the Claude API.
Pricing unchanged — $5/$25 per million tokens (input/output), same as Opus 4.8.

Compared to Opus 4.8, Anthropic describes Opus 5 as a "step-change improvement" rather than an incremental update. The biggest gains are in deep reasoning, agentic coding (long multi-file tasks), test-time compute scaling (turning up the "effort" dial actually produces better results), and code review accuracy.

What changed in Claude Code v2.1.219

The v2.1.219 release brings several practical changes beyond the model swap. Here is what matters for everyday use:

1. Opus 5 is now the default

If you type claude and press Enter, the model picker now defaults to Opus 5 for Anthropic API, Max, Team Premium, and Enterprise pay-as-you-go users. Pro and Team Standard users default to Sonnet 5 instead. If you previously had Opus 4.8 selected, you will see the upgrade automatically.

To check your current model, run /model inside Claude Code. The picker now highlights the newest model name to make it clear which version you are on.

2. Thinking is on by default

This is the most important behavioral change for beginners. On Opus 4.8, Claude Code ran without thinking unless you explicitly enabled it. On Opus 5, the model thinks by default — it decides on each turn whether and how deeply to reason before responding.

For most users, this means better answers with zero configuration. The model handles the thinking budget automatically. If you want more control, you can adjust the effort level: low, medium, high (the default), xhigh, or max. Higher effort means deeper reasoning at the cost of more tokens and time.

3. Nested subagents go three levels deep

Before v2.1.219, Claude Code subagents could spawn only one level deep (depth 1). Now subagents can spawn their own subagents up to depth 3 by default. This means Claude can delegate a task to a subagent, which can delegate a subtask to its own subagent, which can delegate once more.

If you have a complex task like "refactor the authentication module, update the tests, and verify the API endpoints still pass," Claude can now parallelize more aggressively by spinning up a tree of workers. To disable nesting entirely, set:

export CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1

4. Dynamic workflow size guidelines

Claude Code now defaults to a medium dynamic workflow size — aiming for fewer than 15 agents in a workflow at a time. You can change this in /config under "Dynamic workflow size" or set it from any settings file using the new workflowSizeGuideline key. The current default size is also shown in the running-workflow status line.

5. Sandbox network allowlist

A new sandbox.network.strictAllowlist setting lets you deny all network connections to hosts not on your allowlist — without being prompted each time. This is useful if you want tighter security in sandboxed environments and do not want Claude Code to ask permission for every outbound connection.

6. DirectoryAdded hook

A new DirectoryAdded hook fires whenever you add a working directory mid-session (via /add-dir or the SDK's register_repo_root). This lets you react to directory changes with custom logic — for example, automatically scanning new directories for linting issues or setting up project-specific context.

Gotchas for beginners

Opus 5 introduces a few breaking changes and quirks that catch people off guard:

Disabling thinking requires effort "high" or below. If you set thinking to disabled while effort is xhigh or max, you will get a 400 error. This is a breaking change from Opus 4.8, where thinking and effort were independent. Either lower the effort level or leave thinking enabled.

Opus 4.7 is removed from fast mode. The /fast command now only applies to Opus 5 and Opus 4.8. If you were using fast mode with Opus 4.7, it no longer works.

Remove old verification instructions. Opus 5 verifies its own work without being told to. If you have prompt templates that say "include a final verification step" or "use a subagent to verify," remove them — they cause over-verification on Opus 5 and waste tokens.

Longer default responses. Opus 5 tends to write longer, more detailed responses by default. If you prefer concise output, lower the effort level or add explicit length instructions to your prompt.

How to update

If you installed Claude Code via npm:

npm update -g @anthropic-ai/claude-code

Or run the update command inside Claude Code:

claude update

After updating, run claude --version to confirm you are on v2.1.219 or later. Then run /model to see that Opus 5 is now your default.

What this means for coding agent users

The Opus 5 default in Claude Code raises the baseline for what a terminal coding agent can do. The 1M context window means Claude can read your entire repository without losing track of earlier instructions. The thinking-on-by-default approach means fewer blind spots in complex refactors. And nested subagents at depth 3 mean Claude can break large tasks into parallel work streams without your manual orchestration.

If you are choosing between Claude Code and other terminal agents (Codex, Copilot CLI, OpenCode), Opus 5 widens the capability gap for reasoning-heavy tasks. Copilot CLI also added Claude Opus 5 support in v1.0.75 (released the same day), but Claude Code is the first to make it the default with deep integration — thinking controls, effort tuning, fast mode, and nested subagent depth all built around the model's strengths.

The bottom line: update to v2.1.219, accept the Opus 5 default, and let the model think. Most users will see better results without changing anything.

Codex 0.146.0 Explained: Session Management, Agent Plugins, and Thread Forking for Beginners

TerminalBlog — Fri, 31 Jul 2026 01:51:27 +0000

OpenAI released Codex CLI 0.146.0 on July 29, 2026 — the biggest single release of the summer for the terminal-based coding agent. It ships 239 changes across six new features, dozens of bug fixes, and a new plugin architecture that connects Codex to Amazon Bedrock and Claude Code marketplaces.

If you use Codex day-to-day, three things in this release will change your workflow: named sessions with pinning, thread forking, and Agent Plugins with a skills discovery system. Here's what each does, why it matters, and how to get started.

Named Sessions: Stop Losing Important Threads

Before 0.146.0, every Codex session got an auto-generated name. If you were juggling three tasks — a feature branch, a bug fix, and a refactor — they all blended together in the thread list. Finding the right one meant scrolling and guessing.

Now you can name sessions explicitly:

/new authentication-refactor

Or name an existing session when clearing:

/clear "API rate limiter"

Pin important threads so they stay at the top of your thread list regardless of when you last used them. Switch between side conversations without closing the active one — running a quick test in one thread no longer kills your progress in another.

Why This Matters

Session naming sounds simple until you realize most coding agents treat every conversation as disposable. You run a session, it finishes or you get distracted, and the thread becomes a ghost in your history. Named sessions with pinning turn Codex from a stateless tool into something closer to a project workspace. You can keep your "main branch work" pinned while experimenting in temporary threads that don't clutter the view.

Thread Forking: Branch Conversations Like Git Branches

Thread forking is the most powerful new feature for experienced users. When you're deep in a conversation and want to try a different approach, you can fork the current thread — it creates a copy that carries forward the full paginated history, but any changes you make in the fork don't affect the original.

Think of it like git branch for your AI conversation:

You're 20 turns deep discussing a database migration
You want to try a different schema without losing the original discussion
Fork the thread — the new copy inherits everything up to that point
Make your changes in the fork; the original stays untouched

Forks can be temporary — they won't appear in your thread listings unless you want them to. This means you can experiment aggressively without polluting your main conversation history.

Practical Example

Suppose you're refactoring an authentication module. You're 15 turns into a session, and the agent has generated several files. Now you want to try a completely different approach. Before 0.146.0, you'd either lose the context by starting fresh or keep pushing forward in a thread that's getting tangled.

With forking:

Fork the thread at turn 15 — you now have two identical copies
In the fork, tell the agent "try a JWT-based approach instead"
Keep the original thread if you want to go back to the session-cookie approach
Both threads maintain their full history independently

Agent Plugins: An Ecosystem for Extending Codex

This is the feature that changes Codex's long-term trajectory. Version 0.146.0 introduces Agent Plugins manifests — a standard way to package, publish, and discover plugins that extend what Codex can do.

What Agent Plugins Actually Are

An Agent Plugin is a bundle of capabilities that Codex can load and use during a session. Think of them like VS Code extensions but for a terminal agent. A plugin might provide:

Custom tools the agent can call
Pre-built workflows for common tasks
Integration with external services
Domain-specific knowledge and prompts

Where Plugins Come From

0.146.0 adds support for three plugin marketplaces:

OpenAI's own marketplace — the default source for officially supported plugins
Amazon Bedrock marketplace — plugins distributed through AWS's infrastructure
Claude Code marketplace — plugins from Anthropic's ecosystem, now accessible to Codex users

The Bedrock and Claude Code marketplace integrations are significant because they mean Codex isn't locked into a single vendor's plugin ecosystem. If a useful plugin exists in the Claude Code ecosystem, Codex can discover and use it.

Workspace Plugin Publishing

You can also publish plugins from your own workspace. This is the enterprise story: teams can build internal plugins that encode their specific tools, APIs, and workflows, then distribute them across the organization through the workspace plugin system.

# Discover plugins available to your executor
codex skills list

Codex now auto-discovers executor-provided skills and securely reads their associated resources. If you've configured skills in your environment, Codex will find them automatically.

Skills Discovery: Smarter Tool Selection

Under the hood, 0.146.0 adds a reciprocal rank fusion algorithm for skill selection. In plain terms: when Codex has multiple skills or tools available, it now uses a smarter ranking system to pick the most relevant one for your current task.

Before this release, skill selection was simpler — the agent might pick a tool based on basic keyword matching. Now it considers multiple signals and fuses them together, similar to how search engines combine ranking algorithms.

What This Means in Practice

If you have 10 skills configured — code review, testing, deployment, documentation generation, etc. — Codex is now better at picking the right one without you having to specify it explicitly. Ask it to "review this pull request" and it will prefer the code review skill. Ask it to "deploy this function" and it'll reach for the deployment skill.

The release also improves how Codex handles tight context budgets. When the available context is small, Codex now retains more skills and warns you when skill catalogs must be truncated rather than silently dropping them.

WebSocket Remote Execution

A smaller but important feature: Codex can now connect to remote Code Mode hosts over WebSocket. This means the app-server can delegate execution to a remote machine, opening the door to:

Running Codex on a powerful remote server while controlling it from your laptop
Connecting to cloud-hosted development environments
Sharing a single execution environment across team members

For individual developers, this is most useful if you work on a lightweight laptop but need the agent to run on a machine with more resources. The WebSocket connection keeps the terminal responsive locally while the heavy lifting happens remotely.

Bug Fixes That Matter

Beyond the headline features, 0.146.0 fixes several issues that affect daily use:

Proxy reliability: Proxy settings are now honored across authentication, plugin downloads, MCP authorization, remote execution, WebSockets, redirects, and LM Studio connections. If you're behind a corporate proxy, things should just work now.
MCP connection stability: MCP connections and Apps tools stay current when authentication or configuration changes. Closed servers reconnect without restarting healthy ones.
Windows improvements: Navigation keys are fixed, sandboxed process trees terminate reliably, and proxy settings survive security reviews.
Terminal responsiveness: Nonblocking interrupts, better keyboard handling, and improved rendering on narrow layouts.

How to Update

If you installed Codex via npm:

npm install -g @openai/codex@0.146.0

If you're using the native binary installer:

# macOS / Linux
curl -fsSL https://github.com/openai/codex/releases/latest/download/install.sh | sh

# Windows (PowerShell)
irm https://github.com/openai/codex/releases/latest/download/install.ps1 | iex

Or update through the OpenAI-hosted release infrastructure (new in 0.146.0):

codex --version  # Check current version
codex update     # Update via built-in updater

What This Release Signals

Codex 0.146.0 is a shift from "AI chatbot that writes code" to "AI platform that orchestrates tools." The Agent Plugins system, skills discovery, and remote execution connect together into a vision where Codex is less a standalone agent and more a hub that coordinates multiple specialized tools.

The Bedrock and Claude Code marketplace integrations are particularly notable. Rather than building a walled garden, OpenAI is connecting Codex to other ecosystems. This is the opposite of the desktop-app-to-ChatGPT consolidation we saw earlier in July — the CLI is becoming more open while the desktop app is becoming more locked-in.

For developers choosing between coding agents, the plugin ecosystem is now a real factor. Read our Claude Code vs Codex comparison for the full picture of how the two agents differ, and check what developers say about Codex for community reactions as the product evolves.

The Beginner's Quick Start

If you're new to Codex or just updating from an older version, here's what to try first:

Name your sessions: Run /new my-feature-name before starting work. You'll thank yourself when you have 15 threads and need to find the right one.
Pin your main thread: Pin your primary work thread so it doesn't disappear under temporary experiments.
Fork before risky changes: Before asking the agent to do a major refactor, fork the thread. If the refactor goes sideways, you can pick up from the fork point without losing context.
Explore available skills: Run codex skills list to see what plugins and skills your environment provides. You might find capabilities you didn't know were available.
Update: Install 0.146.0 to get all these features. The proxy and MCP fixes alone are worth the update if you've been hitting connection issues.

The coding agent space is moving fast, and session management is table stakes now. What makes 0.146.0 stand out is the plugin ecosystem — it's the first release where Codex starts feeling like a platform rather than a tool.

OpenAI Codex Now Lets You Name Sessions and Fork Threads

TerminalBlog — Thu, 30 Jul 2026 04:33:42 +0000

Originally published at terminalblog.com

OpenAI Codex released version 0.146.0 on July 29, and it is one of the biggest updates to the coding agent in months. The release adds named sessions, the ability to pin important threads, side conversations you can switch between, a plugin system for agent extensions, and the ability to fork any thread into a new branch.

If you use Codex regularly and have ever lost track of which terminal window was handling which task, or wished you could try a different approach without losing your current progress, this release addresses both problems.

Named sessions: give each task a label

Before v0.146.0, every Codex session was anonymous. You opened a terminal, started working, and if you opened a second terminal for a different task, you had no easy way to tell them apart. Codex now lets you name sessions using /new or /clear.

When you type /new in a Codex terminal, you get prompted for a name. Call it something descriptive — "refactor-auth-module" or "debug-payment-flow" — and that name appears in the session header and in session lists. The /clear command does the same thing: it starts a fresh session and lets you name it immediately.

For beginners, think of this like naming browser tabs. When you have five Chrome tabs open, you rely on the title to know which is which. Named sessions do the same thing for your coding agent sessions.

You can also pin threads. Pinned threads stay at the top of your session list so the ones you are actively working on never get buried under completed sessions. If you are juggling three or four tasks across a workday, pinning the active ones keeps them one keystroke away.

Side conversations without losing context

The new side conversations feature lets you branch off from an existing thread to ask a follow-up question or explore an alternative approach, without disrupting the main conversation. You switch between the main thread and its side conversations using the thread UI.

This is useful when an agent is working on a task and you want to ask "what if I used a different database schema?" without derailing the current work. The side conversation lives alongside the main thread. You can go back to the original conversation at any point.

The practical effect is that you stop losing context when you want to explore alternatives. Before this feature, developers often opened a new terminal session entirely, losing the conversation history with the agent. Now the branch stays connected to the original.

Thread forking: try a different approach safely

Thread forking goes further than side conversations. When you fork a thread, you create a complete copy of the conversation history up to that point, and the fork starts fresh from there. You can then give the agent new instructions without affecting the original thread.

The forked thread has paginated history so you can scroll back through the conversation even when it gets long. Temporary forks — ones you create just to try something quickly — do not clutter your thread listing. They exist only while you are working in them.

Think of forking like creating a branch in git. You are taking the current state, making a copy, and working from there. If the forked approach does not work out, you close it and go back to the original. If it does work, you have a clean record of the alternative path.

For beginners, the difference between side conversations and forking is straightforward. A side conversation is a quick question attached to an existing thread. A fork is a full copy of the thread that becomes its own independent workspace. Use side conversations for "quick, what about...?" questions and forks for "let me try a completely different approach."

Agent Plugins: extend Codex with third-party tools

The other major addition in v0.146.0 is Agent Plugins support. Codex can now load plugin manifests — configuration files that describe tools, resources, and capabilities a plugin provides. Once a plugin is installed, the agent can use its tools alongside the built-in ones.

The release adds support for workspace plugin publishing, which means a team can create a plugin and distribute it to every developer on the team through a shared workspace. Additional plugin marketplaces for Amazon Bedrock and Claude Code are also supported, so you are not limited to a single source for plugins.

For someone new to coding agents, a plugin is like an app for your agent. Just as you install a browser extension to add functionality to Chrome, you install a Codex plugin to give your agent new capabilities — access to a deployment service, integration with a project management tool, or specialized code analysis features.

Codex also now discovers executor-provided skills. If the underlying code executor has additional capabilities, Codex automatically detects them and makes them available to the agent. This means plugins do not always require explicit configuration — some just work once they are installed.

Remote Code Mode over WebSocket

A quieter but important change: Codex can now connect its app server to remote Code Mode hosts over WebSocket. If you run a remote execution environment — a dev server, a cloud VM, or a containerized workspace — Codex can send commands to it and receive results without requiring a local installation.

This matters for teams that use remote development environments. Instead of running the full agent locally and having it execute code remotely through SSH, the agent communicates directly with the remote host. It is faster and more reliable.

Web search for custom providers

Codex v0.146.0 also adds standalone web search support for compatible custom model providers. If you are running Codex with a non-OpenAI model through a compatible provider, the agent can now search the web for up-to-date information without relying on the default provider's web search implementation.

This is relevant for teams that use open-source models or self-hosted inference. Before this change, web search only worked with OpenAI's default providers.

Bug fixes and quality improvements

The release includes significant stability work. Proxy settings are now honored consistently across authentication, plugin downloads, MCP authorization, remote execution, WebSockets, redirects, and LM Studio connections. Previously, some of these paths ignored proxy configuration entirely, which broke workflows for users behind corporate firewalls.

MCP connections are now kept current when authentication or configuration changes. If you update your API key or change a server configuration, Codex reconnects the affected servers without restarting the ones that are still healthy.

Terminal rendering improved across the board. Nonblocking interrupts mean you can press Ctrl+C without the UI freezing. Narrow layouts render correctly. Keyboard handling on Windows is more reliable, including navigation keys that were previously broken. Sandboxed process trees are now terminated reliably on all platforms.

The skill catalog retention improved too. When context gets tight, Codex now preserves more available skills and warns you when it has to truncate the list instead of silently dropping them.

How to update

Run your normal Codex update command. If you installed Codex through npm:

npm update -g @openai/codex

If you installed through a different method, check the Codex GitHub releases page for v0.146.0. The alpha track already has v0.147.0-alpha.1 if you want to preview what is coming next, but for production use, stick with v0.146.0.

What this means for coding agent users

This release moves Codex closer to being a full development environment rather than a terminal tool. Named sessions, pinned threads, side conversations, and forking are features you expect from an IDE, not a command-line agent. Adding Agent Plugins turns Codex into a platform rather than a standalone tool.

For beginners, the most immediately useful change is named sessions. Give each task a name, pin the ones you are actively working on, and you will never lose track of what is happening in which terminal window again. The rest — plugins, remote Code Mode, web search for custom providers — becomes relevant as your workflow gets more complex.

Claude Code Now Runs Code Reviews in the Background and Gets Opus 5

TerminalBlog — Thu, 30 Jul 2026 04:32:53 +0000

Originally published at terminalblog.com

Claude Code now runs /code-review as a background subagent so your main conversation stays clear, and the newest Opus model — Claude Opus 5 with a 1-million-token context window — is available as a first-class pick in the model selector. These two changes arrived across Claude Code v2.1.218 (July 22) and v2.1.219 (July 24), and they fix two of the most common complaints people have with long coding sessions: a cluttered conversation and a context limit that runs out mid-task.

If you have ever asked Claude Code to review a pull request and then watched your entire conversation fill up with diff comments while you were still trying to work, the background review change is the one that matters most day to day. If you work on large codebases where 200,000 tokens of context is not enough, the Opus 5 addition is the headline.

What changed in v2.1.218: code review runs in the background

Before this update, running /code-review in Claude Code would execute the review inline — every file read, every diff comment, every summary paragraph would appear directly in your conversation. On a large pull request, that could mean hundreds of tokens of review output stacked on top of your working context. If you were in the middle of a multi-step task, the review output would push your earlier messages out of the context window, and you would lose track of where you left off.

The fix is straightforward: /code-review now spawns a background subagent. The subagent reads the diff, performs the review, and writes its findings to a separate output — your main conversation stays untouched. You get the review results when they are ready, but your working context, your current task, and your conversation history remain intact.

For beginners, this works like delegating a task to a colleague. You say "review this code," the agent goes and does it while you keep working on something else, and when the review is done you see the results without your own workspace getting cluttered. The technical mechanism is a subagent — a separate instance of Claude that runs independently with its own context window, so the review's token usage does not compete with yours.

This also means stacked slash commands continue to work as expected. If you run /code-review /review-security, both commands target the review output, not your main conversation. Before this change, the review output could interfere with stacked command routing because everything shared the same context.

What changed in v2.1.219: Claude Opus 5 joins the model picker

Claude Code v2.1.219 adds claude-opus-5 as a selectable model. This is Anthropic's latest Opus-tier model, and the key numbers are:

1-million-token context window — more than four times the previous Opus limit. For codebases with tens of thousands of files, this means the agent can hold your entire project structure in context without compressing or summarizing.
Fast mode at $10/$50 per million tokens (input/output) — the same pricing tier as the previous Opus model, so switching does not increase your per-token cost.
Default Opus model — when you select "Opus" in the model picker, you now get Opus 5. The old model row has been renamed to show its context limit so you can tell them apart.

The model picker now shows "Opus (1M context)" for the new model, fixing a display issue where the merged row just said "Opus" and users could not tell which model they were getting. This matters because Opus 5 and the previous Opus have different strengths — Opus 5's larger context makes it better for multi-file refactors and full-project analysis, while the older model may still be preferable for narrow, high-precision tasks where the extra context is not needed.

How to select Opus 5

If you are using Claude Code in the terminal, run /model and select claude-opus-5 from the list. If you prefer a one-turn override, use /model --once claude-opus-5 — this switches to Opus 5 for the next message only and then reverts to your default model. This is useful when you need the large context for a single analysis task but want to stay on a cheaper model for everyday coding.

In the SDK or headless mode, pass the model identifier directly in your configuration. The model string is claude-opus-5.

Other notable changes in v2.1.219

The Opus 5 addition gets the headlines, but v2.1.219 includes several smaller features that affect day-to-day use:

Sandbox network strict allowlist. A new setting, sandbox.network.strictAllowlist, lets you lock down which network hosts a sandboxed Claude Code session can reach. When enabled, any connection to a host not on the allowlist is denied without prompting. This is useful for teams that want to ensure agents only talk to approved APIs and package registries.

DirectoryAdded hook. When you run /add-dir mid-session or call register_repo_root from the SDK, a new DirectoryAdded hook fires. This lets you write custom logic that triggers whenever a new working directory is registered — for example, automatically scanning the new directory for configuration files or updating a project manifest.

MCP server error reporting. The mcp_server_errors field now appears in the headless stream-json init event, listing any MCP config entries that were skipped during validation. In terminal mode, a startup warning is printed. This makes it much easier to diagnose why an MCP server is not loading instead of silently missing tools.

Nested subagent forwarding. When --forward-subagent-text is set, subagents spawned at depth 2 or deeper now appear in the stream-json output, keyed by their spawning agent's tool-use ID. This is relevant if you are building tooling on top of Claude Code's output streams and need visibility into nested agent calls.

Other notable changes in v2.1.218

The background code review is the main feature, but v2.1.218 also shipped:

Screen-reader mode improvements. The screen reader now echoes only the typed character instead of rewriting the entire input line on every keystroke. This fixes a real accessibility issue where screen readers would announce the full prompt content on each keypress, making the tool unusable for developers who rely on assistive technology.

Dynamic workflow size default. Dynamic workflows now default to a "medium" size guideline, targeting fewer than 15 agents. You can adjust this through /config or the workflowSizeGuideline setting. This prevents runaway agent spawning on large tasks where the default "unrestricted" mode could create dozens of parallel agents and exhaust your API budget.

Vim mode fix. Pressing the left arrow on an empty prompt now returns from NORMAL mode to the agent view, matching expected Vim behavior. Previously, you had to switch to INSERT mode first, which was a small but annoying friction point for Vim users.

Why these changes matter for beginners

If you are new to coding agents, two things stand out from this release cycle.

First, the background code review pattern is worth understanding because it applies beyond Claude Code. Any coding agent that performs long-running tasks — full-project analysis, test generation, security audits — benefits from running those tasks in subagents that do not pollute the main conversation. When you evaluate tools, look for this pattern: can long tasks run in the background while you keep working?

Second, the 1-million-token context window on Opus 5 changes what is possible. Before this, coding agents hit context limits on large projects and had to rely on compression, summarization, or smart file selection to fit relevant code into the window. With 1 million tokens, the agent can hold most mid-sized codebases in context at once, which means fewer mistakes from missing context and less time spent re-explaining the project structure.

The tradeoff is cost. At $10 per million input tokens, a full 1-million-token context window costs $10 per request. For a typical coding session that uses 200,000 input tokens, you pay $2 — the same as before. But if you are loading an entire project into context, the cost scales with the project size. For most individual developers, this stays well under $5 per session. For teams running automated workflows, the cost math changes.

How to update

If you have Claude Code installed via npm, run:

npm install -g @anthropic-ai/claude-code@latest

For other installation methods, check the Claude Code documentation for platform-specific instructions.

After updating, run claude --version to confirm you are on v2.1.219 or later. Then run /model to see claude-opus-5 in the model list.

What this means for the Claude Code roadmap

These two releases show a clear direction: Claude Code is moving toward treating the terminal session as a persistent workspace rather than a one-shot chat. Background subagents, directory hooks, and a 1-million-token context window all point toward longer, more complex workflows where the agent maintains state across many turns without losing context.

The next area to watch is how the background subagent pattern extends to other long-running tasks. Code review was the first use case, but test generation, security scanning, and documentation writing are all candidates for background execution. If Claude Code applies this pattern broadly, it changes the economics of agent-assisted development — you stop paying the "context tax" of long-running tasks and can instead work on multiple things at once.

Copilot CLI Now Manages Multiple Sessions and Lets You Queue Messages

TerminalBlog — Thu, 30 Jul 2026 04:32:44 +0000

Originally published at terminalblog.com

GitHub Copilot CLI v1.0.76, released July 30, adds a Sessions sidebar for managing multiple concurrent coding sessions, a queue manager that lets you reorder and edit messages before they are sent, and Grok 4.5 as a new model option. These three features address one of the longest-standing complaints about terminal coding agents: the single-session bottleneck that forces you to either finish one task before starting another or juggle multiple terminal windows with no shared visibility.

If you have ever been mid-way through refactoring an API endpoint in one Copilot session and needed to quickly fix a bug in another file without losing your place, the Sessions sidebar is the feature that makes this possible. If you have ever queued a message and then realized you wanted to change its order or edit the prompt before sending, the queue manager removes the frustration of watching the wrong message go first.

Sessions sidebar: multiple coding sessions in one window

The biggest change in v1.0.76 is the Sessions sidebar, which lives on the left side of the terminal and shows all your active Copilot sessions at a glance. You can switch between sessions, spawn new ones, and see which session is doing what without leaving the current one.

To turn it on, run /experimental on in any Copilot CLI session. The sidebar appears as a collapsible panel. Each session card shows the session name, its current status (running, waiting, idle), and which model it is using. Click or use keyboard navigation to switch between sessions. The active session card is accented by default to make it obvious which one you are working in.

For beginners, think of this like browser tabs for your coding agent. Before this feature, each Copilot CLI session was isolated in its own terminal window. If you wanted to work on two tasks simultaneously, you needed two separate terminal windows, and switching between them meant losing visual context on what the other one was doing. The Sessions sidebar keeps everything in one place, showing you the status of each session so you can pick up where you left off.

What happens to your mode when you switch

A small but important detail: when you switch away from a session and come back, Copilot now restores the mode you were in. If you were running in autopilot mode — where the agent completes tasks autonomously — and you switched to another session, coming back resumes autopilot instead of dropping you into interactive mode. This means the task_complete tool stays available, and you do not have to re-enable autopilot every time you switch sessions.

Before this fix, resuming a session always reverted to interactive mode, which meant autopilot sessions would lose their autonomous behavior the moment you looked at another task. For anyone using autopilot for longer-running work, this was a silent productivity killer.

Queue manager: control the order and content of queued messages

The second major feature is a queue manager accessible through the /queue command. When you send a message while Copilot is busy processing another one, the message gets queued. Before v1.0.76, queued messages were fire-and-forget — you could not change their order, edit their content, or remove them without canceling the entire queue.

The queue manager gives you full control:

Reorder queued messages by moving them up or down in the list
Edit the prompt text of any queued message before it is sent
Remove individual messages from the queue
Repeat a message by re-queuing it after it has been sent
Send immediately by selecting a queued message and skipping ahead in the queue

This matters because the order of prompts affects how the agent works. If you queued "run the test suite" before "fix the failing test," the agent would try to run tests before understanding what was wrong. With the queue manager, you can swap the order so the agent investigates first and runs tests second.

You can also remove your own newest queued message with Ctrl+C, which is useful when you realize you sent a prompt with a typo or an incomplete instruction.

A small quality-of-life fix: the queued messages list no longer shows blank rows or inflated counts, so what you see in the queue is exactly what is there.

Grok 4.5 model support

Copilot CLI v1.0.76 adds Grok 4.5 to the model picker. This is the latest model from xAI and is available alongside the existing Claude, GPT, and Gemini options. If you want to try Grok for coding tasks, select it from the model picker or use the /model command to switch.

The addition of Grok 4.5 follows the broader trend of terminal coding agents becoming model-agnostic — you are no longer locked into a single provider's models and can pick the one that works best for your specific task.

Plugin and hook controls in /plugins

The /plugins command now includes enable and disable controls for every type of extension: plugins, instructions, agents, LSP servers, and hooks. Before this change, disabling a plugin or hook required editing configuration files manually. Now you can toggle each extension on or off from within the CLI.

This is particularly useful when you are debugging an issue caused by a misbehaving plugin or hook. Instead of removing the extension entirely (and losing your configuration), you can disable it, test whether the problem goes away, and re-enable it once you have identified the cause.

Enterprise sandbox floor

For teams using Copilot CLI in corporate environments, v1.0.76 adds a sandbox floor that enterprise administrators can enforce through managed settings. The sandbox floor tightens the user's sandbox policy — it can make restrictions more restrictive, but it cannot loosen them. This means an administrator can require that all sessions run with network restrictions or filesystem limitations, and individual users cannot override those restrictions.

The /sandbox dialog now shows which settings are managed by your organization with locked fields and a clear indication of what is enforced. This makes it possible for administrators to confirm that the sandbox policy is correctly applied without having to inspect configuration files.

Other practical improvements

Several smaller changes in v1.0.76 affect daily use:

Unsent prompts stay with their session. If you typed a message but had not sent it when you switched sessions, the unsent text now stays with the session you typed it for. Before this fix, the text would follow you to the new session, which was confusing when you switched sessions to do something completely different.

web_fetch follows redirects. The web_fetch tool now handles HTTP redirects instead of failing. When a redirect points to a different origin, Copilot asks for permission and shows you where the redirect came from, so you know exactly what URL is being accessed.

Faster diff scrolling. The /diff command now scrolls and syntax-highlights large multi-file diffs faster, reducing the lag when reviewing changes across many files.

Subagent delegation improvements. Small tasks and parallel work are delegated to subagents more efficiently, which means the main session stays responsive while the agent handles background work.

Autopilot persistence after task completion. Autopilot mode now stays selected after task_complete by default, so the agent continues working on the next task without dropping back to interactive mode. If you prefer the old behavior, set stayInAutopilot to false in your configuration.

Scheduled prompt count in footer. The status footer now shows the number of active scheduled prompts, so you can see at a glance how many timed tasks are queued without checking each one individually.

Voice mode media handling. When using voice mode on macOS or Windows, Copilot now pauses any playing media before recording your voice input and resumes it afterward, so your music or podcast does not get picked up by the microphone.

How to update

If you already have Copilot CLI installed, the update is automatic — Copilot downloads new versions in the background and prompts you to restart. You can also check your current version by running copilot --version in your terminal. The Sessions sidebar requires experimental mode, which you enable with /experimental on.

For new installations, follow the official setup instructions at github.com/features/copilot. Copilot CLI requires an active GitHub Copilot subscription, which is included with Copilot Individual, Copilot Business, and Copilot Enterprise plans.

What this means for terminal coding agents

The Sessions sidebar is Copilot CLI's answer to a problem every terminal coding agent has faced: how do you manage multiple concurrent tasks without leaving the terminal? Claude Code handles this through subagents that run in the background. Codex added named sessions and thread forking in v0.146.0. Copilot CLI's approach — a visual sidebar that shows all sessions and their status — is the most IDE-like solution in a terminal tool, which makes sense given GitHub's experience building the VS Code sidebar.

The queue manager is a feature that no other major terminal coding agent offers yet. Being able to reorder, edit, and remove queued messages before they are sent gives you finer control over how the agent spends its time, which becomes important when you are batching multiple small tasks in sequence.

Together, these changes move Copilot CLI closer to the multi-session workflow that developers have been requesting since the tool launched. The single-session limitation was one of the most common reasons developers cited for sticking with IDE-based agents like Cursor, even when they preferred the terminal workflow. With the Sessions sidebar, that tradeoff gets smaller.

Who Really Controls Your Coding Agent? — Developers React on Hacker News

TerminalBlog — Wed, 29 Jul 2026 04:51:39 +0000

Originally published at terminalblog.com

A developer found something strange buried in Claude Code's behavior: a hardcoded system instruction telling Opus 5 not to use subagents. Not a bug. Not a configurable setting. A deliberate override baked into the model's instructions, invisible to the user, impossible to change through normal configuration.

The discovery, posted to Hacker News with 27 points and a heated 13-comment discussion, pulled back a curtain that most developers did not know existed. Combined with two other stories from the same week — a tool that lets you run unlimited Claude Code through your Cursor subscription, and an Anthropic blog post about context engineering that developers called a lock-in play — a bigger question surfaced: who actually controls your coding agent?

The subagent restriction nobody asked for

The Hacker News post revealed that Claude Code's system prompt contains a hardcoded instruction preventing Opus 5 from delegating tasks to subagents. This matters because subagents — where the main agent spawns smaller worker agents to handle subtasks in parallel — have become a core pattern for complex coding workflows. Teams use them to keep the main agent's context window clean while offloading research, code review, or file exploration to specialized workers.

The restriction was not documented. Users could not toggle it off through settings. It was just there, silently limiting what the most expensive model in Claude's lineup could do.

Developers in the thread were split into two camps.

The first camp shrugged. One developer wrote that subagents "are not super great to use anymore" because they "go off and do a bunch of duplicate research, then come back and deliver a cheap facsimile of the information the main agent already had." For these developers, the restriction was annoying but not catastrophic. They had already found subagents unreliable enough to avoid them.

The second camp was furious. "I'm honestly so sick of Anthropic nerfing models, messing around with the system prompts, just working against me and others," one developer wrote. Another speculated it might be a product segmentation play — artificially limiting the current model so Anthropic can later "claim gains by removing the restriction on sub-agents."

One developer who had been using Opus 5 extensively pushed back on the premise entirely. They reported that their usual workflow — keeping the main agent as orchestrator while subagents handle execution, review, and bug fixes — worked fine in both medium and high effort modes. Another confirmed that Opus 5 "immediately used 2 subagents on the first task I gave it on Friday."

This contradiction is revealing. Either the restriction is inconsistently enforced, or the discovery in the system prompt is not always activated. Either way, developers do not like being surprised by invisible limits on tools they pay premium prices to use.

Cursor Bridge: developers fight back with hacks

Two days later, a different kind of rebellion showed up on Hacker News: a tool called Cursor Bridge that lets you run Claude Code — Anthropic's terminal agent — using your Cursor subscription's unlimited auto-model instead of paying Anthropic directly.

The pitch is simple. You already pay for Cursor. Claude Code costs extra through the Anthropic API or a separate Pro subscription. Cursor Bridge is a thin shim that routes Claude Code's requests through Cursor's backend instead. One command to install, no daemon, no configuration.

The 20-comment thread revealed developer frustration on multiple levels.

"This is why 'unlimited' subscriptions are going to go away," one developer complained, comparing it to bringing a bucket to a restaurant that offers unlimited refills. "People can't just use what they paid for, they have to drain every bit of value out in every way they can."

But the tool's creator pushed back with a different framing: "You already pay for Cursor. Claude Code costs extra. Cursor's auto model is free and unlimited with your subscription." In their view, they were not gaming a system — they were connecting two things they already owned.

A practical concern surfaced: "What's the fallback when Cursor throttles Auto mid-task? Right now it looks like the answer is nothing, you just eat the failure." Another developer warned that "submitting projects like this to HN is a good way to get them nerfed" — a comment that, ironically, reinforced the thread's underlying tension about who gets to control how developers use their tools.

The most insightful comment came from someone who said "Cursor is probably a better client than Claude Code though." This suggests the real competition is not between AI models but between the interfaces that wrap them — and developers will choose whichever interface gives them the most control.

The lock-in fear in Anthropic's own advice

These two stories landed on the same week as Anthropic published a 447-point Hacker News post titled "The new rules of context engineering for Claude 5 generation models." On the surface, it was practical advice: simplify your prompts, trust the model's judgment more, remove redundant instructions. But developers saw a pattern.

"This all strikes me as an effort to move tailoring the harness out of the easily transferable .md file into specific Anthropic tooling to increase lock-in," one developer wrote. The fear is concrete: if your carefully crafted AGENTS.md or CLAUDE.md file works because of explicit rules, you can port those rules to another model. But if you rely on Anthropic's auto-memory, judgment features, and model-specific behaviors, switching becomes expensive.

"We should design a specific language to make sure that we can encode the exact requirements that we want," another developer wrote, before catching themselves: "Wait a minute..." — a joke about reinventing programming languages to control LLMs.

One developer was blunt: "We want more control, not less. This is the reason I use GPT over Claude. It adheres very closely to your instructions and rules. Claude just does whatever it wants, regardless of what you tell it. It's a miserable experience."

Another expressed concern about liability: "If you deploy code written with assistance from Claude, and then things go wrong, and investigators look into your prompts, this way of working is not going to look good for you from a liability standpoint."

The most pragmatic response came from a developer who simply pointed Claude at its own blog post and asked it to update their CLAUDE.md accordingly. "Worked a charm," they wrote.

What it means for you

Three stories. One thread. Developers are waking up to the fact that model providers are not neutral infrastructure. They make choices — about what features to enable, what prompts to inject, what behaviors to restrict — that directly affect how developers work.

This does not mean Anthropic is acting in bad faith. The subagent restriction might exist because subagents genuinely underperform in current models. The context engineering advice might be genuinely useful. But the pattern of developers discovering restrictions they did not consent to, then building hacks to work around them, then questioning whether "helpful" advice is really a lock-in play — that pattern is worth paying attention to.

If you use coding agents daily, here is what this week's HN discussions actually suggest:

Read your system prompts. The developer who found the subagent restriction found it by reading Claude Code's system prompt. Most developers never do this. If your agent has hidden instructions that override your preferences, you cannot fix what you cannot see.

Build portable configurations. If your workflow depends on model-specific features like auto-memory or judgment-based decision-making, test whether it transfers to another provider. If it does not, you are more locked in than you think.

Distinguish between guidance and control. Anthropic's context engineering advice is useful. But when the same company that sells the model tells you to rely more on its model-specific features and less on portable configuration files, ask yourself who benefits.

Accept that the ecosystem is messy. Developers will keep hacking around restrictions. Providers will keep adding them. The tools will keep changing. The developers who thrive are not the ones who pick the "right" model — they are the ones who stay in control of their own workflow regardless of which model they use.

The real question was never "which coding agent is best." It is "who decides how your coding agent behaves — you, or the company that built it?" This week on Hacker News, the answer was not as clear as anyone would like.

Hermes Agent Now Starts 80% Faster with Password Manager Integration and Smart Approvals

TerminalBlog — Wed, 29 Jul 2026 04:50:49 +0000

Originally published at terminalblog.com

Hermes Agent v0.19.0 shipped on July 20, 2026 with over 2,200 commits and 3,300 closed issues since the last major release. The headline: first-token startup time dropped roughly 80 percent across CLI, gateway, TUI, desktop, and cron. But speed is only the spine — the release also adds Bitwarden and 1Password secret sources, smart approval defaults, live subagent transcripts, a delivery-obligation ledger that prevents lost responses, and a desktop app that feels like a native application under load.

If you have been waiting for Hermes to feel fast and safe enough for daily use, this is the release that gets it there.

Why the speed jump matters

Before v0.19.0, cold-starting Hermes took about 4.3 seconds before your first message even reached the model. Discord capability detection, Ollama probes, and agent-init blocking all sat on the critical path. Now those are cached, deferred, or removed entirely. Cold submit-to-dispatch sits at roughly 0.9 seconds — an 80 percent cut that you feel on every platform.

The second speed win is perceptual. Reasoning models now stream their thinking live by default instead of showing a spinner for 30 seconds. The response box paints per token instead of per line, and prompt-build caching means repeated turns hit a warm cache. For beginners, the practical effect is simple: Hermes no longer takes a deep breath before answering.

Password manager integration: no more plaintext API keys

If you have been storing API keys in a plaintext .env file, you are not alone — but it is a security risk. Hermes v0.19.0 introduces a pluggable SecretSource interface that fetches secrets from Bitwarden and 1Password at load time.

Here is what that looks like in practice:

You reference a Bitwarden or 1Password item in your Hermes config (using op:// syntax for 1Password, for example).
At startup, Hermes fetches the actual secret values from your vault.
Multiple vaults can be enabled simultaneously with deterministic precedence and per-variable provenance tracking.
Future vault providers drop in as plugins, so if you use a different password manager, support may come later.

The result: API keys stay encrypted in your vault instead of sitting in a file that any tool on your machine can read. This alone is worth the update if you care about security.

Smart approvals reduce the permission pop-ups

By default, Hermes now runs an independent LLM reviewer when it wants to execute a flagged command. Instead of asking you to approve every single dangerous-looking action, the reviewer assesses each command individually and decides whether it is safe enough to run.

This works alongside two new features:

User-defined deny rules — You can set rules that block certain commands even when Hermes is in "yolo" (auto-approve) mode. Think of these as hard stops that cannot be overridden.
/deny <reason> — When you refuse a command, you can tell Hermes why. The agent uses that feedback to adjust its approach instead of retrying the same thing.

For beginners, the net effect is fewer interruptions. You approve the genuinely risky stuff and let the tool handle routine operations on its own.

Desktop app: 14x faster markdown rendering

The desktop app received over 20 performance pull requests in this release. The biggest wins:

Incremental block lexing for streaming markdown cuts the markdown splitter's CPU usage by 14x on long replies.
Virtualized diffs in the review pane mean giant code diffs no longer freeze the screen.
Session switching no longer thrashes the layout, even with huge transcripts.
Sidebar and tool-row rendering is batched instead of re-rendered per token during streaming.

If you have been using the Hermes desktop app and it felt sluggish with long conversations or busy agents, this update fixes that. Under load, it now feels like a native application.

Subscription management from the terminal

Changing your Nous subscription used to require opening a browser. Now you can run /subscription directly in the TUI or CLI to:

See your current plan and remaining usage allowance.
Preview upgrade costs ("Pay $46.30 and upgrade now") or schedule downgrades.
Apply changes immediately with scheduled-change banners and undo support.

The desktop app has a matching billing settings tab. Your wallet stays at the keyboard.

Live subagent transcripts

When Hermes delegates a task to a subagent, the dispatch now returns a live transcript file you can watch with tail -f. Every tool call, result, and streamed reply logs to one human-readable file per child agent.

Background delegation completions are also durable now. If the process restarts mid-run, results are restored through an ownership-checked ledger instead of vanishing. You can fan out a fleet of subagents, watch any worker live, and never lose results to a crash.

Delivery ledger: responses survive gateway crashes

Before this release, if the gateway died between generating a response and confirming delivery, that answer was silently lost. You paid for the turn but never got the output. This affected Telegram, Discord, Slack, and every other channel.

v0.19.0 records final responses in a durable ledger in state.db around the platform send and redelivers them on the next boot. A finished answer can no longer be lost.

Profile-based routing: one gateway, many configs

A single multiplexed gateway sharing one bot token can now route specific servers, channels, or threads to different Hermes profiles. Each profile has fully isolated config, skills, memory, and secrets.

For example, point your work Discord server at a work profile and your personal server at a personal profile — from one bot instance. One misconfigured profile can no longer bring down the whole gateway.

New providers and frontier models

The release adds Fireworks AI and DeepInfra as first-class providers, plus Upstage Solar. Model catalogs now include GPT-5.6 variants (Sol, Terra, Luna, and Pro), grok-4.5, kimi-k3, claude-fable-5, claude-sonnet-5, and tencent/hy3. LM Studio gets JIT model loading for local setups.

Reasoning effort gained max and ultra levels with per-model and per-slot control, so you can set your advisors to think hard while keeping your synthesizer fast.

Session export for data portability

hermes sessions export now writes Markdown, HTML, prompt-only, and Hugging Face-ready trace formats. You can filter by age, workspace, and platform, opt in to secret-scrubbing with --redact, and stitch compacted-session lineage into one logical export. Your conversation history becomes a real dataset.

How to update

hermes update        # existing installs
pip install -U hermes-agent

The bottom line

Hermes Agent v0.19.0 is the release where speed, security, and reliability stop being aspirational and start being defaults. The 80 percent faster startup means less waiting. Password manager integration means API keys stay encrypted. Smart approvals mean fewer interruptions. The delivery ledger means responses do not disappear. And the desktop app finally keeps up with long sessions. If you have been on the fence about Hermes as a daily driver, this is the version to try.

Cline Now Has Free Coding Models and a Desktop System Tray

TerminalBlog — Wed, 29 Jul 2026 04:50:42 +0000

Originally published at terminalblog.com

Cline now lets you use coding models for free. Desktop v0.0.7, released July 29, adds a "free" tier to the model picker — models labeled "(free)" cost nothing, and when you hit the usage limit the app shows a clear error card with the exact time the limit resets. The same feature landed in the SDK (v0.0.66) and the CLI extension (v4.0.12) on July 28, so every Cline surface now supports free models.

If you have been holding off on coding agents because API credits cost money, this is the release that removes that barrier.

Free Cline models: how they work

When you open the model picker in Cline Desktop, the extension, or the CLI, you now see certain models marked with a "(free)" label. These are Cline-provided models that do not require an API key or any payment. You select one, start coding, and the agent works exactly as it would with a paid model.

The free tier has usage limits. When you reach one, instead of crashing or producing a confusing error, Cline shows a dedicated error card that tells you two things: that you hit the free-tier limit, and when the limit resets so you can try again. This is a much better experience than the vague "rate limit exceeded" messages that some other tools display.

For beginners, this means you can try Cline without setting up any API keys, configuring billing, or worrying about surprise costs. Pick a free model, ask the agent to do something, and see how it works. If you later decide you want faster inference or access to more capable models, you can switch to a paid provider at any time.

The free models are available across all three Cline surfaces: the macOS desktop app, the VS Code extension, and the command-line interface.

System tray icon and session management

Desktop v0.0.7 adds a system tray icon that shows the app's current status and how many agent sessions are running. On macOS, this means you can glance at your menu bar and see whether Cline is active without switching to the app window. If you run multiple agent sessions in parallel — one refactoring a module while another writes tests — the tray icon counts them all.

Session history is now paginated. Instead of loading every session you have ever had at once, the app shows ten sessions at a time and loads older ones as you scroll to the bottom. This sounds like a minor performance fix, but it matters when you have been using Cline for weeks and have hundreds of sessions. Before this change, scrolling through long lists could lag. Now it stays responsive.

You can also mark sessions as favorites. Favorite sessions appear at the top of the list regardless of when they were last active, so your most important conversations are always one click away. Sessions are also now ordered by most recent activity rather than creation time, which matches how most people think about their work — the session you were just using should be at the top.

Subagent and teammate run visibility

If you use Cline's multi-agent features — where the main agent delegates tasks to subagents or teammates — you can now see those runs directly in the desktop app. Each subagent or teammate run shows its status (running, completed, failed) and its results. Before this change, subagent work happened invisibly in the background and you had no way to monitor progress without checking logs.

This is particularly useful when the main agent spawns a subagent to handle a large task like "run the full test suite and fix any failures." Instead of waiting and wondering, you can see the subagent's progress in real time.

Chat interface improvements

The desktop app's chat interface received several polish updates:

Tool-specific icons. Each tool call now shows an icon matching the tool type — file edits, terminal commands, and web searches each get a distinct visual. This makes it easier to scan a long conversation and find the moment where the agent made a specific change.
Elapsed thinking time. When the agent is reasoning about a task, the thinking section now shows how long it took. This helps you understand whether the agent is genuinely working on a complex problem or stuck in a loop.
Restyled reasoning sections. The visual presentation of the agent's reasoning has been cleaned up, with better spacing and clearer distinction between thinking and output.
Stable message layout. Message actions (like copy, retry, or edit) no longer shift the conversation layout while you are scrolling. The viewport stays anchored to where you are reading.

These changes add up. The desktop app went from feeling like an early-stage tool to something you could use as your primary coding interface.

Agentic compaction becomes the default

The Cline SDK (v0.0.66) makes agentic compaction the default context-compaction strategy. Context compaction is how Cline manages the conversation when it gets too long for the model's context window. Before this change, the default was basic compaction — a simple truncation that could lose important context. Agentic compaction is smarter: it uses a language model to summarize the conversation while preserving the key decisions, file references, and constraints that matter for ongoing work.

Two bugs were fixed in the compaction system:

OpenAI Compatible provider fallback. Agentic compaction was silently falling back to basic compaction on OpenAI-compatible providers because the summarizer tried to call api.openai.com instead of the configured provider endpoint. This is fixed — the summarizer now uses the correct base URL.
Tool-heavy transcript cut points. Agentic compaction previously could not find a good cut point in transcripts with many tool calls, causing it to skip compaction entirely and let context grow until it hit the model's limit. Now the compaction logic treats assistant messages as valid cut boundaries, so it can always find a place to compact.

Both fixes prevent situations where context grows uncontrolled and the agent starts producing worse outputs because it is working with a truncated or confused view of the conversation.

Provider catalog refresh

The built-in provider and model list is now generated from models.dev, a community-maintained directory of AI model providers. This means Cline's out-of-the-box provider coverage automatically includes new providers and models without waiting for a Cline release. If a new provider appears in the directory, it shows up in your model picker on the next update.

The SDK v0.0.66 also adds support for SAP AI Core as a provider and fixes a file-editing issue where CRLF line endings were being corrupted to mixed endings, which broke exact-match edit operations on Windows-originated files.

Bug fixes for regional users

Desktop v0.0.7 fixes an issue where the China/international endpoint toggles for Qwen, Moonshot, Z AI, and MiniMax were being silently ignored. Users in China or outside China were being routed to the wrong API endpoint, causing connection failures or slow responses. The toggles now work as expected, routing to the correct regional endpoint.

A separate fix addresses tool calls that failed when a model returned a line number as a string (for example, "insert_line": "3" instead of "insert_line": 3). The agent would fail, waste a round trip retrying, and sometimes produce an incorrect edit. This is a common case with smaller models that do not always produce perfectly typed responses.

Connector session persistence

Connector sessions — the persistent connections between Cline and external services like MCP servers — now survive daemon or hub restarts. Before this fix, restarting the Cline daemon or the hub process would disconnect all connectors and require manual reconnection. Now sessions persist across restarts and reconnect automatically.

This is especially important for teams using Cline in CI/CD pipelines or automated workflows where the daemon might restart between runs.

How to update

If you are using Cline Desktop, the app checks for updates on launch and every two hours in the background. It will download v0.0.7 and prompt you to restart. If you are using the VS Code extension, run the update from the Extensions panel or wait for the auto-update. For the CLI, update with your package manager.

The free models are available immediately after updating — no configuration changes needed. Open the model picker and look for models labeled "(free)."

Should you switch to the free tier?

If you are evaluating coding agents and want to try Cline without commitment, the free models are the obvious starting point. They give you a no-cost way to understand how Cline works, what its agent loop feels like, and whether the desktop app fits your workflow.

If you are already a paying user, the free tier is useful as a fallback. When you hit rate limits on your paid provider, switching to a free model keeps you working instead of waiting.

The free models are unlikely to match the speed or capability of premium options like Claude Opus 5 or GPT-4o for complex multi-file refactors. But for reading code, answering questions, writing tests, and making small edits, they are more than enough — and the price is hard to beat.

DEV Community: TerminalBlog

What developers actually say about Claude Code vs Cursor

Quick verdict from the community pattern

What people praise about Cursor

What people praise about Claude Code

When to choose which path (community-informed)

Choose Cursor-first when

Choose Claude Code-first when

Choose hybrid when

Failure modes the community actually reports

How to convert anecdotes into a team decision

Quotes you can use in an RFC (paraphrased patterns)

Related reading on this site

Bottom line

Related articles

- Coding agents vs GitHub Copilot: autocomplete is not an agent

Operator close: what devs say claude code vs cursor

Measurement notes for what-devs-say-claude-code-vs-cursor

Coding agent features in 2026: who actually has cron, subagents, and multi-provider routing

Quick verdict

Feature matrix (operator-relevant)

How to read “Yes” without getting burned

When to choose which path

Choose a capability-first shortlist when

Choose a specific pair page when

Choose to wait or stay on autocomplete when

Capability-first shortlists

If you need unattended automation

If you need deep multi-file refactors in a polished terminal

If you need provider neutrality

If you need IDE speed

Job-to-capability mapping

How to keep this matrix honest over time

Related pair deep-dives

Evaluation protocol (one afternoon)

Bottom line

Related articles

- Coding agents vs GitHub Copilot: autocomplete is not an agent

Orchestration Topology Is the New Bottleneck in Agentic Coding

Related articles

The convergence problem

What is orchestration topology?

The git worktree revolution (yes, from 2015)

The conductor pattern

The real bottleneck is decomposition, not execution

Self-evolving agents: the next frontier

Source-level rewriting (MOSS)

Skill crystallization (GenericAgent)

Trace-based self-evolution (Socratic-SWE)

What this means for developers

For solo developers

For teams

For the industry

The tools to watch

The bigger picture

Cursor Router Automatically Picks the Best Model for Every Coding Task

Related articles

How Cursor Router works

Three optimization modes

What the cost data looks like

Admin controls for teams

How this compares to other coding agents

What is next

Claude Code Gets Opus 5 as the Default — What the 1M-Context Model Changes for You

Related articles

What is Claude Opus 5?

What changed in Claude Code v2.1.219

1. Opus 5 is now the default

2. Thinking is on by default

3. Nested subagents go three levels deep

4. Dynamic workflow size guidelines

5. Sandbox network allowlist

6. DirectoryAdded hook

Gotchas for beginners

How to update

What this means for coding agent users

Codex 0.146.0 Explained: Session Management, Agent Plugins, and Thread Forking for Beginners

Named Sessions: Stop Losing Important Threads

Why This Matters

Thread Forking: Branch Conversations Like Git Branches