I have organized and open-sourced a set of AI workstations that I have been using, called Light AI.

The reason for creating it was not because I "lacked a chat page" - there are many chat pages. What bothered me was something else: chatting on one website, writing code on another terminal, and generating images on a third tool. Models, accounts, files, and history records were all separate, and every time I switched tools, the context I had just established was broken.

What I wanted was a place where I could: open it and first clarify the problem through conversation, or hand over real tasks to the Agent, and also create images by hand, all while sharing the same account, navigation, and data boundaries.

Three workspaces, one interaction

Conversation, task, and image.

The conversation area is multi-conversation, streaming reply, Markdown, attachment, sharing, archiving, and exporting, with operation methods that try not to create surprises. The task area can run Codex, Gemini CLI, and Claude Code, allowing the Agent to enter the project, read files, execute commands, and modify code. The image area is connected to the OpenAI compatible interface and the Gemini image model, which can generate images with reference images and can also iterate continuously along a task.

I didn't want them to be just three entrances in the sidebar. So, the three areas share the same navigation, status feedback, and visual language, from "having a vague idea" to "getting a usable result", without having to learn three interactions. The desktop version tries to leave space for content; the mobile version is a separate drawer, bottom navigation, and touch details, not forcing the desktop page into the mobile screen.

Several places I use every day

The task process should be visible. The most frustrating way to use a coding Agent is: input a sentence, wait for a long time, and receive a sentence "completed". Light AI will lay out the plan, execution process, file changes, and products. Tasks can choose models, reasoning intensity, Plan mode, and workspace permissions, and can also be classified by project.

Long tasks are not bound to the web page. Conversations, drawing, and Agents may all take a long time, and these are handed over to independent Workers. Coding tasks are then put into a one-time Docker Runner. Closing the page will not make the task disappear, and when you come back, you can still see the status, with clear feedback for cancellation, failure, and retry. Some protections that seem small but are actually crucial, such as task leases and result isolation after cancellation - otherwise, an old request that has already been cancelled may overwrite the new state.

The reasoning process should be readable. In addition to Markdown and code highlighting, the interface can render Mermaid, and there is a separate entrance for reasoning visualization. When the model output is very long, "being able to generate" is only the first step.

WeChat entrance. After scanning the code to pair, WeChat messages can be converted into Agent tasks, and the processing results will be returned to the chat, with images, files, videos, and voice messages that can be used as attachments in the task workspace. This is not to create another chat robot window, but to allow me to hand over things to my workstation when I leave my computer.

There are also unified model management, invitation registration, user permissions, running logs, and usage estimates. Administrators configure endpoints and keys centrally, and ordinary users do not need to repeatedly paste API keys in the browser. Keys are encrypted and stored on the server, and coding tasks are run in independent containers with limited resources and capabilities.

Self-hosting, and what it's not suitable for

Next.js + SQLite + Docker Compose, which can be run on a Linux machine by an individual or a small team. SQLite has WAL enabled, making deployment and backup straightforward; if you need to support a larger scale, it's more suitable to replace the database and task queue with external services.

One thing needs to be made clear: the coding Agent's Worker needs to access the Docker socket, which means it has high permissions on the host machine. The Runner limits CPU, memory, process number, and capability, but it is not a multi-tenant security sandbox for strangers. So, only give Agent permissions to people you trust, and don't put it on the public network without HTTPS, strong passwords, and firewalls.

Current status

It's already running in my own real environment, but the open-source version is still early, and the interface and database structure may continue to change. The repository contains Docker deployment documentation, Agent deployment instructions, unit tests, and end-to-end tests based on Mock Provider - which can still run through the validation process without configuring real model keys.

Apache License 2.0:

GitHub：JimiZhou/light-ai

If you want to set up your own, you can try it, and if you encounter any problems, you're welcome to submit an issue.