AI Coding Agents in a Docker Setup: OpenCode vs. Aider vs. Claude Code in a Real-World Check

|

As a developer and data scientist, you are constantly looking for ways to optimize your own workflow. AI agents that live directly in the terminal and write code are the current holy grail. But how do these tools perform in practice when you want to run them cleanly isolated in Docker containers?

I set up OpenCode, Aider, and Claude Code and tested them in real projects. Here is the unvarnished truth about setup, token consumption, and "writer's strikes."

An important note: I always set up my coding assistants in Docker containers - either in a setup where corresponding dependencies are integrated through a dev-stage, or in a separate standalone container.

---

1. OpenCode: The Structured One

OpenCode offers a very classic approach to setup and feels like a traditional dev tool.

  • The Setup (conf.json): Configuration is done via a simple JSON file. This is clear and easy to handle in version control. However: How the file is structured, what exactly you need to set, and where the file needs to go (ideally just in the root directory) - is relatively difficult to figure out.
  • Docker & Environment: The Dockerfile is easily built. You pull a Python container, pack your linters (e.g., Pylint) and requirements in, and you have a clean base.
  • API Connection: Can be easily connected to OpenRouter via environment variables. Nice is the switch between planning and building as well as switching modells through the process. This could save you a lot of money, especially if you are switch to free modells from openrouter or somewhere else.
  • Conclusion: A solid, well-crafted setup for anyone who likes to control things via JSON and prefers a standard Python environment.

---

2. Claude Code: The "Out-of-the-Box" Guy

Claude Code follows the approach: "Let me handle this, you just lean back."

  • The Setup: Extremely simple. Basically, there is only the Docker container – you jump in and get started. No complex pre-configuration required.
  • Initialization: Claude handles a large part of the setup itself via init.
  • Conclusion: Whether this strong autonomy is always useful remains to be seen (sometimes as a dev you do want full control), but for a quick start, it is unbeatable.

---

3. Aider: The Double-Edged Sword (Deep Dive)

Aider is extremely popular, but in practice, it requires the most babysitting. The setup in Docker is doable, but the devil is in the details.

Setup & Configuration

  • Configuration (.aider.conf.yml): Somewhat more difficult and error-prone than a simple JSON, especially if you want to map paths and models cleanly.
  • Docker & API: The base Dockerfile is simple (just install aider-chat), and here too, the connection runs flexibly via OpenRouter.

What went wrong (The Bad & Ugly)

  • Planning Weakness: Aider often fails at cleanly planning complex, modular structures. The logic is often not maintained consistently across different modules.
  • Model Incompatibility: Many models (even strong ones like MiniMax or DeepSeek) do not understand Aider's specific instructions correctly. This leads to faulty output, or the agent falls into a pure "chat mode".
  • The Writer's Strike: The biggest problem. Aider often does not write changes physically to the files, even though the code was generated correctly in the chat. This forces you to manually copy-paste.
  • Cost Explosion: As soon as you include Markdown files or structured architecture rules in the context, token counts and thus API costs skyrocket.

The Best-Practice Docker Setup for Aider

Anyone who wants to use Aider productively should use a multi-stage architecture to separate the pure app code from the bloated dev setup. Crucial here are the "Keep-Alive" hack and the TTY constraint.

To prevent Aider from dying in exec mode and to ensure Git permissions are correct, the docker-compose.yml needs this trick:

  entrypoint: 
    - sh
    - -c
    - |
      git config --global --add safe.directory /usr/src/app
      tail -f /dev/null


When calling it, an interactive terminal (-it) is strictly required, as Aider otherwise cannot process the write confirmations (y/n):

docker exec -it my-dev-container aider --model openrouter/minimax/minimax-m2.7

Lessons Learned & Workarounds for Aider

  • Model Switching: If a model hallucinates or doesn't write, often the only thing that helps is a hard switch to a specialized coding model (e.g., Qwen-2.5-Coder), which in turn means new context overhead.
  • History Management: Regular /clear is vital for survival to delete "ghost instructions" from the context window.
  • Forcing Edits: If Aider only shows code blocks, sometimes only the explicit command helps: "Apply changes to [filename] now. Do not chat."

---

Conclusion

Those who love control and transparency will reach for OpenCode. Also - in my opninion it is the best way to save a ton of money without setting up local agents - simply use free models from a provider of your choice. Those looking for zero-setup and autonomy will be happy with Claude Code. Personally - the look and feel is simply the best here - but you have to tackle the issues with out-of-tokens and kind of expensive API tokens. Aider is maybe powerful, but requires a clear workflow, strict token discipline, and a robust Docker infrastructure so as not to end in frustration (or a hefty API bill). Furthermore - for my use case - it was almost useless. It seems if you ask e.g. Gemini it will provide Aider as a solution - but i dont think it is a good choice for agentic coding. There are way more sophisticated tools out there!