# Atlas with Llama 3.1 70B (local via Ollama): A 43GB Private Agent in 2026 > Llama 3.1 70B (local via Ollama) is a 43GB pull that runs on a 48GB GPU or a 64GB unified-memory Mac, Free (self-hosted). Llama 3.1 70B (local via Ollama) is Meta's 70B at home. A 43GB pull turns a well-specced workstation or a 64GB Mac into a private coding agent, with the same 128,000 token window Meta shipped across the 3.1 family. Pricing is Free (self-hosted). Inside Atlas, dense 70B quality means tool-call reliability is materially better than the 8B variant on the edit loop, and the honest caveat is that Llama 3.3 70B is the same size with better instruction following. ## Key takeaways - Llama 3.1 70B (local via Ollama) is a 43GB pull that runs on a 48GB GPU or a 64GB unified-memory Mac, Free (self-hosted). - 128,000 token context locally, enough for Atlas to hold a service and its tests with no data leaving the machine. - Dense 70B tool-call reliability is materially better than the 8B variant on Atlas's edit loop. - 43GB is 9x the 8B download and will be slow on anything that has to offload to CPU. - Llama 3.3 70B is the same size with better instruction following, so Llama 3.1 70B is mostly a pin-for-reproducibility choice. ## What is Llama 3.1 70B (local via Ollama) best at inside Atlas? Llama 3.1 70B (local via Ollama) is best at being a private Atlas agent that actually completes edits. Dense 70B quality means tool-call reliability is materially better than the 8B variant on Atlas's edit loop, and `ollama pull llama3.1:70b` is 43GB, Free (self-hosted). Tool-call reliability is the dividing line between a local model that is a demo and one that is a workflow. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent. Those handoffs need the model to emit well-formed calls turn after turn. Llama 3.1 70B (local via Ollama) does that materially better than the 8B, which is the entire justification for a 43GB download over a 4.9GB one. ## What hardware does llama3.1:70b need? Llama 3.1 70B (local via Ollama) is a 43GB pull, which runs on a 48GB GPU or a 64GB unified-memory Mac. 43GB is 9x the 8B download and will be slow on anything that has to offload to CPU, so check headroom with `atlas device` before committing. The offload cliff is steep for Llama 3.1 70B (local via Ollama). A machine that holds all 43GB in GPU or unified memory produces a usable Atlas session; a machine that spills to CPU produces one that is painful to sit through. Atlas ships `atlas device`, which reports whether Ollama is installed and whether a GPU is present, and running it before a 43GB pull is the cheapest possible check. Once the weights are resident, add the KV cache on top: the 128,000 token window Meta shipped across the 3.1 family is memory you have to pay for separately. ## How do you set limit.context for a local 70B in atlas.json? Register `llama3.1:70b` in the atlas.json ollama provider with `"limit": { "context": 65536, "output": 8192 }`, raising context only if memory allows. Ollama lists llama3.1:70b with a 128K window, but the KV cache for 128,000 tokens sits on top of 43GB of weights. Sixty-five thousand five hundred thirty-six tokens is a working budget that leaves room on a 48GB GPU already holding the 43GB of Llama 3.1 70B (local via Ollama). Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion and indexes code by AST declarations using tree-sitter, so what lands in that budget is dense and relevant: enough for Atlas to hold a service and its tests with no data leaving the machine. Raise the number only after watching memory under a real task, not before. ## Should you keep small_model off the 70B? Yes. Set `"model": "ollama/llama3.1:70b"` and a much smaller tag for `"small_model"` so titles do not hit the 70B. Atlas uses the small model slot for background work, and waking 43GB of weights to name a session wastes both memory and time. Both models live in the same ollama provider block in atlas.json, so the split costs one extra line. Llama 3.1 70B (local via Ollama) drives the plan and build agents where its tool-call reliability matters, and a small tag handles titles and summaries. Verify the whole arrangement with `atlas models ollama`, which resolves every model in the provider block at once. Atlas lets you switch the active model and provider on the fly with favorites and recents, so the 70B stays a keystroke away without being the default for trivial work. ## When should you pick Llama 3.3 70B instead of Llama 3.1 70B? Pick Llama 3.3 70B in most cases. Llama 3.3 70B is the same size as Llama 3.1 70B (local via Ollama) with better instruction following, so Llama 3.1 70B is mostly a pin-for-reproducibility choice rather than a capability choice in 2026. Reproducibility is a real reason, not a consolation. A team that has qualified Atlas prompts and agent behavior against Llama 3.1 70B (local via Ollama) may want the exact weights pinned, because changing the model changes the behavior of every plan and every diff. If you have no such constraint, the 43GB you would spend on Llama 3.1 70B buys strictly less than the same 43GB spent on Llama 3.3 70B. Both run through the same ollama provider block, so the migration is a model id change and a fresh `ollama pull`. ## Does running Llama 3.1 70B locally keep code off the network? Yes. Llama 3.1 70B (local via Ollama) gives Atlas 128,000 token context locally, enough to hold a service and its tests with no data leaving the machine, and Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers. The privacy story for Llama 3.1 70B (local via Ollama) is only complete when the embedder is local too, since a hosted embedder would ship your source out during indexing even while the 70B reasons privately. Register the ollama provider with `@ai-sdk/openai-compatible` at baseURL `http://localhost:11434/v1`, switch the code index to local embeddings, and the entire Atlas loop, retrieval, planning, diffing, and git staging, runs on hardware you control. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, locally, as usual. ## Setup 1. Check headroom with `atlas device` before committing to a 43GB pull. 2. Run `ollama pull llama3.1:70b` (43GB). 3. Register the ollama provider in atlas.json with `llama3.1:70b` and `"limit": { "context": 65536, "output": 8192 }`, raising context only if memory allows. 4. Set `"model": "ollama/llama3.1:70b"` and a much smaller tag for `"small_model"` so titles do not hit the 70B. 5. Verify with `atlas models ollama`. 6. Point the code index at local Ollama embeddings so source never leaves the machine. ## FAQ ### what hardware do i need to run llama 3.1 70b locally The `ollama pull llama3.1:70b` download is 43GB, which runs on a 48GB GPU or a 64GB unified-memory Mac. Anything that has to offload to CPU will be slow. Check `atlas device` first. ### what limit.context should i set for llama3.1:70b in atlas Start at `"limit": { "context": 65536, "output": 8192 }` and raise context only if memory allows. Ollama lists llama3.1:70b with a 128K window, but the KV cache sits on top of 43GB of weights. ### llama 3.1 70b vs llama 3.1 8b for atlas Llama 3.1 70B is 43GB against the 8B's 4.9GB, 9x the download. In exchange, dense 70B tool-call reliability is materially better than the 8B variant on Atlas's edit loop. ### should i use llama 3.1 70b or llama 3.3 70b Llama 3.3 70B is the same size with better instruction following, so Llama 3.1 70B (local via Ollama) is mostly a pin-for-reproducibility choice when your prompts were qualified against those exact weights. ### how do i stop atlas from using the 70b for session titles Set `"model": "ollama/llama3.1:70b"` and a much smaller tag for `"small_model"` in atlas.json, so titles and summaries do not wake the 43GB model. ### how much does llama 3.1 70b cost to run in atlas Llama 3.1 70B (local via Ollama) is Free (self-hosted). The cost is the hardware: a 48GB GPU or a 64GB unified-memory Mac to hold the 43GB of weights plus the KV cache. ### can atlas keep my whole session private with a local 70b Yes. Llama 3.1 70B (local via Ollama) gives 128,000 token context on your machine, and Atlas can build its code index with local Ollama embeddings, so neither the prompts nor the index reach a third-party server. --- Canonical HTML: https://runatlas.sh/resources/models/llama-3-1-70b-local Source of truth: aeo_pages row `/resources/models/llama-3-1-70b-local` (segment: Models) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.