@code installs a local AI coding workflow on your machine. An internet connection is used for installation and the first model download; after that, the public documentation says it can run offline. Here is the documented workflow and its boundaries.
On macOS, Linux, or WSL, run curl -fsSL https://raw.githubusercontent.com/aslam-anees/at-code/src/install/install.sh | bash. On Windows PowerShell, run Invoke-RestMethod https://raw.githubusercontent.com/aslam-anees/at-code/src/install/install.ps1 | Invoke-Expression. The checksum-verifying installer places the @code CLI and platform helpers in ~/.atcode/bin (or the Windows equivalent), installs the local engine as ~/.atcode/engine/atcode-server, and adds the binary directory to your PATH. Start with @code on POSIX shells or atcode in PowerShell; @ and at are also installed where the shell permits them. See the public install guide for requirements, and review any installer before piping it to a shell.
On first run, @code downloads its local model components to ~/.atcode/model under generic @code filenames such as atcode-model.gguf and atcode-vision.gguf. The repository documents the download at roughly 4.8 GB total and 8 GB RAM as the minimum; it does not publish a universal VRAM requirement. Local performance varies with your hardware and the work you ask it to do.
Start @code from the repository you want to work in, then give it a bounded, reviewable request. Good prompts state the goal, constraints, and how you will validate the result: “Find where login errors are returned, propose a small change to preserve the error code, and show the files you would edit,” or “List the tests that cover this endpoint before changing it.” Keep secrets and production credentials out of prompts. The product site describes repository-aware coding and planning, but the public installation repository does not document a specific indexing algorithm or promise that every file is loaded at once. Treat any context-window figure as a model capability, then verify the tool’s behavior on your own project.
Bounded prompts · Your validation criteriaFor an autonomous coding agent, a safe workflow is plan first, act second, verify last. Ask for a short plan and the expected files before allowing edits. When changes are proposed, inspect the diff, run your project’s formatter, tests, and static checks, and keep normal pull-request review in place. The software runs inference through the local @code engine after setup, so network availability is not needed for that local workflow; however, dependencies, package installs, web requests, MCP servers, and your own build scripts can still use the network. A local model does not remove the need to test generated code or evaluate licenses, security, and deployment impact.
Plan · Diff review · TestBefore committing, read each changed file, run the relevant tests locally, and use version control to retain a clear rollback path. @code’s public README describes a proprietary local tool with no per-token API charges; it does not publish team-license terms, enterprise deployment guides, audit-log behavior, or a benchmark methodology. The site mentions “Flash” and “Super” modes, but their implementation and performance characteristics are not documented in the public install repository, so they should not be relied on as a performance guarantee. For air-gapped deployment, download and validate all required binaries and model files through an approved process before isolating the environment.
Review changes · Test locally · Keep a rollbackLocal AI development carefully shifts some responsibility from a hosted provider to the machine running the tool. Before installing @code, confirm that the machine meets the documented baseline: macOS 12 or later, Windows 10 64-bit or later, or a modern Linux distribution; 8 GB of RAM minimum; and around 4.8 GB of free disk space. The public project provides ARM64 and x86-64 binaries for macOS, Linux/WSL, and Windows. It does not publish a universal GPU, VRAM, throughput, programming-language, or framework support table. Run a small, representative task on the hardware you will actually use, measure latency and memory use, and confirm that your build and test commands complete normally. For teams, decide who can install models, where the model files live, how updates are approved, and how generated changes are reviewed. For regulated or air-gapped environments, document the provenance and checksums of every binary and model artifact, stage them through the organization’s approved software process, and test the fully disconnected workflow before relying on it. This approach keeps the local workflow practical without overstating undocumented capabilities.
Validate hardware · Approve artifacts · Test offline