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

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.

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:

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:

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

Evaluation protocol (one afternoon)

1. Pick three production-like tasks (one migration, one CI failure, one small feature).
2. Shortlist two tools that cover the must-have rows.
3. Run both tools on the same tasks with the same model budget where possible.
4. Score: time-to-mergeable draft, review debt, secret/tool incidents, cost.
5. 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.

FAQ

Q1: Which coding agents support cron and background jobs in 2026?

Hermes and pi.dev are the clear leaders for cron/scheduling and background tasks. Most other CLIs treat background work as a secondary feature or don’t support it. If unattended fleets are your requirement, shortlist Hermes and pi.dev and re-verify their scheduling against current release notes before a company rollout.

Q2: What is multi-provider routing and why does it matter?

Multi-provider routing lets an agent switch between models (Claude, GPT, Gemini, local) rather than being locked to one vendor. It matters for two reasons: you survive a single provider’s outage or price hike, and you control cost by routing cheap models to drafts and strong models to merge-ready work. Hermes, OpenCode, Goose, and many OSS CLIs support it.

Q3: What’s the difference between subagents and plugins?

Subagents are parallel worker processes your agent spawns to split a large task; plugins/skills are reusable instructions and tooling. Both matter but solve different problems: subagents fan out work, plugins define how the agent handles your team’s conventions. Teams should decide which they need before comparing brands.

Q4: Does the coding agent leaderboard decide which agent I should use?

No. The leaderboard (stars, commits, package downloads) is useful context about adoption, but it does not prove fitness for your monorepo. Pick by the job first and the missing capability column second, then validate with the evaluation protocol above on real production-like tasks.

Q5: How often should I re-evaluate my coding agent stack?

Quarterly at minimum. Agent harnesses ship faster than most internal standards — cron, subagents, multi-provider routing, and local-first are the rows that change architecture, and every major release can shift them. Re-check the rows that block your workflow, not the full matrix.

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.

See also: pricing guide, open source vs commercial, leaderboard.

Related articles

• Open source vs commercial coding agents: operator fit, not ideology
• Claude Code vs Mimo Code: open source vs commercial tradeoffs
• Coding agents vs GitHub Copilot: autocomplete is not an agent

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