The archive notice decides this review
The most important part of the OpenCode README is now the first six lines. This repository is no longer maintained, it has been archived for provenance, and the original author continues the project with the Charm team under the name Crush. That is not a stale-release inference or a guess based on quiet issues. It is the maintainer's explicit direction.
OpenCode had a compelling shape while it was active. Written in Go with a Bubble Tea terminal interface, it connected to OpenAI, Anthropic, Gemini, Bedrock, Groq, Azure, OpenRouter, GitHub Copilot, and local endpoints. It stored sessions in SQLite, tracked file changes, integrated diagnostics from language servers, and let models search, read, and modify a repository. Custom commands could turn repeated prompts into named actions. MCP support added external tools over standard input or server-sent events.
Those features explain why the source remains interesting. This was not a thin chat wrapper. It combined model choice, agent tools, session state, code intelligence, permissions, and a keyboard-driven interface in one binary. The MIT license leaves the implementation available for study. None of that changes the recommendation: an archived coding agent is a risky foundation because providers and models evolve even when its own code does not.
What the old client did well
The interactive workflow was unusually complete for an early 0.0 project. Users could switch sessions and models from the terminal, open an external editor for long prompts, inspect logs, approve a tool once or for the rest of a session, and review file changes. Auto-compaction watched context use and summarized a long conversation into a new session at a documented threshold. The TUI exposed a permission dialog instead of quietly giving every interactive request full machine access.
The tool set covered the basics a coding agent needs: file listing and search, text search, reading, writing, patching, diagnostics, shell commands, and fetching web content. LSP integration was honest about its boundary. The client implementation understood more of the protocol, but only diagnostics were exposed to the agent. That is better documentation than implying full language-server intelligence.
Provider coverage was another strength. A developer could configure separate coder, task, and title models, use cloud credentials from several vendors, or point at a local endpoint. The README documented configuration search paths and environment variables in detail. In principle, this let teams change model suppliers without replacing the terminal workflow.
The rough edges are frozen too
The repository's issue history shows why a maintained successor matters. Issue #298 reports that installations from the project's own script could immediately fail because the coder agent was missing. Multiple users reproduced it across Homebrew, npm, macOS, Debian, and NixOS, with configuration workarounds varying by installation method. That report remains open.
Local models were also less dependable than the feature list suggested. Issue #311 says LOCAL_ENDPOINT did not work as expected with Ollama and an OpenAI-compatible server. Comments explain that the client queried a limited set of model-list endpoints, forcing at least one user to put LiteLLM in the middle. Issue #342 reports a configured local model returning no useful action. These were solvable engineering problems in an active project, but they are permanent caveats in an archive.
Credential handling deserves special attention. Issue #343 flags an authentication JSON file stored in plaintext. The report is short, but the concern is specific and the issue is still open. Anyone preserving an old installation should inspect that file, restrict its permissions, rotate credentials after migration, and avoid carrying unused provider tokens forward.
Non-interactive mode has a separate safety tradeoff. The README says all permissions are automatically approved when a prompt is passed on the command line. That is convenient for scripts, but it means a model can reach file and shell tools without the interactive approval screen. Old automation should be reviewed before it runs in a valuable checkout or with broad credentials.
Installation instructions are historical evidence
The README still offers an install script, a Homebrew tap, an Arch package, and go install. Release v0.0.55, published June 27, 2025, includes Linux and macOS archives plus Debian and RPM packages, but no Windows binary. The final functional code commits followed in early July. On July 29, issue #354 announced the new Crush repository, and the September 18 commit added the archive banner.
That chronology matters. GitHub reports a last push in September 2025, but the push did not revive development. The current archive flag, the move notice, and the issue announcement all agree. Likewise, the repository's 158 open count includes issues and pull requests left behind at migration; it is not an active support queue. Stars and GitHub page updates continuing in 2026 do not make the code current.
A legacy user can still download a checksum-covered release and reproduce an old workflow. Doing so may be reasonable for recovering SQLite sessions or checking configuration behavior. It is not a sensible way to begin a new deployment. Model identifiers in the README date from 2025, provider APIs can change, and old package names may now collide with other projects using OpenCode branding.
Migrate, do not reinstall
Existing users should first back up the SQLite database and configuration file, then record custom commands, model mappings, local endpoints, language servers, and MCP servers. Review stored authentication files separately and rotate secrets. Recreate the smallest workflow in Crush before moving valuable repositories, especially any scripted prompt that previously relied on automatic approval.
New users have an easier decision. Choose Crush if you want the direct continuation by the original author. Evaluate anomalyco/opencode if you mean the separate active project now associated with the OpenCode name. Consider Codex or another maintained agent when its provider and permission model fit better.
opencode-ai/opencode is worth preserving as a readable snapshot of how capable terminal agents came together in 2025. It is not worth adopting as living infrastructure. The maintainers have already provided the exit, and users should take it.