Aistatine is building on-device AI models for developers who want to create production-ready code locally, without sending their repository to a hosted AI service.
Your code stays on your device. Aistatine runs locally, giving you complete control over your data with no cloud processing or unnecessary data sharing.
Privacy is stronger when it is part of the system design, not a setting hidden behind an account dashboard. @code is installed locally and uses a local model through llama.cpp’s server. After its initial model download, the documented workflow can operate offline. That gives developers a clear boundary: code, prompts, and generated output stay in the development environment they control. It does not remove the need for secure devices, access controls, source-control review, or good software engineering; it gives those practices a local AI workflow to build on.
We believe an AI coding tool should help with the work without making software decisions invisible. A useful workflow starts with a bounded request, turns that request into a reviewable plan and set of edits, and ends with developers running their own tests and reviewing the diff. The goal is not to promise that every output is correct. The goal is to reduce repetitive work while keeping the engineer responsible for architecture, security, behavior, and deployment. Production-ready code comes from that discipline, not from a button.
We publish @code’s installation repository so developers can inspect how the tool is installed and what it downloads. The public guide documents the @0.1 9B GGUF model files, supported operating systems, and baseline hardware requirements: 8 GB RAM minimum and approximately 4.8 GB of free disk space. We will keep improving product documentation as features mature, and we will distinguish documented behavior from plans rather than filling gaps with claims that users cannot verify.
Local development should not mean a weaker developer experience. Our mission is to make on-device AI useful for everyday software work: understanding an existing project, exploring a change, drafting code, reviewing output, and preparing a release. That includes solo developers working on a laptop, startup teams protecting product code, and organizations evaluating offline or controlled environments. We will measure progress by whether the tool is understandable, reliable enough to evaluate, and respectful of the people and codebases that use it.
Trust cannot come from a privacy slogan alone. It comes from clear documentation, honest boundaries, reproducible examples, and a willingness to correct the record when a claim cannot be supported. We will publish technical articles only when they include a named author, date, real examples, and enough methodology for a reader to understand what was tested. We will not use placeholder posts, invented benchmark numbers, or customer claims that cannot be verified. As Aistatine grows, we intend to make the evidence around the product easier to inspect—not harder.