Local-first AI coding cockpit
Principles
ADDOM is being built around a small set of operating rules: state should stay close to the machine, machine-side action should stay visible, and autonomy should stay adjustable.
Operating rules
Projects, threads, artifacts, and continuity should not depend on a remote product surface to remain useful. The desktop app is the core environment, not a thin wrapper around a cloud page.
The product is biased toward explicit approval before risky or consequential actions. That includes file changes, commands, and other machine-side operations.
If the system searched, read, staged, delegated, or executed something, the user should be able to understand what happened and why it happened.
ADDOM is designed around provider flexibility. Remote providers can be used when chosen, but the product direction is not to collapse into one locked model path.
Privacy posture
Closer to the machine
Remote when chosen
If you use a remote provider, model requests leave the local machine according to that provider path and your configuration. The product goal is to keep that boundary explicit instead of pretending it does not exist.
That is why provider choice, approvals, and inspectable execution are tied together in the design.
FAQ
Not as a public-source product today. The current direction is private-first while the product is still being shaped and hardened.
No. Provider choice is part of the product direction. The system is being built to work across multiple provider paths, including local options where appropriate.
Because the product is about real local work: repositories, files, commands, revision control, and explicit machine-side execution.
Yes, in alpha terms. The foundation is serious. The current phase is refinement, hardening, and fit with real workflows.
Bottom line
Local-first state, artifact review, approval before mutation, and adjustable autonomy are not side features. They are the product thesis.