During this period, I organized the AI workspace I've been using and finally open-sourced it. The project is called Light AI.

At the beginning, I didn't create it because the market lacked a chat interface. On the contrary, there were already many interfaces that could chat with large models. What really bothered me was that chatting was on one website, writing code required opening another terminal, and generating images was a third set of tools; models, accounts, files, and history records were all separate. Every time I switched tools, the context I had just established was interrupted.

What I wanted was a place where I and my small team could use it for a long time: after opening it, I could chat to clarify issues, hand over real tasks to Agents, and generate images directly; all these capabilities shared the same account, navigation, and data boundaries.

So, I created Light AI.

It's not just three functions put together

Light AI currently has three main work areas: conversation, task, and image.

The conversation area supports multiple conversations, streaming replies, Markdown, attachments, sharing, archiving, and exporting, with operating methods that are as familiar as possible. The task area can run Codex, Gemini CLI, and Claude Code, allowing Agents to enter projects, read files, execute commands, and complete modifications. 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 retry and iterate on a task.

But I don't want them to be just three entrances on the sidebar.

I care more about the fact that users don't have to learn three sets of interaction logic repeatedly from "having a vague idea" to "getting a usable result". The three work areas use the same navigation, status feedback, and visual language; the desktop version leaves as much space as possible for content, while the mobile version has a separate drawer, bottom navigation, and touch details, rather than forcing the desktop page into a mobile screen.

These places won't appear in the model capability rankings, but they determine whether a tool will be opened again the next day.

I specially made a few small features that I care about

The first is the task process is visible.

Coding Agents are not just inputting a sentence, waiting for a long time, and finally only receiving a sentence "completed". Light AI will organize the plan, execution process, file changes, and products. Tasks can choose models, inference intensity, Plan mode, and workspace permissions, and can also be classified by project. This way, you can hand over tasks without completely losing control.

The second is long tasks don't occupy the web page.

Conversations, drawing, and Agents may all take a long time to run. I handed these tasks over to independent Workers for processing, and coding tasks will also enter a one-time Docker Runner. Closing the page doesn't mean the task disappears; when you come back, you can still see the status; cancellation, failure, and retry all have clear feedback. Here, I did a lot of small protections, such as task leases and result isolation after cancellation, to avoid an already canceled old request covering up the new state.

The third is making the reasoning process readable.

In addition to ordinary Markdown and code highlighting, the interface can also render Mermaid diagrams. The project also has a separate reasoning visualization entry, hoping to organize the complex analysis process of the model into a more easily followable structure. When the model output is very long, "can generate" is only the first step, and "human can understand" is the real completion.

The fourth is a special entrance: WeChat.

After scanning the code to pair, WeChat messages can be converted into Agent tasks, and the processing results can be returned to the chat. Images, files, videos, and voice messages can also be used as attachments to enter the task workspace. It's not meant to turn WeChat into another chat robot window, but to allow me to hand over tasks to my workspace when I'm away from my computer.

Additionally, I also did unified model management, invitation registration, user permissions, running logs, and usage estimation. Administrators can configure model endpoints and keys centrally, and ordinary users don't need to repeatedly paste API keys in the browser. Keys are encrypted and saved by the server, and coding tasks are run in independent containers with limited resources and capabilities.

Self-hosted, but I don't want to pretend it has no boundaries

Light AI uses Next.js, SQLite, and Docker Compose, which can be run on a Linux host by individuals or small teams. SQLite opens WAL mode, and deployment and backup are relatively straightforward; if you need to support larger scales in the future, it's better to replace the database and task queue with external services.

The Worker for coding Agents needs to access the Docker socket, which means it has high permissions on the host machine. The Runner has CPU, memory, process number, and capability restrictions, but it's not a secure sandbox for unknown users. So, I wrote the boundary clearly in the README: only give Agent permissions to trusted people, and don't expose it directly to the public network without HTTPS, strong passwords, and firewalls.

I've always thought that open-sourcing a project that can run should also include "what it's not suitable for".

Now open-sourced, welcome to polish the details together

Light AI has been used in real environments, but the open-source version is still in the early stages, and the interface and database structure may continue to be adjusted. The repository has prepared Docker deployment documentation, Agent deployment instructions, unit tests, and end-to-end tests based on Mock Provider, which can run validation flows without configuring real model keys.

The project is open-sourced under Apache License 2.0:

GitHub:JimiZhou/light-ai

If you also want to set up your own AI workspace, or are studying how Chat, coding Agents, image generation, and multi-end entrances can be more naturally placed together, you're welcome to try it. If you encounter problems, you can submit issues; if you find that some interactions can be smoother or some deployment processes can be more stable, you're also welcome to submit PRs directly.

Many of my favorite small features were initially just because of a sentence that popped up when I used them: it would be even more convenient if this were a bit more user-friendly here.