IBM Granite 3.3 8B (Ollama) is IBM's general-purpose Granite 3.3 at 4.9GB with a 128K tokens (131,072) context, priced Free (self-hosted). It is not a code specialist. What it is, inside Atlas, is a well-behaved instruction follower that holds long tool transcripts, which makes it a solid Atlas small_model or a general assistant alongside a dedicated coder. Assign it to small_model and Atlas titles, summaries, and subagent chatter run locally and free, while model stays on a coder tag.
What is the Atlas small_model slot and why does Granite 3.3 8B fit it?
The Atlas small_model slot handles titles, summaries, and subagent chatter, and IBM Granite 3.3 8B (Ollama) fits it because reliable structured output and instruction following matter more there than raw code skill. At 4.9GB and Free (self-hosted), it makes those background calls cost nothing.
Every Atlas session generates a stream of small language tasks that are not code generation: naming the session, compacting a transcript, summarizing what a subagent found. Sending those to a metered frontier API is a quiet, constant cost. IBM Granite 3.3 8B absorbs them locally. Assign it to small_model so Atlas titles, summaries, and subagent chatter run locally and free, while model stays on a coder tag. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, and those subagents are the heaviest consumers of the small slot, which is why moving them to a free local model is the single largest cost change available to a local-first Atlas setup.
How much context does IBM Granite 3.3 8B hold?
IBM Granite 3.3 8B (Ollama) holds 128K tokens (131,072) from a 4.9GB download, roughly 7GB to serve, so long-transcript work runs on an 8GB card. That window is the reason it survives in the summarize slot, where a compaction pass has to read a long transcript before it can shorten it.
A summarizer with a short window is nearly useless, because the whole job is reading more than the main model can hold. IBM Granite 3.3 8B at 128K tokens (131,072) can take in a long Atlas tool transcript in one pass. Reliable structured output is the second half of that job: Atlas expects the summary back in a shape it can use, and a model that drifts out of format breaks the pipeline rather than merely degrading it. Granite 3.3's instruction following is the specific reason to prefer it here over a stronger but less obedient model of similar size, and IBM enterprise licensing means it clears the same procurement path as the Granite Code models.
Should IBM Granite 3.3 8B write your diffs?
No. IBM Granite 3.3 8B (Ollama) is a general model, and for actual diff generation an 8B code specialist will beat it. Inside Atlas, keep granite3.3:8b on small_model and leave the main model slot pointed at a coder tag. That split is the intended configuration, not a compromise.
Atlas computes a unified diff for every file edit and surfaces it for approval before writing, which means diff quality is directly visible to you on every turn. A general model will produce more diffs you reject. That wasted round trip is the real cost of misusing IBM Granite 3.3 8B as a builder. Atlas lets you switch the active model and provider on the fly with favorites and recents, so running granite3.3:8b in the small slot while a coder tag holds the main slot takes no ceremony. Both can be local, both can be Free (self-hosted), and the codebase index can run on the Ollama embedder so the small_model and the vector store share the same offline runtime.
How do you configure the Ollama provider for Granite 3.3 in atlas.json?
Declare the ollama provider in atlas.json on @ai-sdk/openai-compatible with baseURL http://localhost:11434/v1, then register granite3.3:8b with limit.context 131072 and limit.output 8192. That is the whole provider setup for IBM Granite 3.3 8B (Ollama), and it is shared by every other Ollama tag you add.
The provider block is written once. After that, adding a model to IBM's Granite line or any other Ollama tag is a matter of adding an entry to the models map with the right limits. For IBM Granite 3.3 8B, pull it with ollama pull granite3.3:8b (4.9GB, aliased to :latest), then assign it to small_model rather than to model. Finally, switch the codebase index to the Ollama embedder so the small_model and the vector store share the same offline runtime, which means an Atlas machine that never calls out for embeddings or for its background language work.
Is there a smaller Granite 3.3 tag worth running?
IBM Granite 3.3 exists at a 2b tag of 1.5GB if you need something smaller than the 4.9GB 8B, but capability drops off sharply. For the Atlas small_model slot the 8B is usually the better trade, since roughly 7GB to serve already fits an 8GB card and the 128K tokens (131,072) window survives.
The reason to be cautious about dropping to the 2b tag is that the Atlas small slot is not a trivial slot. It routes subagent work, produces summaries that the main model later reads, and titles sessions. A summary that is wrong is worse than no summary, because the main model believes it. IBM Granite 3.3 8B at 4.9GB is small enough that the 1.5GB saving rarely changes what hardware you can buy, and the capability difference is not subtle. Reserve the 2b tag for genuinely constrained machines, and prefer granite3.3:8b anywhere an 8GB card is available.
Setup
- 01Pull it: ollama pull granite3.3:8b (4.9GB, aliased to :latest).
- 02Declare the ollama provider in atlas.json on @ai-sdk/openai-compatible with baseURL http://localhost:11434/v1.
- 03Register granite3.3:8b with limit.context 131072 and limit.output 8192.
- 04Assign it to small_model so Atlas titles, summaries, and subagent chatter run locally and free, while model stays on a coder tag.
- 05Switch the codebase index to the Ollama embedder so the small_model and the vector store share the same offline runtime.
Frequently asked questions
- how to set granite 3.3 8b as the atlas small_model
- Run ollama pull granite3.3:8b (4.9GB), register it with limit.context 131072 and limit.output 8192, then assign it to small_model so Atlas titles, summaries, and subagent chatter run locally and free while model stays on a coder tag.
- what is granite 3.3 8b's context window
- IBM Granite 3.3 8B (Ollama) has a 128K tokens (131,072) context from a 4.9GB download, roughly 7GB to serve, so long-transcript work runs on an 8GB card.
- is granite 3.3 good at coding
- IBM Granite 3.3 8B is a general model, not a code specialist. For actual diff generation an 8B code specialist will beat it. Use Granite 3.3 8B in the Atlas small_model slot instead.
- how do i configure the ollama provider in atlas.json
- Declare the ollama provider in atlas.json on @ai-sdk/openai-compatible with baseURL http://localhost:11434/v1, then register granite3.3:8b with limit.context 131072 and limit.output 8192.
- granite 3.3 8b vs 2b for local use
- The Granite 3.3 2b tag exists at 1.5GB if you need something smaller, but capability drops off sharply. Prefer granite3.3:8b at 4.9GB anywhere an 8GB card is available.
- does granite 3.3 8b cost anything to run
- No. IBM Granite 3.3 8B (Ollama) is Free (self-hosted). Assigning it to small_model means Atlas titles, summaries, and subagent chatter cost nothing per token.
- can i use granite 3.3 8b in a regulated enterprise
- IBM Granite 3.3 8B ships under IBM enterprise licensing, so it clears the same procurement path as the Granite Code models, and Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas vs Pieces for Developers: AI Tools for Developers in 2026
Comparing Atlas, a terminal-native AI coding agent, with Pieces for Developers, an OS-level memory layer, for developers in 2026. Evaluate code generation, safety, and context management.
Atlas for TypeScript in 2026
In 2026, TypeScript developers leverage Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas understands your types, ensures code quality, and offers robust safety features.
Atlas vs Sourcery: Terminal AI Coding Agents in 2026
Compare Atlas and Sourcery for 2026. Atlas offers terminal-native AI coding with permission-gated tools and local embeddings. Sourcery provides Python-first LLM review and rules-based refactoring, starting at
Atlas vs Tabnine: Choosing Your Terminal AI Coding Agent in 2026
Comparing Atlas and Tabnine for developers in 2026. Atlas offers a terminal-native AI agent with diff review, while Tabnine provides privacy-first code completion and chat.
Atlas for Quarkus in 2026
Atlas is a terminal-native AI coding agent for Quarkus in 2026. It reads CDI beans and JAX-RS resources, then runs ./mvnw test behind a permission prompt.
Debug a Single Failing Test with Atlas in 2026
How to debug one failing test with Atlas in 2026: run it in isolation with bash, walk the call graph with the lsp tool, and fix the code, not the assertion.
Atlas vs CodeGPT in 2026: A Developer's Guide to Terminal and IDE AI Agents
Comparing Atlas and CodeGPT in 2026 for developers. Atlas offers terminal-native TUI and permission-gated tools, while CodeGPT provides IDE integration and a full repo Knowledge Graph.
Atlas for TensorFlow: Terminal-Native AI Coding for Keras 3 and tf.data in 2026
Atlas is a terminal-native AI coding agent for TensorFlow and Keras 3 in 2026, where tf.function graph tracing and tf.data pipelines are what make training fast.