ATLAS Local Coding Agent
A local coding agent that plans, verifies, and repairs code with compatible open GGUF models.
- Source repo
- inferstep/ATLAS
- Stars
- ★ 2.1k
- Last updated
- today
- License
- AGPL-3.0
- Primary language
- Python
- FA score
- 66/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free, no paid service needed
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- A solo developer with a consumer GPU who wants a local terminal-based coding assistant inside an existing project directory.
- Not a fit if
- Users without a 16 GB+ VRAM GPU
- Windows-native or Intel Arc users
- Users short on ~20 GB disk or unwilling to run Docker/Podman
- Source review
- 66/100 · Some gaps
What does this agent do, and when should you use it?
ATLAS is a local coding agent that adds planning, candidate generation, quality scoring, sandboxed verification, and repair around a compatible GGUF model. Its primary interface is a Bubbletea terminal UI, launched with atlas from a project directory. The outer atlas-proxy handles tool-call routing, grammar enforcement, complexity tiers, and safety limits, while the V3 Pipeline produces and selects code candidates. Geometric Lens scores candidates from the model's own embeddings, and Sandbox compiles, lints, and tests code in an isolated execution environment. It can be deployed with Docker or Podman and does not require a hosted model or third-party model-provider API key, though ATLAS services authenticate with a local per-installation token.
A user submits a task through atlas-tui or uses /add, /diff, /commit, and /run to supply local file context and invoke shell operations. atlas-proxy classifies file operations by complexity, applies GBNF constraints to expected JSON output, and recovers from malformed or truncated responses. The V3 Pipeline uses PlanSearch, DivSampling, Budget Forcing, PR-CoT Repair, and Refinement Loops to generate candidates and iteratively fix them. Geometric Lens uses C(x) and G(x) to score candidates and write steps. Sandbox executes Python, Rust, Go, C, Shell, and other workloads in isolation, compiling, linting, and running both generated and existing test suites before code is accepted or repaired again.
- A solo developer with a consumer GPU who wants a local terminal-based coding assistant inside an existing project directory.
- An engineer who needs generated changes to be compiled, linted, or tested before deciding whether to accept them.
- A developer working in Python, Rust, Go, C, or Shell who wants generated code checked in an isolated execution environment.
- A local-model operator with an additional GGUF who wants to train Lens artifacts through atlas lens build or retrain.
- An engineer who wants to watch V3 pipeline stages live and manage local changes with /diff and /commit.
How do you install or deploy this agent?
Install after meeting the documented requirements: Python 3.9+, Docker or Podman, and a supported GPU with 16 GB+ VRAM.
curl -fsSL https://raw.githubusercontent.com/itigges22/ATLAS/main/scripts/atlas-bootstrap.sh | bashThe bootstrap script detects the distribution and GPU vendor, installs the appropriate runtime, downloads model weights, builds the ASA steering vector, and starts the stack. To pin V3.1.3:
curl -fsSL https://raw.githubusercontent.com/itigges22/ATLAS/v3.1.3/scripts/atlas-bootstrap.sh | ATLAS_BOOTSTRAP_REF=v3.1.3 bashNVIDIA uses the CUDA path; AMD uses ROCm; Apple Silicon uses the native macOS hybrid Metal path; Vulkan is preview support. No hosted-model or third-party model-provider API key is required, but ATLAS services use a local per-installation token.
How do you use this agent?
From any project directory, start the terminal client:
atlas
Enter coding tasks in atlas-tui. Use /add for local file context, /diff to inspect changes, /commit to create a commit, and /run to execute commands. Chat, !bash, and /slash input modes are available. Sandbox commands have outbound network access by default; disable it with:
ATLAS_SANDBOX_NET_INTERNAL=trueWhat are this agent's strengths and limitations?
- Uses PlanSearch, DivSampling, candidate selection, and repair loops rather than relying on a single code generation.
- Its Sandbox can compile, lint, and run generated and existing tests across Python, Rust, Go, C, Shell, and other workloads.
- Runs compatible local GGUF models across CUDA, ROCm, Metal, and Vulkan paths without hosted-model or third-party model-provider API keys.
- The native Bubbletea TUI exposes a live pipeline view plus /add, /diff, /commit, and /run for local development workflows.
- It requires Docker or Podman, Python 3.9+, model weights, and roughly 20–22 GB of disk; the documented target is a GPU with 16 GB+ VRAM.
- The prebuilt CUDA image targets Blackwell RTX 50xx, so older NVIDIA GPUs need a one-time local rebuild.
- Vulkan is preview and AMD ROCm is community-tested; Intel Arc/SYCL remains on the roadmap.
- Grammar-constrained decoding is reported at about 51 tok/s, and complex features can still be inconsistent in unfamiliar codebases.
- Sandbox commands have outbound network access by default, requiring an explicit setting for environments that need it disabled.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| ATLAS Local Coding Agent This agent | 66 · Some gaps | CLIFree | ★ 2.1k | today | Python | — |
| Codewhale Terminal Coding Agent | 75 · Some gaps | CLIFree + model costs | ★ 41k | 1d ago | Rust | OpenAI API · Claude API |
| AGF Local Coding Session Finder | 96 · Excellent | CLIFree | ★ 162 | 1mo ago | Rust | Codex · Claude Code |
| Maki Coding Agent | 64 · Some gaps | CLIFree + model costs | ★ 1.4k | 1d ago | Rust | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: README explicitly states local operation and no intentional upload of repository or prompts; SECURITY.md details sandbox isolation (read-only rootfs, no-new-privileges, resource limits), sensitive-file exclusion and private-value filtering, and ATLAS_TRUST_MODE trust modes (untrusted refuses command execution, trusted defaults to sandbox execution, fully-trusted allows host execution). Interactive permission prompts and session resume are mentioned in V3.1.3. Rollback mechanism (staged upgrade/rollback with auto-restore) is mentioned in README. Dependency security is addressed via CI workflows like CodeQL, container scan, and signed releases. Deductions: publisher identity is unverified, source attribution relies only on repository metadata; sandbox has outbound network access by default (unless ATLAS_SANDBOX_NET_INTERNAL=true), which may increase external effects risk; user confirmation mechanism details are not shown in provided files.
Evidence shows: README and SECURITY.md describe system architecture, trust modes, and security boundaries consistently; test files (e.g., test_embedding_contract.py) demonstrate regression tests for specific failures, indicating internal consistency. Dependency availability: pyproject.toml declares lower bounds for training dependencies but does not pin exact versions, which may affect reproducibility. Failure messages: tests check error message content (e.g., 'unreadable', 'per_token'), indicating failure message design. Deductions: no complete dependency lock file or SBOM details provided; comprehensiveness of failure messages not fully demonstrated in provided files.
Evidence shows: README identifies target audience (developers, local use), use scenarios (local coding agent), capability boundaries (supported languages, hardware platforms), and trigger conditions (launch via TUI or CLI). Environment fit: supports multiple GPUs and OSes, with SUPPORT_MATRIX.md and SETUP.md documentation. Deductions: specific details of capability boundaries and trigger precision (e.g., tool-call classification, safety limits) are only partially described in provided files, not deep into code.
Evidence shows: README provides clear information architecture (doc links, directory structure), install notes (one-shot install script, manual install path), naming stability (version numbers, component names), examples and FAQ (examples in docs), known limitations (explicitly listed), license (full AGPL-3.0 text), versioning changelog (CHANGELOG.md link), and maintenance responsibility (contributing guide, sponsorship info). Deductions: maintenance responsibility is solely on a single maintainer, no clear update path or community governance details; specific changelog content not shown in provided files.
Evidence shows: README describes output usability (TUI, CLI, structured logs), marginal value (frontier-style reasoning on small models), and cost-benefit (local run, no API fees). Deductions: lack of actual run data or benchmark results to support these claims; cost-benefit analysis not quantified.
Evidence shows: README cites specific benchmarks (LiveCodeBench 74.6%) and methodology docs (V3_ABLATION_STUDY.md), indicating claim traceability. Test files demonstrate regression tests for specific issues, supporting separation of facts and inferences. Deductions: cross-source corroboration is limited, relying mainly on single-repo docs and tests; benchmark results not independently verified in provided files.
- Publisher identity is unverified; source attribution relies only on repository metadata, so caution is advised.
- Sandbox has outbound network access by default, which may increase external effects risk; consider setting ATLAS_SANDBOX_NET_INTERNAL=true to restrict.
- Dependency versions are not pinned, which may affect reproducibility.
- Benchmark results (e.g., LiveCodeBench 74.6%) are not independently verified in provided files; cite with caution.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v3.1.7 V3.1.7 "Maia"
Release notes excerpt
A security release, with installer and build fixes. 3.1.7 fixes four defects with an advisory and several more without one; the advisories are [GHSA-543g-qfqh-q498](https://github.com/inferstep/ATLAS/security/advisories/GHSA-543g-qfqh-q498), [GHSA-f7jr-f255-59p6](https://github.com/inferstep/ATLAS/security/advisories/GHSA-f7jr-f255-59p6), [GHSA-cjfr-rrgx-2g38](https://github.com/inferstep/ATLAS/security/advisories/GHSA-cjfr-rrgx-2g38) and [GHSA-62cf-6h99-6cv9](https://github.com/inferstep/ATLAS/security/advisories/GHSA-62cf-6h99-6cv9). Please upgrade. Security …View on GitHub ↗ -
v3.1.6 V3.1.6 "Maia"
Release notes excerpt
A security release. 3.1.6 fixes a way for a command behind a prefix or a nested shell to skip ATLAS's command policy: [GHSA-m9w4-p32x-chx9](https://github.com/inferstep/ATLAS/security/advisories/GHSA-m9w4-p32x-chx9). Please upgrade. Thanks to @Rendegou, who reported and fixed it. Security - The command policy now looks past command prefixes and checks the command each nested shell, eval or env -S layer would run, up to 16 layers. - A command whose quoting or layers can't be checked completely is refused, with a message saying so. …View on GitHub ↗ -
v3.1.5 V3.1.5 "Maia"
Release notes excerpt
A security release. 3.1.5 fixes a way to skip ATLAS's workspace check with an argument name in another letter case: [GHSA-c3p6-m657-h629](https://github.com/inferstep/ATLAS/security/advisories/GHSA-c3p6-m657-h629). Please upgrade. Security - Tool argument names must now be lowercase, as every tool's names are. A name in another letter case (for example "PATH") or with non-ASCII letters is refused. Before, such a name skipped the workspace check, and in 3.1.4 a "Command" argument also skipped the destructive-command deny-list. …View on GitHub ↗