ZeroChat is a personal learning project about AI clients and agentic execution. The work combines clear goals, decision review, and result validation.
1. Learning to build a chat client
ZeroChat is a personal project for experimenting with models and understanding an AI client's components: profiles, streaming, attachments, storage, context, document retrieval and tools.
The implementation lets these features be tried together, but results depend on the model, provider and computer. It does not replace answer review or specialized development tools.
- Chat: API adaptation, exposed reasoning and vision where supported.
- Documents: text extraction and local lexical search with Orama.
- Tools: browser execution, local backend, MCP and permissions.
- Context: estimates, provider usage data and checkpoints.
- Interface: shared desktop and mobile controls, subject to browser capabilities.
2. Learning to work with coding agents
Development has provided practice in defining tasks, reviewing proposals and checking changes made with agent assistance.
- Limit the objective and decide which behaviour must be preserved.
- Keep rules and contracts close to the code they describe.
- Review and simplify proposals before incorporating them.
- Check changes with applicable tests and manual review where needed.
Tests
The suite checks specific logic, architecture, integration, infrastructure and browser cases. Passing it does not prove universal compatibility or absence of errors.
3. The bitter lesson: rules without tests
After releasing 9.0.0 on 11 October 2026, cleaning up the code took 26 commits in a day and a half; 17 of them are breaking refactors (refactor!). In js/, css/ and py/ alone, about 16,500 lines were removed and 7,600 written, and 83 test files were changed. Apart from an edit_file improvement and a scrolling fix, there was no new functionality: what was removed should never have gone in. The nine commits before the release had already started that cleanup.
What was removed followed a common pattern:
- fallbacks for modules that are always loaded (
window.X || require(...), privatet()wrappers, fallback text after a translation); - guards checking whether an always-present element existed, and compatibility code for old formats and keys;
- functions exported only for tests, and tests that faked elements with plain objects, forcing the code to tolerate incomplete elements;
- literal colours, fallback values in
var()andstyle.displayscattered across the styles; except Exception: passand generic catches in the backend.
None of these changes was absurd on its own: each agent session did something locally reasonable to make its task work. But there was no written rule forbidding it and no test detecting it, so nothing stopped it from piling up. The rules on dead, duplicated and compatibility code, and the first hygiene test (test_code_hygiene.js), arrived on the day 9.0.0 was released; the style and backend ones (test_style_hygiene.js, test_backend_hygiene.js) during the cleanup itself.
What it teaches
- A rule without a test is a wish. An agent reads
AGENTS.mdwhen it suits it; an architecture test always fails. - The rule and its test are written together, with the first case, not when the problem already spans thousands of lines. The sooner, the cheaper.
- Every cleanup leaves its test behind, so the same kind of problem cannot come back without the suite saying so.
- Tests must not ask the code for concessions. Faking the DOM with objects looked convenient but forced fallbacks; with a real DOM they disappeared.
- What cannot be checked by a test is reviewed by hand on every change, and it is stated explicitly that it is not protected.
The 9.1.0 reviews apply this lesson: each AGENTS.md rule is matched with the test that protects it, and rules without a test are flagged as pending.
4. Status and use
ZeroChat is still a personal project. It is published under the MIT licence: anyone may use it, modify it or reuse its parts if they find them useful, without support or warranty.
The current goal of the 10.x series is to use it as the single frontend for local models, served through an OpenAI-compatible API or Ollama; the model changes with the task. Improvements target that use; this help describes what is implemented and does not announce a roadmap.
This help documents current usage.