My Agents Do the Work, I Just Press "Allow" 🦥

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

I think I've found the laziest job in software. You give an AI agent a task, go make a cup of cha, come back, read what it changed, and press one button.

The trouble is that the button never lives in the same place. At one point last month I had four coding agents installed, and each of them asked for permission in its own way. Claude Code asks in one terminal. Gemini CLI asks in another. Codex has its own style. More than once I came back with my tea to find that nothing had happened, because an agent had been politely waiting for my approval in a window I'd forgotten about.

So the three of us at HackersHostel built one place where that button always shows up in the same spot.

What I Built

AgentWebUI is a small, self-hosted web page for talking to AI models and command-line coding agents from one place. You run it on your laptop or a home server, open it in the browser, and pick who does the work: a model behind any OpenAI-compatible API, or a coding agent that speaks the Agent Client Protocol (ACP), like Claude Code, Codex, Gemini CLI, OpenCode, Hermes or Pi.

With an agent, you choose the agent, then its model and effort level, then the folder it should work in. After that you mostly watch. It streams the agent's thinking, its plan, the tools it calls and the diffs it makes. When it wants to touch a file, it asks first. You read the diff and press Allow or Deny.

Who gets to be lazier because of it:

• People who use more than one coding agent and are tired of learning each one's commands and approval prompts.
• People who run agents on another machine and don't want to SSH in just to check whether something is stuck waiting for them.
• People who want quick questions answered by a small local model instead of paying for every token.

There are no accounts and no setup wizard. Everything lives in one .env file.

Demo

Live demo: agentwebui.hackershostel.com

Code

HackersHostel / AgentWebUI

The lightest web UI for OpenAI-compatible model APIs and ACP agents.

AgentWebUI

One small web page to chat with AI models and with command-line agents, on your own server. Open it and chat there is no setup screen and no accounts. Everything is configured in .env. The package and command are still named agentwebui-lite.

• Models: any OpenAI-compatible API (OpenAI, OpenRouter, NVIDIA, Groq, Ollama, LM Studio, vLLM, …).
• Agents: anything that speaks the Agent Client Protocol over stdio: Claude Code, Codex, Hermes, Pi, Gemini CLI, OpenCode, … Pick the agent, then its model and effort, then the folder it works in. It streams its thinking, plan, tool calls and diffs, and asks before it acts.

The server is about 3,000 lines of Python with one dependency (aiohttp) and uses about 40 MB of memory. The web client is Preact through htm with no build step. Nothing loads from the internet unless you pick a font other than Geist.

…

View on GitHub

Running it takes four commands:

git clone https://github.com/HackersHostel/AgentWebUI.git
cd AgentWebUI
cp .env.example .env   # add your models and agents
docker compose up -d

If you want it running as a proper service on a VPS or a homelab box, there's also an install script that sets it up with systemd and Caddy for HTTPS.

How I Built It

We already had a bigger version, now called AgentWebUI Pro, that slowly grew into a full control room. For this challenge we went the other way and rebuilt AgentWebUI from scratch as the smallest thing that still does the job. Our rule was simple: anything that adds weight has to earn it.

• Server: about 3,000 lines of Python with one dependency, aiohttp. It sits at roughly 40 MB of memory, so an old laptop or a cheap VPS is plenty.
• Web client: Preact through htm, with no build step. No bundler, no node_modules. Edit a file, refresh the page, done.
• Agents: connected over ACP through stdio. Because ACP is an open protocol, we wrote one client instead of a separate integration per agent. Claude Code and Codex come in through their ACP adapters, and the others plug in the same way.
• Models: anything with an OpenAI-compatible API. On the open-weight side that means Ollama, LM Studio or vLLM on your own hardware. In our setup, Llama 3.2 3B runs locally through Ollama, with open-weight DeepSeek models next to it.
• No outside calls: the page itself loads nothing from the internet unless you switch away from the default font (Geist).

Why Does Open Innovation Matter?

This project couldn't exist in this shape without the open pieces.

• An open protocol is what makes "one UI for every agent" possible. Without ACP, we'd need a custom integration for every agent, and each one would break the next time that agent changed. With it, adding an agent is mostly a line of config.
• Open-weight models make everyday use free. Small questions like "what does this regex do?" go to a local model and cost nothing. The paid subscriptions only get the heavy work.
• It keeps working without internet. Here in Bangladesh, load-shedding takes the router down more often than I'd like, and mobile data isn't always a great backup. With a local model and a page that loads nothing from outside, the chat side keeps going as long as the laptop battery does.
• Your code stays with you. It's self-hosted, with no accounts and nothing phoning home. Agents work in folders on your own machine, not on someone else's server.
• Swapping models is boring, in a good way. A new open model comes out? Edit .env, restart, try it.
• You can read all of it. 3,000 lines is one evening. If you don't like how something behaves, you can change it.

A vendor's own app is usually great for that vendor's agent. The moment you use two agents, you're back to two windows. An open setup is the only way we found to keep everything in one tab that we actually control.

The Lazy Payoff

What changed for me once I started using it day to day:

• I don't open a terminal just to check whether an agent is stuck waiting for me. The request shows up in the browser, with the diff right there.
• I don't have to remember four different ways to approve a file write. There's one Allow button.
• I stopped spending paid tokens on two-second questions. The local model takes those.
• I don't read a fresh setup guide for every new model. It's one line in .env.

The part I like most: I can hand a task to an agent on the home server, close my laptop, and check on it later from a browser on any other device. If it needs me, the approval is waiting in the same place as always.

And the most sloth-like part of all: once .env is filled in, there's nothing left to configure. You open a tab and hand the work over.

What It Doesn't Do (Yet)

We'd rather be upfront about this:

• It's not a fleet manager with dashboards for everything. That's what AgentWebUI Pro is for.
• Agents need to speak ACP, directly or through an adapter.
• Cloud agents like Claude Code and Codex still need an internet connection. The offline part is the local model side.

Want to Help?

There's still a lot to do, and Hacktoberfest is a good excuse to jump in. Support for more agents, better tests, UI polish, accessibility and clearer docs are all on the list. Install it, use it for some real work, and open an issue when something feels off. If you can fix it yourself, even better.

Prize Categories

Entering for the overall prize.

---

Built with @tahrimwalid and @mahmudurrahmanlabib at HackersHostel. They wrote about AgentWebUI from their own angles too, so check out Walid's post and Labib's post.

If something breaks while you try it, the issues tab is open and PRs are very welcome. 🦥