Running lac-cli Fully Offline with Ollama

Why I Started Caring About Offline Mode

API costs add up fast when you're using an AI shell all day. I'm not talking about huge bills — but when you're iterating quickly, running lac shell for a dozen commands, asking lac agent to refactor a module, and bouncing between tasks, the tokens accumulate. There's also the privacy angle: sometimes I'm working on client code that I'd rather not send to any third-party server, period.

The fix turned out to be simpler than I expected. lac-cli supports Ollama as a first-class provider. That means lac shell, lac agent, and lac mind all work locally — no API key, no cloud, no data leaving your machine.

What You Need Before Starting

Two things: lac-cli installed, and Ollama running. That's it.

Install lac-cli if you haven't yet:

pip install lac-cli

Or use the one-liner:

curl -fsSL https://lacai.io/install.sh | bash

Then install Ollama from ollama.com and pull a model. I use llama3 for general work and codellama when I need something that actually understands code structure:

ollama pull llama3
ollama pull codellama

Start the Ollama server:

ollama serve

It runs on http://localhost:11434 by default. Keep that terminal open or set Ollama to run as a background service — both work fine.

Pointing lac-cli at Ollama

Run the setup wizard:

lac shell --setup

It walks you through picking a provider. Select ollama, then enter the model name you pulled (llama3, codellama, whatever you have). The config gets saved to ~/.lac/config.json so you only do this once.

If you want to switch to offline mode for a single session without touching your saved config:

lac shell --offline

The --offline flag tells lac-cli to skip any cloud provider and go straight to your local Ollama instance. Useful when you're on a plane or somewhere without reliable internet and just want things to work.

Using lac shell Offline

Once configured, lac shell behaves exactly the same as it does with Claude or GPT. You type plain English, it shows you the command with ghost text, you hit Tab to accept and Enter to run. The only difference is that the inference is happening on your own hardware.

Something like:

> find all Python files modified in the last 7 days and count them

Gets resolved to:

find . -name "*.py" -mtime -7 | wc -l

Response time depends on your machine. On an M2 MacBook Pro with llama3, I get answers in about two seconds — fast enough that I don't notice much difference from the cloud providers for short prompts. Longer, more complex requests take a bit more time, but it's not painful.

lac agent Works the Same Way

This is the part that surprised me most. lac agent — the agentic coding assistant that reads and writes files, tracks project memory in .lac-memory.json, handles undo/redo, and runs in PlanMode — it all works with Ollama too.

Start it normally:

lac agent

If your config already points to Ollama, it picks that up automatically. You get the full feature set: file edits with diff previews, undo with /undo, PlanMode before touching anything, HTTP request running. All local.

I'll be honest — for complex multi-file refactoring, codellama is noticeably better than llama3. The code-focused model handles context windows and reasoning about file structure better. Worth pulling both and switching based on the task.

What About lac mind?

lac mind — the multi-model debate engine — also works offline, but with a catch: to have models debate each other, you need at least two different models pulled locally. You can run something like llama3 vs mistral and watch them argue through your problem. It opens the local web interface the same way it does with cloud providers.

That said, the debate format really shines when the models have meaningfully different strengths. Mixing a code-focused model with a general reasoning model gives you more interesting output than two similar models echoing each other.

The Config File Is Just JSON

If you want to manually edit your provider setup or keep multiple configs around, ~/.lac/config.json is plain JSON. Nothing complicated. You can version-control it, copy it between machines, or just inspect it when something feels off.

A minimal Ollama config looks roughly like:

{
  "provider": "ollama",
  "model": "codellama",
  "base_url": "http://localhost:11434"
}

If you're running Ollama on a different machine on your local network (say, a home server with a beefier GPU), just point base_url at that machine's IP. lac-cli doesn't care whether Ollama is running locally or on another box — it just needs the endpoint to be reachable.

When to Use Offline vs Cloud

I don't think of offline mode as a fallback. It's a deliberate choice depending on what I'm doing:

• Client or proprietary code: Ollama every time. Nothing leaves the machine.
• Air-gapped or low-connectivity environments: lac shell --offline and move on.
• Prototyping or exploration: Cloud providers are faster and more capable right now for complex reasoning. I use Claude or GPT here.
• High-volume repetitive tasks: Ollama. Running the same kind of transform or query a hundred times with a local model costs nothing extra.

Having the choice baked into the tool — not bolted on as an afterthought — is what makes this actually usable. You don't need a different tool for offline work. It's all just lac-cli.

One Practical Tip to Leave You With

Set up a shell alias so switching modes takes zero thought:

alias lacoff="lac shell --offline"

Then when you need to drop offline fast, it's just lacoff and you're in. Combine that with Ollama set to auto-start on login and you've got a fully local AI shell that's always ready without any extra steps.

If you haven't tried the offline mode yet, pull codellama and give lac agent a spin on a project you'd normally hesitate to send to a cloud API. You might just leave it set to Ollama by default.