@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 the shell command from the public install guide. On Windows PowerShell, use Invoke-RestMethod https://raw.githubusercontent.com/aslam-anees/at-code/src/install/install.ps1 | Invoke-Expression (PowerShell’s curl alias is not the shell installer). The installer places the at binary in ~/.atcode/bin (or the Windows equivalent), installs the PrismML llama-server build with an upstream fallback, and adds the binary directory to your PATH. Use @ on POSIX shells; PowerShell uses at because a bare @ is reserved syntax. Read the installer before piping it to a shell, as you would with any software installation.
On first run, @code downloads two local files to ~/.atcode/model: @0.1-9b.gguf and @0.1-mmproj.gguf. The repository documents the download at roughly 4.8 GB total. The released model family is @0.1 9B in GGUF format; the public README does not publish a fuller base-model lineage, supported-language matrix, or VRAM requirement. It documents 8 GB RAM as the minimum. This is important planning information: 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 locally through llama.cpp after setup, so network availability is not needed for that local workflow; however, dependencies, package installs, web requests, 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 binaries for Apple Silicon and Intel Macs, AMD64 and ARM64 Linux, and AMD64 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