Comparison
How to evaluate Apothem against hand-maintained harness config and other configuration approaches, with a feature matrix and per-harness pages.
Apothem is a host-agnostic AI-harness configuration manager. One shared
profile at ~/.config/apothem/profile.yaml materializes into seventeen
harness-native config surfaces. This section frames how to evaluate Apothem
against the alternatives you already use.
How Apothem compares
Peer facts on this page are as of 2026-10-02, read from each project's own README or documentation (see Sources); recheck them at each minor release.
Other tools solve adjacent slices of this problem. File-based config managers
like chezmoi and GNU Stow place, link or template files but never
translate one source into each harness's native configuration schema.
Cross-tool sync CLIs generate per-tool files from one source: rulesync
generates native configuration for 60 coding tools and two open standards,
across a synced unit that adds MCP, ignore files, permissions and review checks,
none of which the Apothem manifest syncs; Apothem renders its MCP servers from
the profile through the materializers of the adapters that author them.
ruler distributes one .ruler/ directory to 33 targets, concatenating rules
into each tool's instruction file and translating MCP servers, skills and
subagents into native config. Apothem's distinction is the governance and
lifecycle discipline shipped around the sync: a mechanized conformity gate,
deterministic pipelines, an audit fortress, and a reversible verified lifecycle.
| Capability | Apothem | File config managers (chezmoi, Stow) | rulesync | ruler |
|---|---|---|---|---|
| One source to many tools' native schemas | Yes — seventeen harness adapters | No — copy, symlink or template, no translation | Yes — 60 tools plus the AGENTS.md and Agent Skills standards | Partly — rules concatenated into each tool's instruction file; MCP, skills and subagents written in native form |
| Synced unit | rules, skills, subagents, slash-commands, hooks, output-styles, statuslines, templates, conformity validators, schemas, per-harness instruction templates, and the Claude Code settings template | arbitrary files | rules, ignore, MCP, commands, subagents, skills, hooks, permissions, checks (code-review check instructions) | rules, MCP, skills, subagents |
| Governance corpus (behavioral rules plus a mechanical conformity gate) | Yes — python -m apothem.conformity.gate | No | No — its checks feature syncs code-review checks to tools; no conformity gate over the rules | No |
| Deterministic plan and research pipelines | Yes — /plan-spec to /plan-execute, thirteen-stage /research | No | No | No |
| Audit fortress that detects and remediates | Yes — eleven-command sweep, /fortress re-audit loop | No | No | No |
| Durable memory across sessions | Yes — memory/records.json store under the Apothem data home, created at install | Not compared | Not stated in its README | Not stated in its README |
| Supply-chain hardened releases | Yes — SBOM, Sigstore, SLSA, Scorecard target | Not compared | Not stated in its README | Not stated in its README |
| Reversible, verified lifecycle | Yes — backup, apothem verify --json, zero-orphan uninstall | chezmoi: chezmoi verify checks every target; Stow: symlinks only | Not stated in its README | .bak backups and ruler revert; no verify command in its README |
Where a peer is stronger, it is named: rulesync reaches more than three times as many tools and syncs MCP, ignore files, permissions and review checks, which the Apothem manifest does not, and ruler reaches nearly twice as many tools with a revert command of its own. Apothem trades raw tool count for the governance, audit, and lifecycle discipline shipped around the sync — a conformity gate, deterministic plan and research pipelines, an eleven-command audit fortress, durable memory, and a reversible verified lifecycle — that neither sync tool carries.
Sources
All retrieved 2026-10-02, against each project's latest release on that date. The rulesync and ruler READMEs were read again on 2026-10-15 for the durable-memory row; neither mentions a memory feature.
- rulesync (npm
rulesync): README (supported-tools table: 60 coding tools and two open standards) and file formats reference (thechecksfeature). - ruler (npm
@intellectronica/ruler): README (supported-agents table,--backup,revert). - chezmoi: home page and
chezmoi verify. - GNU Stow: project page ("a symlink farm manager").
How to compare
Compare along three axes:
- Source of truth. Where do your rules, agents, commands, and settings live? Apothem keeps one shared corpus and renders each harness's native format from it. Hand-maintained config keeps one copy per tool.
- Drift cost. What happens when you change a rule? Apothem propagates
the change to every installed harness on
apothem update. Hand-maintained config requires you to edit each tool's native file separately and keep them aligned by memory. - Verification. How do you know each harness is correctly configured?
Apothem ships
apothem verify --harness <name>andapothem doctor. Hand-maintained config has no built-in verification.
Feature matrix
The matrix contrasts Apothem against the two alternatives operators reach for first: hand-maintaining each harness's native config, and managing those files through a general-purpose dotfile manager.
| Capability | Hand-maintained config | Dotfile manager | Apothem |
|---|---|---|---|
| Single shared source of truth | No (one copy per tool) | No (tracks files, not a profile) | Yes (one profile) |
| Renders harness-native formats | Manual | No | Yes (per-adapter materializer) |
| Cross-harness drift prevention | Manual alignment | File sync only | Yes (apothem update) |
| Per-harness install/uninstall | Manual | Partial (symlink/copy) | Yes (install / uninstall) |
| Built-in verification | None | None | Yes (verify / doctor) |
| Format translation per tool | None | None | Yes (.mdc, .toml, embedded .md) |
| Seventeen harnesses from one input | No | No | Yes |
Comparison pages
- Apothem vs other harness frameworks
- vs raw antigravity
- vs raw claude-code
- vs raw codebuddy
- vs raw codex
- vs raw cursor
- vs raw gemini-cli
- vs raw github-copilot
- vs raw glm
- vs raw hermes
- vs raw kimi-code
- vs raw kiro
- vs raw open-claw
- vs raw opencode
- vs raw qwen-code
- vs raw trae
- vs raw windsurf
- vs raw zed
For per-harness adapter detail, see the harness adapters section.