Reviews, comparisons, alternatives, and practical guides for AI coding tools and agents — including Cursor, Claude Code, Codex, GitHub Copilot, Cline, Devin, and more.
CC Switch can change provider configuration, routing, and related tool settings, but it does not automatically transfer a model’s understanding of your repository. Treat CC Switch codebase context as an access-and-configuration concern. Preserve architecture facts, dependency evidence, task decisions, and verification results in a separate model-independent layer.
That distinction prevents a dangerous assumption: a successful provider switch proves that requests reach a different backend; it does not prove that the new model knows which files matter, why a boundary exists, or which tests validate the planned change.
What CC Switch Actually Switches
CC Switch is a third-party, open-source desktop application, not an official feature of Claude, Kimi, Codex, or OpenAI. Its repository describes one interface for managing provider profiles across supported coding tools, along with MCP and Skills synchronization, session browsing, local proxy routing, and configuration backups.
The application can therefore affect several operational layers:
Layer
What CC Switch can manage
What that does not establish
Provider profile
Endpoint, API format, model choice, credential reference, and active profile
That the new model has read the repository
Local routing
Protocol conversion and forwarding for providers that need it
Equivalent model behavior or tool semantics
Shared configuration
Selected MCP, Skills, prompts, or common config fields
Shared private reasoning or task conclusions
Session interface
Browsing, searching, restoring, or reclassifying supported history
Guaranteed cross-provider continuation
Backup state
Copies of configurations or migrated session records
A current architecture map
The v3.18.0 release demonstrates the routing role clearly. It added and refined paths that let Codex communicate with providers using different upstream protocols. The Kimi guide explains a Responses-to-Chat-Completions conversion path; the Claude guide explains a Responses-to-Anthropic-Messages path. Both require local routing, and both recommend restarting the Codex process after switching so it reloads configuration and model-catalog data.
Those are meaningful capabilities, but they answer where requests go and how protocols connect. They do not answer what the repository means.
What Happens to Codebase Understanding
Repository understanding is constructed inside a task from selected files, instructions, search results, tool output, and intermediate judgments. A model may infer that a schema is authoritative, that a generated client must change, or that a failing test is unrelated. None of those conclusions becomes part of another provider merely because the endpoint changes.
After a Claude-to-Kimi context switch, for example, the new model may receive the same checked-out files and the same committed instructions. It does not automatically inherit:
which paths the earlier model inspected and which it skipped;
the earlier model’s private reasoning about an architectural trade-off;
unresolved hypotheses, rejected alternatives, or confidence levels;
an in-memory list of callers, dependencies, owners, and affected tests;
tool results that were never written to a durable handoff;
permissions or credentials held by the previous process.
Even shared Skills and MCP configuration should not be confused with coding agent repository memory. A Skill can define a workflow. An MCP server can expose a tool. Neither proves that the new provider has loaded the same evidence, interpreted it the same way, or validated it against the current commit.
The safe operating assumption is simple: a provider switch starts a new evaluator unless you explicitly supply a reviewed evidence packet. The existing guide to sharing context across coding agents owns the generic cross-tool pattern; this article focuses on the CC Switch boundary.
Session History vs Repository Knowledge
CC Switch’s unified Codex session-history feature makes an especially useful boundary test. Its official project guide says the feature only rewrites the model_provider classification tag so official and third-party sessions can appear in one history list. It backs up records before migration, but it does not rewrite the conversation body into a provider-neutral reasoning format.
The same guide warns that resuming an old session through another backend may fail because the session can contain encrypted_content reasoning that only the backend that created it can decrypt. The record may still be visible and its plain text may still exist on disk, yet provider B may be unable to continue provider A’s session.
This creates three distinct states:
Visible: the session appears in a history or resume list.
Readable: the stored plain-text messages can be inspected.
Continuable: the active backend can resume the session and generate another turn.
Unified history improves the first state. It does not guarantee the third. More importantly, even a continuable transcript is not a verified repository model. It can contain old file paths, assumptions from an earlier commit, failed experiments, and conclusions that were never tested.
Use session history as an audit trail and task clue. Promote only verified facts into durable repository evidence.
How a Code Graph Reduces Context Loss
A model-independent code graph can preserve structural evidence that is expensive to rediscover: packages, files, symbols, imports, calls, schemas, routes, tests, owners, and architecture records. The graph should be tied to a repository revision and should link every important relationship back to inspectable source.
The graph reduces context loss when it serves a narrow handoff:
Pin the source state. Record the commit or worktree revision that produced the graph.
Query for the task. Retrieve only the modules, dependency paths, contracts, owners, and tests relevant to the requested change.
Preserve provenance. Include file paths, symbols, edge types, and source locations rather than an unsupported summary.
Mark uncertainty. Separate deterministic imports or references from inferred runtime relationships.
Verify after switching. Ask the new model to open high-impact source and run the required tests.
This is not automatic memory transfer. It is a repeatable way to reconstruct the right working set for another model. Graphify can serve as one external evidence layer, while the CC Switch knowledge graph workflow covers the complete two-layer operating model.
Practical Migration Checklist
Before changing a provider, create a compact migration packet. After switching, require the new model to validate it before editing.
Before the switch
Record the active provider, model, protocol path, and CC Switch routing state.
Pin the repository commit and list any uncommitted changes.
Save the task goal, non-goals, acceptance criteria, and protected paths.
Export verified file, symbol, dependency, owner, and test evidence.
Label model-specific conclusions as hypotheses unless source or tests prove them.
Record failed commands, partial migrations, and unresolved risks.
Remove secrets, raw credentials, private data, and irrelevant transcript content.
After the switch
Restart the affected CLI when its configuration is read at process startup.
Confirm the intended provider, endpoint path, model, and local-routing state.
Start a new session if cross-provider resume fails or reasoning provenance is unclear.
Reopen the authoritative source behind every high-impact graph edge.
Rerun focused tests for the changed surface, then the repository-required suite.
Compare the new plan with the saved constraints before allowing writes.
This checklist makes a failed transfer observable. “The session opened” is not a validation result; “the new model confirmed these paths at this commit and these tests passed” is.
Keep the first post-switch change deliberately small when the task allows it. Review the new model’s selected files, stated assumptions, patch, and focused test result before assigning a broader refactor. If that short pilot exposes a mismatch between the evidence packet and current checkout, refresh the packet and restart planning instead of compounding uncertain context with more edits.
FAQ
What should be checked after switching providers?
Check provider identity, model, endpoint, protocol conversion, local-routing status, loaded instructions, repository commit, dirty files, and tool permissions. Then verify the task’s important dependency paths against source and rerun focused tests. If the CLI reads configuration only at startup, restart it before trusting the check.
Can old session notes mislead a new model?
Yes. Notes can describe a previous commit, preserve an abandoned hypothesis, omit failed tests, or mix facts with model-specific inference. Keep provenance and timestamps, label uncertainty, and require the new model to confirm high-impact claims in current source. Do not treat a visible transcript as repository truth.
How should teams document failed transfers?
Record the source and destination providers, session identifier, repository revision, routing state, exact failure, affected evidence, and recovery choice. Distinguish “history not visible,” “history readable but not resumable,” and “task evidence incomplete.” Preserve logs only after checking them for credentials or sensitive content.
Conclusion
CC Switch makes provider and configuration changes easier, but a provider switch is not a repository-understanding transfer. Unified session visibility, synchronized Skills, and working protocol conversion remain separate from the model’s current evidence about code.
Use CC Switch for the access layer. Use a revision-bound repository graph, source-controlled instructions, decision records, and test results for the knowledge layer. When the provider changes, start from a compact evidence packet, verify it against current source, and restart planning whenever the old model’s assumptions cannot be reproduced.
Orca multi-agent coding turns a collection of terminal-based coding assistants into a coordinated desktop workspace. Instead of opening Claude Code, Codex, OpenCode, or another CLI agent in unrelated terminals, Orca gives each task a visible workspace, an isolated Git worktree, file and diff context, and a path for handing work between agents.
That makes Orca more than a launcher. It is an Agent Development Environment—or ADE—designed around the operational problems that appear after a team starts running several coding agents at once: branch isolation, terminal sprawl, review, remote access, task dispatch, and human approval.
The original Chinese tutorial from ITPostman provides an extensive Windows walkthrough. This English guide takes a different approach: it explains the current product model, verifies features against Orca's official repository and documentation, updates version-sensitive setup instructions, and adds the security and workflow limitations that a production team should understand before adopting it.
Orca brings agent terminals, worktrees, project context, and mobile monitoring into one workspace. Source image from the original ITPostman tutorial.
What Is Orca Multi-Agent Coding?
Orca is an open-source desktop application from Stably AI for running CLI coding agents side by side. Its official repository describes it as an orchestrator for agents such as Claude Code, OpenAI Codex, OpenCode, Pi, Hermes, Grok, Cursor CLI, GitHub Copilot CLI, and many others. The general compatibility rule is simple: if an agent runs interactively in a terminal, Orca can usually host it.
Orca does not replace those agents or bundle their models. You bring your own subscriptions, accounts, and command-line installations. Orca provides the surrounding environment:
projects and isolated Git worktrees;
persistent terminal sessions and split panes;
source files, diffs, annotations, and Git operations;
GitHub, GitLab, and Linear workflow surfaces;
an embedded Chromium browser with Design Mode;
SSH workspaces and port forwarding;
automation, orchestration, and Computer Use commands;
a mobile companion for monitoring and steering the desktop app.
As of July 16, 2026, the GitHub repository had about 20.4K stars and used the MIT License. That popularity is notable for a project created only in March 2026, but stars are not evidence of reliability or security. Orca ships frequently, which makes its release notes and current documentation more dependable than screenshots of a particular version.
The Mobile Companion can monitor and steer agents running through the desktop app; it is distinct from emulator and device automation.
The Core Idea: One Task, One Worktree, One Agent
The strongest Orca workflow is not simply “run more agents.” It is to create explicit task boundaries.
A Git worktree is a separate working directory connected to the same repository object database. Each worktree can use its own branch, files, agent session, and terminal state. That is more efficient than cloning an entire repository for every task, while still isolating filesystem changes.
For example, a team could create:
ui-shell-claude for interface and responsive-layout work;
split-engine-codex for business logic and tests;
export-opencode for CSV and Markdown export.
Each agent operates in a different branch and working directory. The main workspace can review their diffs and merge selected work.
Isolation is not absolute. Agents can still collide on shared databases, network ports, caches, external APIs, generated resources, or assumptions about the same interface. Parallel development also creates ordinary merge conflicts when two branches change the same code. The worktree model reduces accidental file overlap; it does not eliminate coordination.
Parallel worktrees let agents explore or implement separate tasks without sharing one mutable working directory.
Supported Platforms and Installation
Orca currently provides desktop builds for:
macOS on Apple Silicon and Intel;
Windows 10 and 11 on x64;
Linux through AppImage, with additional release assets such as Debian and RPM packages.
The official download page is the simplest starting point. The GitHub Releases page provides explicit platform files, while macOS users can also install the Homebrew cask:
brew install --cask stablyai/orca/orca
Installing Orca does not automatically install or authenticate every coding agent. Before creating a workflow, verify the CLI tools you intend to use:
claude --version
codex --version
opencode --version
gh --version
Only the relevant commands need to be present. GitHub CLI can be useful for GitHub authentication and operations, but it should not be described as a universal Orca dependency. Linear integration requires a personal API token, which should be scoped and stored carefully.
The onboarding UI can detect installed agents and offers defaults for terminal, theme, notifications, and project setup. Counts such as “32 available agents” are version-dependent. The durable claim is that Orca ships many presets and can run other terminal agents through custom setup.
Parallel Terminals Without Losing Context
Agentic coding creates a new kind of terminal problem. A conventional terminal is organized around processes and tabs, while the user thinks in terms of tasks, branches, agents, reviews, and decisions.
Orca associates terminals with a project and worktree. It supports split panes, persistent scrollback, and multiple sessions inside the same workspace. Its documentation describes the terminal as using xterm.js—the same terminal foundation used by VS Code—with themes and settings that can be imported from Ghostty.
The advantage is contextual persistence. When a user returns to a worktree, the associated terminals and agent history remain connected to the task. This is particularly useful when one agent is waiting for input, another is running tests, and a third is investigating a failure.
More terminals still create cognitive load. A useful operating rule is to assign each worktree one clear objective, define a verification command, and close or archive sessions once the task is complete. Unlimited panes should not become unlimited unfinished work.
Split terminals are most effective when every pane belongs to a named task and a defined worktree.
Design Mode: Send UI Context to an Agent
Orca's embedded Chromium browser includes Design Mode. A user can select an element on a running page and send structured context to the active agent. According to Orca's documentation, that context can include:
the selected HTML and nearby DOM;
computed CSS;
a cropped screenshot;
source location when a source map is available;
a human annotation describing the desired change.
This is more useful than sending only a screenshot because the agent receives both visual evidence and implementation context. A designer or reviewer can point at a spacing problem, label it, and let the agent trace the relevant component and styles.
Design Mode does not remove the need for review. The agent may identify the wrong source file, overgeneralize a local change, or create a layout that works at one viewport and fails elsewhere. Pair visual instructions with responsive checks, accessibility requirements, and regression tests.
Design Mode packages selected browser context so an agent can act on a specific visible issue.
GitHub, Linear, Diffs, and Review
Orca includes native workflow surfaces for code review and task systems. Official documentation covers GitHub pull requests, issues, projects and Actions, as well as Linear tasks through a personal API token. The application also exposes Git and diff tools inside each workspace.
One of the more practical features is diff annotation. A reviewer can attach a comment to a changed line and send that feedback back to the agent. The result is a tighter loop:
the agent makes a change;
the human reviews the actual diff;
the human attaches precise feedback;
the agent revises the branch;
tests run again before merge.
This is a safer pattern than asking an agent to “fix everything” in an unbounded session. The review artifact stays connected to a branch and a visible patch.
Access scope matters. GitHub, GitLab, and Linear credentials can expose private repositories, issues, customer information, and internal plans. Use the smallest permissions that support the workflow, and avoid pasting long-lived tokens into an agent prompt or terminal history.
Integrated work items reduce context switching, but their tokens and repository permissions still need deliberate scoping.
SSH Worktrees for Remote Development
Orca can create worktrees on a remote machine over SSH while retaining file editing, Git operations, terminals, agent sessions, reconnection, and port forwarding.
This is useful when the project needs:
a Linux environment unavailable on the local machine;
more CPU, RAM, or GPU capacity;
access to an internal development network;
a long-running agent session that should survive a laptop interruption.
Official documentation says remote PTYs can remain alive through a relay on the remote host, with a default grace period after the desktop app closes. Orca can also remember an SSH passphrase in memory for a configurable period.
Those conveniences increase the trust boundary. Review remote-host ownership, SSH keys, passphrase retention, port-forward bindings, and the processes left running after disconnection. A forwarded development server should not accidentally bind to a public interface or expose an unauthenticated tool.
SSH worktrees extend the same agent workflow to remote development hosts, including reconnect and port-forwarding support.Line-level annotations create a concrete human-review loop before agent changes are accepted.
Dragging Files and Using the Orca CLI
Files and images can be dragged from the file explorer into an agent session. That is helpful for design references, logs, test fixtures, screenshots, and documents that would be awkward to describe in a prompt.
Treat dragged files as data disclosure. The terminal agent—not Orca alone—may send the attachment or extracted content to its model provider. Provider privacy policies, enterprise controls, and data-retention terms still apply.
Orca also exposes a CLI so agents and scripts can interact with the application. Current documentation includes commands for worktrees, browser interaction, snapshots, orchestration, automation, and Computer Use. The CLI makes Orca programmable, but it also means a coding agent can affect more than the repository if given broad permissions.
Keep command scopes explicit. A task that needs to inspect a page should not automatically receive permission to submit forms, send messages, delete resources, push code, or modify accounts.
File drag-and-drop is convenient, but the destination agent’s data policy governs what happens after the content enters its context.The Orca CLI turns workspace operations into a programmable interface for scripts and agents.
Orchestration: Hand Work Between Claude Code and Codex
The original tutorial demonstrates a common pattern: one agent analyzes a task and another implements it. For example, Claude Code may inspect the repository and prepare a plan, then dispatch the implementation to Codex in a dedicated worktree.
Current Orca documentation describes a native orca orchestration command surface with persistent messages, tasks, dispatches, heartbeats, completion signals, decision gates, and a coordinator loop. This is more structured than copying a long prompt between terminal windows.
A safe handoff should include:
the objective and acceptance criteria;
verified file paths and current behavior;
files or modules that must not change;
required tests and build commands;
the target worktree and branch;
permission boundaries;
the expected completion report.
The receiving agent should independently inspect the repository rather than trusting every assumption in the handoff. The coordinator should verify the resulting diff and tests before merging.
For a deeper comparison of the underlying assistants, see Claude Code vs Codex CLI. The Orca layer coordinates those tools; it does not make their capabilities identical.
Scheduled Automation
Orca can schedule recurring agent tasks by time and workspace. Official documentation covers hourly, daily, weekday, weekly, cron, and RRULE schedules, along with timezone, repository, provider, session-reuse, and fresh-session settings.
Useful jobs include:
daily test and production-build verification;
dependency or security-report generation;
review of commits from the preceding 24 hours;
repository health summaries;
non-mutating checks of a staging environment.
Start automations disabled, run them manually, inspect their permissions, and only then enable the schedule. A scheduled agent that can modify code, push branches, access browsers, or use external integrations can repeat a mistake without a human present.
The best default is reporting rather than repair: inspect, test, summarize, and ask for approval before making consequential changes.
Computer Use and Mobile Control Are Different Features
Two Orca capabilities are easy to conflate.
The Mobile Companion lets a phone monitor and steer agents running through the desktop application. It can show terminal scrollback and files, send replies and attachments, review source-control changes, and receive notifications. Orca documentation says the desktop remains the source of truth and that the connection does not rely on a cloud relay. If the desktop app is closed, the mobile connection ends.
Device automation is separate. Orca includes skills and commands for Android environments visible through ADB, including emulators and configured physical Android devices. iOS automation targets Apple Simulator on macOS with Xcode; the cited documentation does not establish equivalent control of a physical iPhone.
Computer Use allows an agent to operate local desktop applications through accessibility trees, screenshots, keyboard input, and visible UI actions. macOS requires Accessibility and Screen Recording permissions, and other operating systems have their own native providers.
These are powerful permissions. Orca's own safety guidance warns against automatically pushing code, submitting forms, sending messages, purchasing, deleting, changing account settings, or exposing secrets without explicit permission. Read the current state before every action, keep personal tabs and accounts out of scope, and require human confirmation for destructive or externally visible operations.
Privacy and Telemetry
Packaged Orca builds collect anonymous product telemetry through PostHog Cloud in the United States. Orca's telemetry documentation says it records application version, platform, lifecycle events, coarse feature use, and agent kind, but not prompts, model output, file content, repository paths, URLs, commit text, usernames, or email addresses.
Users can opt out in Settings or through environment variables such as:
DO_NOT_TRACK=1
ORCA_TELEMETRY_DISABLED=1
That is only one part of the data path. Claude Code, Codex, OpenCode, and other agents have their own providers, privacy terms, authentication, retention, and enterprise settings. Files dragged into a session, terminal prompts, repository content, and Computer Use observations may be processed under those separate terms.
Mobile pairing, SSH access, API tokens, and browser permissions also deserve threat modeling. The application is open source, but open source is not a substitute for reviewing permissions, releases, dependencies, and operational controls.
Where Orca Fits—and Where It Does Not
Orca is a strong fit when a developer or small team:
regularly uses more than one CLI coding agent;
needs parallel branches or implementation experiments;
wants a single place for terminals, files, diffs, and review;
works across local and remote machines;
values programmable orchestration and scheduled checks.
It may be unnecessary when the task is a quick one-off command, when a single IDE agent already covers the workflow, or when the team is not prepared to review several concurrent branches. The original author makes a similar practical point: for a temporary filesystem task, the operating system terminal can be faster than creating a full managed workspace.
Orca should also be evaluated carefully in high-compliance environments. Its value comes from connecting agents to repositories, terminals, issue systems, browsers, remote machines, and possibly desktop applications. Every connection improves capability while expanding the security boundary.
A production-minded first experiment can be small:
Install Orca from the official download or release page.
Verify Git and one or two agent CLIs independently.
Open a non-sensitive repository with reliable tests.
Create one worktree for a bounded change.
Give the agent acceptance criteria and explicit prohibited actions.
Review the diff and annotate problems inside Orca.
Run tests and the production build.
Merge manually only after the result is understood.
Add a second agent or orchestration handoff after the single-agent loop is dependable.
Enable mobile, SSH, automation, or Computer Use only when the workflow genuinely requires them.
This sequence measures whether the environment improves delivery rather than merely increasing the number of active agents.
Orca’s repository grew rapidly after its March 2026 launch. Popularity is a useful adoption signal, but not a substitute for release and security review.Use the official Orca download page or GitHub Releases rather than relying on a third-party installer mirror.Orca publishes skills for Computer Use, orchestration, Linear workflows, emulators, and workspace configuration in its open-source repository.
Conclusion
Orca multi-agent coding addresses a real transition in software development. Once developers use several coding agents, the limiting problem is no longer opening another terminal. It is defining isolated tasks, tracking active work, handing context between agents, reviewing patches, and controlling what automation is allowed to do.
Orca combines those concerns in an ambitious open-source desktop environment. Its worktrees, persistent terminals, Design Mode, diff annotations, SSH workflow, orchestration CLI, mobile companion, and Computer Use integration can create a productive control plane for agentic development.
The same breadth creates the main caveat. Orca can sit between valuable source code and multiple model providers, remote machines, issue systems, browsers, and local applications. Adopt it progressively, scope credentials and permissions, keep a human responsible for every merged result, and treat the current documentation—not a version-specific screenshot—as the authority for setup.
No. Orca is a desktop environment and orchestration layer for CLI agents. Claude Code, Codex, OpenCode, and other tools keep their own models, subscriptions, authentication, and data policies.
Can Orca run Claude Code and Codex at the same time?
Yes. Each can run in its own terminal or worktree, and Orca's orchestration tools can dispatch structured tasks between agents.
Is Orca free and open source?
The desktop repository is published under the MIT License. Users still need any paid subscriptions or API access required by the agents they choose to run.
Does Orca support Windows, macOS, and Linux?
Yes. Current downloads cover macOS on Apple Silicon and Intel, Windows 10/11 x64, and Linux packages including AppImage.
Does Orca control a physical phone?
The Mobile Companion controls and monitors the Orca desktop workflow from a phone. Separate Android tooling can automate ADB-connected emulators or configured devices. Official iOS automation documentation covers Apple Simulator on macOS, not general physical-iPhone control.
What is the biggest risk of using Orca?
Permission sprawl. Orca can connect agents to code, terminals, Git hosts, issue systems, SSH machines, browsers, files, and desktop UI. Use least-privilege credentials and require human confirmation for destructive or externally visible actions.
Comet began as an orchestration layer for combining OpenSpec’s specification lifecycle with Superpowers-style planning and execution. The project now describes itself more broadly: a resumable workflow and Skill platform for coding. That shift matters because current Comet has three distinct jobs, not one:
/comet runs a guarded software-change workflow.
/comet-any turns existing Skills into a reusable workflow package.
comet eval tests whether a Skill behaves reliably enough to advance toward publication.
A June 2026 WeChat article from 职场向上生长力 explains the original five-phase design well. It is now a historical snapshot of the 0.3.x line: its central state-machine model remains relevant, but several counts, scripts and product boundaries changed in the 0.4 beta series. This guide uses the current official rpamis/comet repository and release metadata as the authority.
Version reality: current does not mean stable
Classic is the established architectural core, but the current npm default remains a semantic prerelease; pin the exact package version.
As of July 16, 2026, npm’s latest tag for @rpamis/comet points to 0.4.0-beta.4, published July 12. It is the current default install, but the beta identifier still makes it a semantic prerelease. The last version without a prerelease suffix is 0.3.9, published June 18.
Choice
What it means
Best fit
@rpamis/comet@0.3.9
Last non-beta release; mature Classic workflow built around the 0.3 architecture
Teams prioritizing a fixed, non-prerelease baseline
@rpamis/comet@0.4.0-beta.4
Current npm default; pure Node runtime plus the expanded Skill and eval platform
Evaluation, new integrations and teams willing to absorb beta changes
Unpinned @rpamis/comet
Currently resolves to beta.4 because npm latest points there
Only when your update policy intentionally follows the current channel
The repository calls Classic Spec “the stable core for long-running tasks.” Read that as a product-architecture claim: the five-phase lifecycle is the established center of Comet. It does not turn the 0.4.0-beta.4 package into a generally available 0.4 release. Likewise, beta.4’s release notes call several top-level commands “Stable Classic commands”; that describes their supported interface inside the beta, not the maturity label of the entire package.
Pin the version in team setup documentation and automation. Otherwise, the same installation command can resolve to a materially different runtime over time.
What changed in the 0.4 beta line
The most visible engineering change is a pure Node runtime. The 0.4 README says Comet no longer depends on Bash or WSL; the package declares Node.js 20 or newer. This is especially meaningful for Windows users and for cross-platform workflow bundles, because state and guard logic no longer depend on a shell environment that behaves differently across machines.
The product surface also expanded:
Classic Spec remains the requirements-to-archive workflow.
/comet-any authors composed Skill Bundles with workflow nodes, schemas, guards and handoffs.
comet eval supplies local or LangSmith-connected evaluation evidence.
comet dashboard provides a read-only browser view of active changes and archive history.
Beta.4 adds or hardens ambient resume, a registry of project-scope installations, direct comet state, comet guard, comet handoff and comet archive commands, custom build evidence, multi-change guards, archive confirmation and Codex Skill discovery. Those details come from the official 0.4.0-beta.4 release, not from the older WeChat walkthrough.
Surface 1: Classic Spec with /comet
Classic Spec is for a software change that should move through a controlled lifecycle. Its conceptual phases remain:
Open — turn an idea into an OpenSpec change and obtain human agreement on scope.
Design — record architectural decisions and resolve ambiguity before implementation.
Build — create an execution plan, choose isolation and implement under review rules.
Verify — collect test, task and design-conformance evidence.
Archive — synchronize the accepted delta into the main specification and close the change.
The important mechanism is not the command sequence. It is durable external state. Each managed change stores workflow facts in .comet.yaml: phase, mode, artifact references, verification outcome and archive status. /comet can inspect that state and recommend the next legal action after a terminal restart or context reset.
Guards are equally important. A useful workflow must reject illegal transitions, not merely remind the agent what it should do. Comet’s Classic runtime checks prerequisites before phase advancement and can restrict source writes while a change is still in requirements or design. Beta.4 also requires final archive confirmation to be represented in machine-owned state, so calling an internal path cannot silently bypass the human decision.
A practical Classic setup
Requirements are Node.js 20+, npm or npx, and Git. Choose a version deliberately:
# Last non-beta release
npm install -g @rpamis/comet@0.3.9
# Current beta evaluated in this guide
npm install -g @rpamis/comet@0.4.0-beta.4
Then initialize inside the target repository:
cd your-project
comet init
comet doctor --json
comet status --json
Use /comet from the supported coding agent to start or resume a change. Do not begin with automatic transitions enabled on a high-risk repository. First learn which points request scope, isolation, review and archive decisions. After the team trusts its checks, automation can reduce ceremony without hiding governance.
Surface 2: /comet-any for workflow authoring
/comet-any addresses a different problem: turning Skills into a distributable workflow rather than implementing a product feature. The current Skill defines a workflow contract in terms of:
Workflow Nodes that own resumable responsibilities;
Skill Bindings and required Skill calls;
Output Schemas attached to specific nodes;
Guardrails that permit or block advancement;
Handoffs containing cross-node or subagent evidence;
a workflow-protocol.json source of truth.
This is more rigorous than placing several Skill names in a prompt. A bound Skill does not automatically replace a workflow node, and a schema declared globally does not enforce anything until it is attached to a concrete node. The authoring flow requires a proposal and human confirmation before generation, then creates scripts, rules, hooks, references and an eval manifest.
There are two broad modes. A comet-five-phase-overlay customizes parts of Classic Spec while preserving .comet.yaml semantics and protected control nodes. A workflow-kernel is for a genuinely different lifecycle with its own state model and guard design. If a team wants to replace fundamental control nodes such as open, execute, verify or archive, it should treat that as a new kernel rather than quietly weakening Classic’s guarantees.
Use /comet-any when the deliverable is a reusable workflow package. Use /comet when the deliverable is a software change. Mixing those intents produces confusing state and weak acceptance criteria.
Surface 3: comet eval as evidence
Comet separates guarded software changes, reusable workflow bundles, and evaluation evidence into three connected surfaces.
comet eval asks whether a Skill can be discovered, executed and scored on defined tasks. For a bundle generated by /comet-any, the recommended sequence is:
--collect is a low-cost preflight: it checks the manifest, task discovery and dependency paths without starting the expensive evaluation. --html performs the run and creates a browsable report. The official documentation distinguishes raw runs from the clean analysis set and attributes failures to harness, workflow, task, model or environment instead of folding every infrastructure error into a Skill-quality score.
For an early local Skill without an eval manifest, comet eval ./my-skill --quick --html is a smoke test. It is not final release evidence. Publish readiness expects evaluation tied to the current draft hash; failed, missing or stale-hash evidence blocks progression.
The README discusses Rubric, Pass@k and Pass^k scoring and shows repository-generated benchmark charts. Treat those results as project evidence for its published tasks and treatments, not proof that every team’s custom workflow will improve by the same amount. Your tasks, model, environment and validators determine whether the measurement transfers.
Choosing the right Comet path
Start with the outcome:
For a feature, bug fix or refactor that needs traceable requirements and verification, use Classic /comet.
For a repeatable organizational process assembled from multiple Skills, use /comet-any.
For evidence that a Skill works across runs, use comet eval.
For a conservative rollout, pin 0.3.9 and test the beta in a separate repository.
For 0.4 capabilities, pin beta.4, record the version in artifacts and rerun evaluation when upgrading.
Comet’s most valuable idea is not that an agent can execute five commands. It is that workflow control can be represented as files, state transitions, deterministic checks and review evidence. That architecture survives a context window. The 0.4 beta extends the same principle from one software-development workflow to a broader platform for composing and evaluating Skills.
AI coding agents are fast at local execution and unreliable at remembering why a project works the way it does. Trellis addresses that gap by putting durable engineering context inside the repository: scoped specifications, task artifacts, per-developer journals, workflow state, and platform-specific agent configuration.
That makes Trellis less like a model or code generator and more like an agent harness. It does not replace Claude Code, Codex, Cursor, or another coding agent. It gives those agents a shared project layer and a repeatable delivery loop.
At the time of this review, the mindfold-ai/Trellis repository had roughly 12.7k GitHub stars—12,662 when checked—and the npm package was version 0.6.7. The project uses the AGPL-3.0-only license. Its current prerequisites are Node.js 18.17 or newer for the CLI and Python 3.9 or newer for the scripts and hooks.
What Trellis stores in the repository
The .trellis/ directory holds the stable project context; generated skills, hooks, and host entry files adapt that core to each coding environment.
The .trellis/ directory is the stable core across supported coding tools. Four areas matter most:
spec/ stores team conventions: directory structure, error handling, testing, component patterns, and other rules that should survive a chat session.
tasks/ stores active and archived work, including a PRD and separate context manifests for implementation and review.
workspace/ stores per-developer journals so a later session can recover what happened without reconstructing the entire conversation.
workflow.md and runtime state tell the agent which phase is active and what evidence it should produce next.
Trellis also generates platform-specific skills, subagent definitions, commands, hooks, and entry files such as AGENTS.md. The core artifacts stay the same, but their delivery varies by host. Claude Code, Cursor, and OpenCode expose richer hook and subagent integration; other tools may rely on pull-based context, a prompt file, or an inline main-agent path.
This distinction is important. “Supports 17 platforms” means Trellis ships configurators for 17 environments. It does not mean every environment provides identical session-start events, pre-tool hooks, slash commands, or subagent context injection. The official capability matrix should be reviewed for the exact tools a team uses.
The current four-phase loop
Plan selects context, Implement produces the change, Verify collects evidence, and Finish archives the task while promoting durable lessons.
The current Trellis README describes a four-phase workflow:
Plan — trellis-brainstorm clarifies the task one question at a time and writes prd.md. Research-heavy questions can be delegated to trellis-research. The plan curates which specs and research artifacts belong in implement.jsonl and check.jsonl.
Implement — trellis-implement works from the PRD and the selected implementation context. It is instructed not to commit the change.
Verify — trellis-check reviews the diff against the task and specs, then runs the relevant lint, type-check, and test commands. It can self-fix small mechanical issues.
Finish — a final check runs, trellis-update-spec promotes durable lessons into the spec library, and finishing the work archives the task and updates the developer journal.
An older source described spec update as a separate third stage and finish as a fourth. The current documentation folds spec promotion into Finish, after Plan, Implement, and Verify. That is more than naming: the knowledge update is part of closure, not an optional cleanup step detached from verification.
Specs are bootstrapped, then curated
The most consequential correction to older Trellis reviews concerns specification authoring. Trellis no longer expects every team to fill every placeholder entirely by hand. The official README says many teams let AI draft specifications from the existing codebase, then tighten important rules manually. The quick-start documentation also includes a bundled spec-bootstrap skill and an optional template marketplace.
The right mental model is AI draft, team curate:
Use the codebase to produce a first-pass description of actual patterns.
Delete generic advice that does not constrain a decision.
Add concrete examples and counterexamples from the repository.
Review high-impact rules—security, migrations, API compatibility, testing, error handling—like code.
Keep the specs versioned and update them when a verified task establishes a better convention.
AI-generated specs are not automatically trustworthy. A model can faithfully document an accidental pattern, copy an anti-pattern that happens to be common, or turn preferences into false absolutes. Trellis provides the structure and update path; the team remains responsible for the standard.
Why context manifests are useful
Large instruction files often fail in two ways: they consume context on every turn, and unrelated rules distract the agent from the current task. Trellis instead uses task-specific JSONL context manifests.
The planning phase selects the relevant material for implementation and checking. An implementation worker might need API conventions, database rules, and the PRD. A reviewer may need those plus testing and error-handling guidance. The two manifests can differ, which helps keep each agent’s context bounded and makes the selection inspectable.
This mechanism does not guarantee lower total token use. Hooks, planning, subagents, checks, and spec updates all cost time and model work. Its value is context precision and repeatability, not free context. Teams should compare end-to-end latency and usage against their current workflow on representative tasks.
Project memory without one giant chat history
Trellis journals record what a developer completed, while task state records what remains active. On hook-backed platforms, session startup can inject identity, Git status, active tasks, spec indexes, and recent journal context. On tools without the same hook surface, an entry skill or generated prelude supplies a fallback.
This is durable memory in the engineering sense: versioned project knowledge plus developer-specific work summaries. It is not a claim that every past conversation is automatically correct or that journal context should override the repository. The current code, tests, and reviewed specs remain the source of truth.
Per-developer workspace directories reduce journal conflicts, while shared specs and tasks remain reviewable through normal pull requests. Teams should still define ownership for spec changes; otherwise, the knowledge base can accumulate contradictions as quickly as a monolithic AGENTS.md file.
Installation and a safe first pilot
Install the current CLI and initialize only the platforms you actually use:
The generic trellis init -u your-name flow can auto-detect installed platforms. Pinning the npm version makes a team trial reproducible; @latest is convenient for exploration but can change generated templates between machines.
For an existing codebase, use this pilot sequence:
Initialize Trellis on a disposable branch.
Let the bootstrap workflow draft a narrow set of specs from real code.
Have maintainers review and reduce those specs to high-signal rules.
Choose one medium-sized, reversible feature with clear acceptance criteria.
Run the complete Plan → Implement → Verify → Finish loop.
Inspect which files each JSONL manifest selected.
Intentionally violate one rule and confirm the review phase catches it.
Start a new session and verify that task and journal recovery are accurate.
Measure repository footprint, merge noise, runtime, and model usage before expanding adoption.
Codex users need an additional platform check. Current Trellis documentation says Codex uses an AGENTS.md prelude, skills and agent files, and a UserPromptSubmit hook; hook support must be enabled and reviewed in compatible Codex releases. Subagent context injection is not identical to Claude Code’s PreToolUse path, so parity should be tested rather than assumed.
Trade-offs teams should evaluate
Repository weight
Trellis generates more than a single instruction file. Exact file counts vary by version and selected platforms, so an old “152 files” result should not be treated as a fixed product property. The meaningful question is whether those generated files stay stable, reviewable, and useful enough to justify their maintenance cost.
Platform variance
The same .trellis/ core can be shared broadly, but automation depth varies. Some platforms have full session and subagent hooks; others use skills or inline execution. A mixed-tool team should test its least-capable required platform first.
Spec quality and governance
Poor specs scale poor decisions. Teams need reviewers, ownership, deprecation rules, and a way to resolve conflicts between written standards and working code.
Workflow overhead
Planning, isolated implementation, independent checking, and spec promotion are valuable for consequential work. They can be excessive for a one-line fix or disposable prototype. Trellis’s current quick-start says small inline tasks do not have to become Trellis tasks; use that escape hatch deliberately.
License
Trellis is licensed AGPL-3.0-only, not MIT or Apache-2.0. Organizations with distribution, modification, hosted-service, or proprietary integration concerns should have the intended use reviewed against the license before standardizing the tool. This is a governance check, not a reason to avoid the project automatically.
Who should adopt Trellis?
Trellis is most compelling for a long-lived repository where multiple people or coding agents repeatedly need the same architectural knowledge. It is particularly relevant when the team has already outgrown one large AGENTS.md or CLAUDE.md, when task context needs to be reviewable, or when sessions frequently lose the reasoning behind local conventions.
It is less compelling for a small prototype, a one-person script, or a repository whose conventions are still changing faster than anyone can curate them. In those cases, a concise instruction file plus normal tests may be the simpler and more reliable harness.
The core Trellis proposition is not “AI remembers everything.” It is “the repository carries the right memory forward.” That proposition succeeds only when specs are curated, tasks are closed honestly, checks are meaningful, and each platform’s integration is verified in practice.
I started using AI to write code in 2024. Two years later, my day-to-day development work looks very different. I hand tasks to agents: Codex handles refactors, Claude Code fixes bugs, and several projects often run in parallel. The tools themselves are strong enough that I initially assumed the bottleneck would be model quality.
It was not. The real friction sits around the model.
I switch to another project and have no idea whether the agent is still working or has been waiting at a confirmation prompt for half an hour. Two agents touch the same workspace and Git turns into a crime scene. A long task is halfway done, but I need to leave my desk. I want an agent to query a test database, but giving it credentials is obviously a bad idea. Every new session needs the same project rules repeated again. At the end of the month, I still do not know which project, model, or worktree burned the tokens.
I looked around and did not find something that fit the way I work.
So three months ago, I started building my own tool. That became Codux: a GPL-3.0 open-source native terminal for AI coding, now at 2.0 RC. This is not meant to be a feature dump. I want to explain the design decisions, because every feature came from a specific failure mode.
Why Not Electron
The first decision was the UI stack.
Codux is not an app I open once in a while. It is a desktop workspace that stays open all day. It needs to render several fast-scrolling terminals at once, while also showing Git state, files, agent status, token usage, remote sessions, and local memory. Electron can do a lot, but it was not the direction I wanted.
I ended up choosing GPUI, the UI framework behind Zed. The reasons were practical.
First, GPU rendering. Multiple terminals can be noisy, and frame stability matters.
Second, Rust all the way down. The terminal layer uses the alacritty crate, and PTY, networking, and state management are all Rust as well. I did not want to keep crossing language boundaries for a tool that lives close to the terminal.
Third, the state model fits this kind of app. GPUI’s Entity plus observer model, combined with snapshot rendering, means unchanged data does not need to trigger unnecessary redraws. For a long-running terminal workspace, that matters.
The cost is real. Documentation is thin. Many controls have to be built by hand. Linux desktop support is still not mature enough, which is why Codux currently only supports Linux as a headless host.
There were also plenty of sharp edges. You cannot read back a view entity inside a snapshot builder. An observer can fire while an entity is still inside an update lease, and reading it there will panic. If an observer is synchronously reachable from an action handler and needs to write back into app state, that write has to be deferred.
Each of those deserves its own post. But the upside is that the terminal can be refined at a very low level.
Codux supports things like:
⌘F search through scrollback with direct jump
Floating terminal windows
Pasting a screenshot into the terminal and turning it into a file path automatically
IME candidate windows that follow the cursor precisely
Terminal titles that show the active AI tool and model
Multiple active terminals without status updates dragging down rendering
These are not checklist features. They come from spending ten hours a day inside terminals. After a while, your hands remember what is annoying.
Status Detection Without Writing Files, Changing Config, or Installing Hooks
Codux needs to support multiple AI CLIs: Codex, Claude Code, OpenCode, Kiro CLI, Kimi Code, CodeWhale, MiMo Code, and Agy. It needs to know what each one is doing: generating, waiting for confirmation, idle, or finished. It also needs to track token usage and inject context where the tool supports it. The easiest approach would be obvious: write prompt files into the user’s repo, mutate global config, or install hooks.
A lot of tools go that way. I made all three red lines.
Codux detects state through process inspection and incremental parsing of each tool’s session files. It can distinguish between generating, waiting for confirmation, idle, and finished. “Waiting for confirmation” gets its own visible state, because yes, I have had an agent sit at a y/n prompt for forty minutes. More than once.
Context injection only uses official or clearly controlled channels. Codex uses developer instructions. Claude Code uses --append-system-prompt. OpenCode uses a managed plugin. Kimi uses --agent-file. If a tool does not have a confirmed non-invasive injection path, Codux does not force one by writing files into the project.
That line costs engineering time. But when a user uninstalls Codux, their environment should be clean. Their repo should not be left with my “smart” prompt files scattered around. That tradeoff feels right.
Worktrees Are the Task Container
The biggest problem with parallel agents is not that they misbehave. It is that they share a workspace. If two agents edit the same repo at the same time, no amount of polite prompting will keep Git clean forever. Instead of asking agents to avoid stepping on each other, Codux isolates the work physically.
In Codux, every task is a git worktree. A task owns its terminals, Git state, file view, and AI sessions. Switching tasks is not just switching tabs. It is switching the whole working context atomically.
ome back three days later, and the terminal is still exactly where it was.
The Git panel follows the same idea. You can stage, unstage, and discard at the directory level. You can inspect what the agent changed, keep what is good, and throw away what is not. The more I use this model, the more obvious it feels.
For agent-based development, a worktree should not be an advanced Git trick. It should be the default task boundary.
Credentials: The Process That Knows the Secret Should Not Be the Model
The part I am most strict about is credentials.
The threat model is simple: once a password enters a prompt, it enters model context. Once it enters context, it may enter transcripts. From there it may enter logs. In the worst case, it may travel farther than you expected.
Letting an agent read config files is even worse. That is basically handing it your ~/.ssh, database URLs, and test environment secrets. Writing “do not leak this” in a prompt is not a security boundary. So Codux separates knowing a credential from using a credential.
Connection profiles are stored in the desktop app and can be tested there. On the agent side, only two commands exist:
list only returns profile names and hostnames. The real password, private key, and connection string are injected inside a helper process. The model only ever sees the profile name.
If a database profile is marked read-only, the wrapper enforces a single-statement allowlist at the syntax layer. DROP and UPDATE are rejected before they get anywhere dangerous. This does not depend on the model “being careful.”
The boundary belongs at the process layer, not inside the prompt.
You Can Leave. The Task Should Not.
“Phone takeover” sounds like remote desktop, but Codux is not built as remote desktop.
The desktop app, mobile app, and headless host are peers. The transport layer uses end-to-end encrypted P2P when possible, and falls back to a relay when NAT gets in the way. The relay only sees ciphertext. No public IP is required. The important part is the session model: the work always stays on the host.
The PTY, agent process, terminal history, and task state all live on the host machine. The phone connects to the same running session. You can press enter, approve a permission request, or watch live output from your phone. When you return to the desktop, you keep working with the same processes.
Disconnect and reconnect, and you get the same task back. The headless codux-agent installs with one script and detects the system architecture automatically. If GitHub is slow, there is a --mirror option. codux install registers a launchd or systemd service. codux qrcode prints a pairing code. codux update upgrades itself.
My unused Mac mini finally has a job.
The hardest part here was the remote terminal protocol. Incremental frames plus baseline snapshots. Per-viewer acknowledgements. A single-owner lease for terminal size, because a phone and desktop cannot both resize the same PTY at once. Scrollback that does not reflow incorrectly across widths. It took four iterations to make that stable.
That also deserves its own post.
I also added a tunnel browser. Once the desktop connects to a host, the built-in browser can browse as the host. If Vite is running on the host at 127.0.0.1:5173, you type that locally and it opens through the Codux link. HMR, WebSocket, .local, VPN routes, all of it works without manual port forwarding. That is not a party trick. In remote development, “I just want to open the page running on that machine” is a daily need.
Memory and the Token Ledger
AI coding has two long-term problems: context disappears, and usage is hard to account for.
Codux has three layers of local memory:
User preferences
Project profiles
Module notes
When a new session starts, Codux injects that memory through the supported official channels mentioned earlier. The result is simple: you do not need to repeat that this repo uses pnpm, tests run with just test, generated files should not be touched, or a module has a known historical trap.
This is not meant to be a grand memory system. It just stores the boring things I got tired of saying again. Token tracking is split by tool, model, project, worktree, and date. It uses 30-minute buckets and a daily heatmap, stored in local SQLite.
Which project burned money? Which model was expensive? When was I actually working? You can see it. No cloud. No account. The data stays on the user’s machine.
And a Pet
This part has almost no productivity value, and I like it anyway. Every token an agent burns feeds a pixel pet. It has five stats: wisdom, chaos, night, stamina, and empathy. Those stats grow from real usage patterns and working hours. If you work late, the night stat gets very real.
You can use custom skins, and old pets can retire into a hall of fame instead of disappearing. Pointless? Mostly. But I still want to check it every day.
I no longer think small emotional details are out of place in developer tools. If you spend ten hours a day with a workspace, a little personality is not a defect.
Current Status
Codux is most stable on macOS 14 and later. Windows 11 works, but still needs polish. Linux desktop is blocked by GPUI maturity for now, so Linux currently runs as a headless host. Host pairing is beta.
Updates are frequent.
macOS desktop:
brew install --cask duxweb/tap/codux
Headless host:
curl -fsSL https://raw.githubusercontent.com/duxweb/codux/main/apps/agent/scripts/install.sh | sh
