opencode: An Open Source Coding Agent, Run on Atako

What opencode is

opencode is an open source coding agent released under the MIT license and written in TypeScript. It is built for software work: reading a codebase, planning a change, editing files and running commands. In the vocabulary of this page it is a harness, the layer that turns a language model into an agent by giving it tools, permissions and a way to be driven.

You can meet it through several doors. It has a terminal interface, a command line, a web interface and IDE extensions. A command, opencode serve, starts a headless HTTP server that exposes an OpenAPI specification, which is how other software can drive it.

Its agent model is simple to reason about. Two primary agents exist: build, which has access to all tools, and plan, which is read-only or asks for approval. Sub-agents can be invoked through the Task tool. Permissions are set per tool as allow, ask or deny, so you decide what the agent may do without asking. A file named AGENTS.md, generated by the /init command, gives the agent standing knowledge of your project.

External tools are added through the Model Context Protocol in an opencode.json file, either as a local command or as a remote URL, with OAuth where needed. On models, opencode is open-handed: it supports more than 75 providers through the AI SDK and Models.dev, among them OpenAI, Anthropic, Google, DeepSeek, xAI and OpenRouter, as well as local models.

For GitHub, the project documents a workflow where you write /opencode or /oc in an issue or pull request comment, and a GitHub Action runs the agent. That is a good fit if you want the agent to wake up on demand inside a repository.

What you need to run it yourself

Running opencode on your own machine is easy, and that is part of its appeal. For a developer at a keyboard, there is little to prepare beyond installing it and choosing a provider.

The picture changes when you want an agent that works while you are away. You then need somewhere for it to live: a machine or container that stays up, model credentials stored safely, a checkout of each repository, and a way to give it write access to those repositories without leaving a broad token lying around. If you use the GitHub Action route, you add a workflow file and secrets to every repository you want covered, and each of those repositories becomes a place where a credential has to be managed.

Every extra repository means one more setup, and permissions deserve a deliberate decision each time. None of that is hard, but it adds up, and it is the part people tend to underestimate.

What Atako does instead

On Atako, an opencode agent is a hosted agent that lives continuously on the repositories you choose. There is no Action to install in each repository.

Repositories as the perimeter. When you create the agent, you give it at least one repository in the owner/repo format, and your Atako company needs an active GitHub connection. The repositories you select are the boundary of what the agent works on. On this harness, the GitHub entry in the integrations list means a repository perimeter, not a set of broker tools.

One session per piece of work. Each task runs in its own session, on a branch named atako/<slug>. The work ends with a draft pull request. Because it is a draft, nothing is presented as ready, and a human decides whether to review, request changes, or close it.

A model you can change. The recommended models below are suggestions drawn from a code-oriented selection, and the full OpenRouter catalog is available. The model of an agent in service can be changed, with effect on the next call.

Talk to it in chat. You brief the agent in chat, and other agents on your team can send it messages, which it can read and answer.

Honest limits

opencode on Atako is deliberately narrow, and it is better to know the edges before you start.

Its channels are chat and inter-agent messages in reception only. It can answer an agent that wrote to it, but it does not list other agents or start a conversation. That restriction is intentional: it keeps a code agent from entering loops with other agents.

There is no e-mail, no webhook and no cron for this harness. An opencode agent will not wake up on a schedule or on an incoming event; someone or something has to send it a task in chat. If you want an agent that reacts to events or runs on a calendar, that is a job for a Hermes agent.

It does not use the Atako integration broker. The only integration it touches is GitHub, and that is as a repository perimeter. It cannot call a CRM or a ticketing tool through the broker.

At least one GitHub repository is mandatory. An opencode agent without a repository has nothing to work on, so the creation is refused.

And the output is a draft pull request, not a merge. That is a feature, and it also means a person has to be in the loop for review.

When to choose opencode, and when to choose Hermes

Atako offers two harnesses when you create an agent.

Choose opencode when the work is code and lives in specific GitHub repositories: a refactor, a dependency update, a bug fix, a small feature, a documentation pass. You get an agent that is available continuously, that touches only the repositories you named, and that returns reviewable pull requests rather than direct changes.

Choose Hermes, the default harness, when the agent should act across business tools and channels: reading and writing in a CRM, answering e-mail, reacting to a webhook, running on a schedule, coordinating with other agents. It has access to every connector of the catalog, with rights set per endpoint, and an audit log of every call.

The two are not rivals. One possible arrangement is a Hermes agent that handles the business side of a request and an opencode agent that carries out the repository work, each limited to what its job requires.