Running AI agents on servers makes sense to me when you’re working on several tasks in parallel, because it separates their environments and takes that load off your computer. MonkeyCode organizes that work through a central dashboard: each task has a remote environment with its own resources, files, and terminal. I can see the appeal for developers and teams who need to keep several jobs running without putting everything on one machine.
In my test, the hosted version built an interface for visualizing Docker Compose files and then modified it following another instruction. I also installed the dashboard on my own VPS, although that second part stopped short of running tasks: I still needed to add a worker host. That distinction determines what you need to set up and what you’ll pay for.
What changes when you run agents off your computer
I use various coding agents, including Claude Code, Codex, and OpenCode. As terminals and tasks pile up, keeping track of what each one is doing starts getting complicated. Then there’s the CPU and RAM needed for the work they run on your machine.
MonkeyCode moves the execution environment to a remote server. From the dashboard, you can review the files the agent has modified, open a terminal, and continue the task. The work stays tied to that environment, with its own resources.
The benefit I’m interested in is separation between tasks. If you’re working on different projects, you can keep their files and processes in separate environments. In a team, that approach also helps centralize configuration without forcing everyone to work in the same space.
This addresses a different question from dividing responsibilities between agents. In MiniMax Code and the leap from using one agent to building a team, I explain the separation between whoever implements and whoever verifies. Here, the question is where each job runs and what resources it uses.
What worked in my MonkeyCode test
I asked for a simple frontend where I could paste a Docker Compose file to see its services in a structured view. I wanted to avoid going through the entire file to find databases, variables, and other components.
The agent generated the application and opened a preview hosted on a MonkeyCode domain. I pasted in a Compose file from the project itself, and the interface displayed its services, including a database, Redis, and ClickHouse, along with the environment variables. For the scope I’d asked for, it did a pretty good job.
Then I asked it to add useful warnings for the developer. The agent modified the application, and the warnings appeared. You can see the test result, which I left published.
There’s a distinction I’d keep in mind when using that application: the fact that the agent generates a warning shows that it has implemented the feature. The severity it assigns to each warning needs reviewing. In the test, some warnings were marked as critical, and I pointed out myself that those judgments would need checking.
I also had access to the environment’s files and terminal. I find that more useful than just having a preview: you can inspect the work and keep iterating on it.
What I ran was one task followed by one iteration. The free account I used allowed only one concurrent task, so testing how several environments behave when working at once was outside the scope of my test.
Which limits matter more than the token allowance
In the video published on September 4, 2026, the dashboard showed these plans. These are the terms I showed at the time:
| Plan | Displayed price | Concurrent tasks | Environment resources | Daily allowance |
|---|---|---|---|---|
| Free | Free | 1 | 1 core and 4 GB of RAM | 10 million tokens |
| Pro | $15 | 3 | 2 cores and 8 GB of RAM | 100 million tokens |
| Ultra | $60 | — | — | 300 million tokens |
For this use case, I’d look at concurrent tasks first. You can have a huge token allowance and still be limited to one active job. If you want to run several agents at once, that restriction matters more than the big number on the plan.
Usage isn’t just about what you type in the chat, either. An initial task where I’d written “hello” had already consumed around 74,000 tokens. My impression was that startup and internal instructions accounted for much of that usage, although I didn’t check the breakdown.
After creating the application and iterating on it, I’d used just over a million tokens. The dashboard also listed credits for features such as searches, image recognition, document processing, and tool calls separately. Before choosing a plan, check which allowance the kind of work you’re requesting draws from.
Self-hosting needs a dashboard, models, and worker hosts
MonkeyCode is open source and has a public GitHub repository. To test the installation, I chose a Hetzner VPS, connected over SSH, and ran the installer specified in the project. The process installed Docker and asked me for the administrator details.
Then I used OpenCode to configure Traefik and expose the dashboard through a subdomain. I pointed the subdomain to the server’s IP in Cloudflare and was able to access the MonkeyCode interface from my browser.
But having the dashboard installed was only part of the setup. When I launched a task, MonkeyCode told me no hosts had been added. The server I’d just prepared hosted the central management interface; I still needed to register the servers where the work would run.
I decided to stop there because I didn’t want to pay for another VPS for that test. Installing the dashboard and accessing it through a domain worked, but I didn’t get as far as running a task on my own deployment.
The architecture separates several pieces: the dashboard centralizes configuration, the AI provider supplies the models, and the hosts run the tasks. The settings also include repositories, environment images, skills, and MCPs. If you need to understand what that last connection adds, you’ll find an explanation in what MCP servers are.
The objection: you’re trading local load for infrastructure
The most reasonable objection is that moving agents off your PC adds servers and configuration. My self-hosting attempt makes that pretty clear: I could access the dashboard and configure a model provider, yet I was still missing the machine that would run the task.
That’s why, for me, the hosted version is the sensible starting point if you want to test the workflow before managing infrastructure. Self-hosting is a better fit when you want control over that installation and are willing to maintain its components.
You also need to sort out inference. The self-hosted installation didn’t include the hosted service’s model allowance, so I configured an external provider. In the test, I used Hetzner’s experimental inference service and got useful responses, although it was slow at times.
A word of caution: I didn’t encounter a usage limit during my tests, but that doesn’t prove the service is unlimited. Before choosing it as your regular provider, check its terms and whether its speed works for the tasks you want to run.
When I’d keep working locally
I’d keep the work on my computer if I’m running a single task, the machine handles it well, and managing its processes doesn’t bother me. In that situation, setting up a dashboard and adding hosts introduces operational work without addressing a specific need.
I’d consider moving to servers when I need several independent jobs, my computer can’t keep up, or I want to share a central configuration with other developers. The deciding factor is the bottleneck you’re removing: local resources, mixed environments, or team management.
To test it, go to MonkeyCode and bring a small task from a project you know. Review the files, open its terminal, and ask for a modification; then decide whether you need more concurrency or your local setup already handles that work.
What do you think?
Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .