TerminalBlog

Posted on Jul 31 • Originally published at terminalblog.com

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

#comparison #guide #pillar #features

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.*

DEV Community