Terminal CLI Tools for AI Developers [2026 Setup Guide]

Originally published at kunalganglani.com — read it there for inline code, hero image, and live links.

Terminal CLI tools for AI developers are the shell programs, agentic coding agents, local inference wrappers, and prompt management utilities that turn a blank terminal into a production-ready AI development environment.

Ollama just raised $88 million and serves 8.9 million developers. OpenCode crossed 185,000 GitHub stars. A Systima study proved Claude Code sends 4.7x more token overhead than OpenCode. And a single command — ollama launch — now bootstraps your entire AI coding environment in one shot. If your terminal CLI tools setup for AI development looks the same as it did a year ago, you're burning money and moving slower than you need to.

Key Takeaways

• One command bootstraps everything: ollama launch claude or ollama launch opencode configures and launches agentic coding tools with local or cloud models. No env vars, no config files.
• Claude Code sends ~33,000 tokens of overhead before your prompt arrives; OpenCode sends ~7,000 — a 4.7x gap that compounds with MCP servers, instruction files, and subagents.
• Ollama 0.31 on Apple Silicon with MLX delivers up to 90% faster inference for coding agents versus prior versions, as measured on the Aider polyglot benchmark.
• Fish shell 4.8 (Rust rewrite) and Nushell are the two shells worth evaluating if your AI workflow pipes JSON between tools. Zsh still wins for plugin ecosystem depth.
• Simon Willison's llm CLI is the missing prompt management layer — it stores every prompt and response in SQLite, supports reusable templates, and works with 75+ model providers.

Token overhead is the new technical debt: invisible until the bill arrives.

The 2026 AI Developer CLI Stack at a Glance

Here's what a complete terminal CLI tools setup for AI developers looks like in mid-2026:

Layer	Tool	Use Case	GitHub Stars	Cost Model
Shell	fish 4.8 / nushell / zsh	Daily terminal environment	—	Free
Agentic Coding	OpenCode	Multi-file AI coding agent	185K	Free (bring your own API key)
Agentic Coding	Claude Code	Anthropic's first-party agent	—	Subscription or API
Agentic Coding	Aider	Git-aware pair programming	44K	Free (bring your own API key)
Quick Query	llm (Simon Willison)	One-off prompts + logging	12.2K	Free
Quick Query	ShellGPT (sgpt)	Inline shell suggestions	12.2K	Free
Local Inference	Ollama	Model management + serving	—	Free + cloud tier
Raw Inference	llama.cpp	Direct CLI control	120K	Free
Prompt Mgmt	llm templates	Reusable prompt patterns	(same)	Free
Key Mgmt	direnv / .env + gitignore	API key isolation	—	Free
Glue Layer	Dotfiles repo	Reproducible setup	—	Free

Every tool on this list has real adoption numbers and solves a specific problem. No aspirational picks, no "this might be interesting someday" entries. The rest of this guide walks through each layer.

Shell Setup: zsh vs fish vs nushell for AI Workflows

Your shell is the foundation everything else sits on. For AI coding workflows in 2026, three shells are worth your time.

zsh is still the macOS default and the most battle-tested option. Its plugin ecosystem (oh-my-zsh, zinit) is unmatched, and every tutorial assumes you're running it. If you pipe LLM outputs through jq and don't think twice, zsh works fine.

fish 4.8.0 (released June 24, 2026) is the sleeper pick. The 4.x series was rewritten in Rust, so startup is noticeably faster. Autosuggestions, syntax highlighting, tab completions — all there out of the box. Zero config. For developers who want productivity without maintaining a 200-line .zshrc, fish is the answer. The native abbreviation system is particularly good for AI workflows: abbr --add oc 'opencode' fires instantly.

Nushell is the opinionated choice. It treats all data as structured types — JSON, YAML, CSV, SQLite — instead of raw strings. When your AI workflow constantly pipes JSON between tools (which it does now, constantly), nushell eliminates the brittle grep | sed | awk chains that break the moment a model changes its output format. If you've ever had jq silently swallow a malformed JSON response from an LLM, nushell's typed pipelines catch that at parse time.

My recommendation: Fish 4.8 for most AI developers. Nushell if you're doing heavy data pipeline work in the terminal. Zsh if you're already invested in a plugin setup that works. The shell honestly matters less than having your AI tools properly configured inside it.

Agentic Coding Tools: Aider vs OpenCode vs Claude Code

This is the layer most developers actually care about, and 2026 gave us three genuinely different options for terminal-first agentic AI coding.

Aider (44K stars, 6.8M installs) is the veteran. Created by Paul Gauthier, it maps your entire codebase into context, auto-commits with sensible git messages, and supports 100+ languages. It processes 15 billion tokens per week across its user base. Aider's polyglot benchmark — 225 Exercism exercises across six languages — is the closest thing the community has to a standard eval for coding agents. Current top score: 88.0% using gpt-5 (high) at $29.08 per run. Aider is best when you want full visibility into every change and a git-integrated workflow where nothing happens behind your back.

OpenCode (185K stars, 7.5M monthly developers) is the scale story. Built by Anomaly Brand, it supports LSP loading, multi-session parallel agents, and 75+ LLM providers through Models.dev. Open source, stores no code or context data, installs in one line. OpenCode shines for teams that want provider flexibility — you can point it at a local LLM through Ollama just as easily as Claude or GPT.

Claude Code is Anthropic's first-party terminal agent. It works across macOS, Linux, and Windows, integrates with VS Code and JetBrains, and supports routines (scheduled tasks like weekly dependency audits) and pinned sessions. The deep Anthropic integration means it leverages Claude's strengths well. The tradeoff is token overhead. And it's not small.

When to use which

• Aider for solo developers who want git-native AI pair programming with full change visibility
• OpenCode for teams or cost-conscious developers who need provider flexibility and lower token overhead
• Claude Code for developers already in the Anthropic ecosystem who value deep IDE integration and can stomach the cost premium

I've written more on the specifics in my Aider vs Claude Code comparison and free Claude Code alternatives roundup.

Token Cost Reality: Why OpenCode Sends 4.7x Fewer Tokens Than Claude Code

The Systima Applied Research Team published these numbers on July 12, 2026. The Hacker News thread hit 439 upvotes in a single day. Here's why people were upset.

Both tools pointed at the same model (Sonnet 4.5), same machine, same task. Claude Code sent approximately 33,000 tokens of system prompt, tool schemas, and injected scaffolding before the user's prompt even arrived. OpenCode sent approximately 7,000. That's 4.7x more overhead just to get started.

On Claude Fable 5, the gap narrowed to about 3.3x because Claude Code sends newer models a smaller system prompt. Still substantial.

But here's the thing nobody's saying about the real cost killer: cache behavior. OpenCode's request prefix was byte-identical in every run — it paid to cache its payload once per session and read it back cheaply. Claude Code rewrote tens of thousands of prompt-cache tokens mid-session and wrote up to 54x more cache tokens than OpenCode on the same task. Cache writes are billed at a premium. This is why your usage dashboard climbs faster with Claude Code even when the per-token rate looks reasonable.

Then come the multipliers. MCP servers, CLAUDE.md instruction files, framework templates, subagents, extended thinking — all compounding Claude Code's overhead further. From maintaining the LLM pricing data at kunalganglani.com/llm-prices, I can tell you that per-token cost comparisons mislead without cache-hit and retry assumptions. That 4.7x overhead translates into real dollars fast, especially on teams running dozens of sessions per day. Lorenzo Gentile at Ploy found that even switching providers for their production agent (Claude Opus 4.8 to GPT-5.6) cut costs 27% while halving wall-clock time — but required fixing eval harness, tool schemas, caching logic, and reasoning replay. All provider-specific behaviors.

The lesson: LLM cost optimization isn't about picking the cheapest model. It's about understanding what your tooling sends on your behalf.

Setting Up Ollama for Local Inference (Including ollama launch)

Ollama is the gravity well of local AI inference in 2026. 8.9 million developers. $88 million in fresh funding (announced July 9, 2026). And the latest versions are genuinely fast.

What is ollama launch and how does it work?

ollama launch shipped in Ollama v0.15+ (January 23, 2026) and does something that should have existed years ago: it bootstraps Claude Code, OpenCode, or Codex with local or cloud models. No environment variables. No config files.

Three steps:

1. Download Ollama v0.15+ from ollama.com
2. Pull a model: ollama pull glm-4.7-flash (local, ~23 GB VRAM with 64,000 token context) or ollama pull glm-4.7:cloud for the cloud variant
3. Launch: ollama launch claude or ollama launch opencode

The command guides you through model selection and launches your chosen integration. No ANTHROPIC_API_KEY exports, no config.yaml files, no debugging why OLLAMA_HOST isn't being picked up. It just works.

Recommended local models for coding agents as of mid-2026: glm-4.7-flash, qwen3-coder, and gpt-oss:20b. Cloud alternatives: glm-4.7:cloud, minimax-m2.1:cloud, and qwen3-coder:480b-cloud. Ollama also extended its free-tier coding session window to 5 hours with this update.

For configuration without immediate launch, use ollama launch opencode --config.

Apple Silicon vs Linux: MLX, CUDA, and Local Inference Performance

Ollama 0.31 (June 2026) delivers up to 90% faster coding-agent inference on Apple Silicon via MLX multi-token prediction, benchmarked using the Aider polyglot benchmark. This is the single biggest performance jump Ollama has shipped.

From running the benchmarks I maintain at kunalganglani.com/llm-benchmarks, I've learned something counterintuitive: unified memory changes the VRAM-is-the-limit intuition. Big models load on Apple Silicon machines that would choke an equivalent NVIDIA card. But throughput is the real trade. A Mac Studio M4 Max loads a 70B model that needs a $1,600 RTX 4090 on the NVIDIA side, but the 4090 generates tokens faster at that model size.

On Linux with CUDA, Ollama 0.30 improved GGUF compatibility through llama.cpp (120K GitHub stars), broadening hardware support to AMD ROCm and older NVIDIA cards. If you're on a Linux workstation with a dedicated GPU, the CUDA path still wins on raw throughput per dollar. If you're on a MacBook, the MLX engine in 0.31 made local coding agents genuinely usable for the first time.

For deeper hardware comparisons: my local LLM hardware guide and the Mac Studio vs RTX 4090 PC breakdown.

llama.cpp Direct CLI: Flags That Matter for AI Developers

Ollama is an abstraction over llama.cpp, created by Georgi Gerganov. When Ollama's defaults aren't enough — when you need specific quantization behavior, precise context control, or you're benchmarking — you go to llama.cpp directly.

The flags that matter:

• --ctx-size (-c): Context window in tokens. Default is usually 512, which is laughably small for any real coding task. Set this to at least 8192. Ideally 32768 or 64000 if your VRAM allows.
• --threads (-t): CPU threads for prompt processing. Match this to your physical core count, not logical threads. On an M4 Pro, that's 12.
• --gpu-layers (-ngl): Layers to offload to GPU. Set to 999 to offload everything if your VRAM fits the model. Partial offload is where performance falls off a cliff.
• --batch-size (-b): Prompt processing batch size. Higher values (512-2048) improve prompt ingestion speed at the cost of memory.

For most AI developers, Ollama handles these defaults well enough. You reach for llama.cpp directly when you need reproducible benchmark conditions or hardware-specific tuning that Ollama's abstraction layer doesn't expose. From maintaining the benchmark database at kunalganglani.com/llm-benchmarks, I've seen firsthand that quantization quality cliffs are model-family-specific. A blanket Q4 recommendation is wrong, and proving that requires llama.cpp's direct flag control.

Prompt Management CLIs: Simon Willison's llm Tool and Templates

Between the big agentic coding tools and the raw shell, there's a gap that nobody talks about enough: prompt management. Simon Willison — co-creator of Django and creator of Datasette — built the llm CLI to fill exactly this gap.

llm has 12,200 GitHub stars. Here's what it does well:

SQLite logging. Every prompt you run and every response you get goes into a local SQLite database. This sounds boring until you realize you can query your entire prompt history with SQL. Six months of "what did I ask that model about the auth flow?" answered instantly.

Templates. Reusable prompt patterns stored as named templates. Instead of retyping your code review prompt or your commit message generator, define it once, call it by name. Prompt engineering made practical, not theoretical.

Fragments. Attach files, URLs, or text snippets as context. cat myfile.py | llm -s "Explain this code" is the simplest form, but fragments let you build richer context windows.

Universal provider support. Works with OpenAI, Anthropic, Gemini, Llama, and dozens more via plugins. llm install llm-ollama adds local model support.

The llm CLI is the best tool I've found for the 80% of AI terminal work that isn't agentic coding. Quick questions, "summarize this error log," "rewrite this commit message." It complements Aider/OpenCode/Claude Code rather than competing with them.

Quick-Query Tools: ShellGPT for One-Off Terminal LLM Use

ShellGPT (sgpt) is the other 12.2K-star tool in this space, and it solves a different problem than llm. Where Willison's tool emphasizes logging and templates, sgpt is optimized for inline shell integration.

The core use case: you're in the middle of something, you need a quick shell command suggestion, and you don't want to context-switch to a browser or spin up a full agentic session. sgpt drops the answer right into your terminal.

It supports chat mode for multi-turn conversations and direct code generation. Think of it as asking a colleague "what's the find flag for files modified in the last hour?" — except the colleague actually remembers every flag.

The practical split for AI developers: sgpt for instant shell productivity. llm for logged and templated prompt workflows. Aider/OpenCode/Claude Code for multi-file agentic coding. Each tool earns its place by solving a distinct problem at a distinct scope. Check the full developer tools overview for how these layers fit together.

API Key Management and Security in the Terminal

Every tool in this stack needs API keys. Anthropic, OpenAI, Google, Ollama cloud — the key count adds up fast. And every key that leaks into your shell history or a committed .env file is a security incident waiting to happen. As I covered in the AI security guide, credential leakage is one of the most common and most preventable AI security failures.

Here's the setup that actually works:

Use direnv for project-scoped keys. Drop a .envrc file in your project directory with your API key exports. direnv loads them when you cd into the directory and unloads them when you leave. Your keys never touch your global shell config or history.

Never export keys in .bashrc/.zshrc/config.fish. These files get committed to dotfiles repos, shared in pair programming sessions, backed up to cloud services. A leaked ANTHROPIC_API_KEY in a public dotfiles repo? Depressingly common.

Add HISTIGNORE patterns. In zsh: HISTIGNORE="*API_KEY*:*SECRET*:*TOKEN*" prevents key-containing commands from being saved to shell history. In fish: set -g fish_history_ignore "*API_KEY*".

Use built-in key storage when available. Both llm (llm keys set openai) and Ollama store keys in their own config directories, not in shell environment. Claude Code handles key management through its own auth flow.

Rotate keys. Most providers support multiple active keys. Create project-specific keys and rotate them monthly. If a key leaks, you revoke one key, not your entire API access.

Dotfiles: The Repo That Ties the Whole Stack Together

Every tool above generates configuration. Aliases, environment settings, shell functions, tool configs. Without a dotfiles repo, you're rebuilding from memory every time you touch a new machine. I've been through that enough times to know it's a terrible use of a morning.

Here's what a 2026 AI developer dotfiles repo should include:

Shell aliases for daily AI workflows. In fish or zsh:

• Alias oc to opencode
• Alias a to aider --model sonnet-4.5
• Alias q to llm for quick queries
• Alias lp to ollama pull for fast model downloads

Model-switching shell functions. A function that takes a model name and reconfigures your default agentic tool:

modelswitch sonnet → sets ANTHROPIC_MODEL=claude-sonnet-4.5 and restarts your agent session. modelswitch local → switches to Ollama with glm-4.7-flash.

An .envrc.template file. A template with placeholder values for every key your stack needs, committed to the repo. The actual .envrc with real values stays in .gitignore.

llm templates for common tasks. Export your llm template directory into the dotfiles repo. Code review templates, commit message generators, error explainers — all versioned and portable.

A bootstrap script. One script that installs Ollama, pulls your default models, installs llm and its plugins, sets up direnv, and symlinks your config files. Running this on a fresh machine should get you from zero to productive in under 10 minutes.

This is where a vibe coding setup becomes a repeatable engineering practice. The dotfiles repo is the difference between "I had that alias on my old machine" and "I cloned my dotfiles and everything works."

The Decision Framework: Which Tool for Which Job

The most common mistake I see is using one tool for everything. Claude Code is a terrible choice for "what's the tar flag for gzip?" And sgpt is a terrible choice for refactoring a 15-file module.

Single-command questions → sgpt or llm
"What's the regex for matching ISO dates?" "Explain this error message." Latency matters here, depth doesn't. Quick-query tools.

Multi-file code changes → Aider or OpenCode
"Refactor the auth module to use JWT." "Add error handling to all API endpoints." These tools understand your codebase structure, coordinate changes across files, and commit the results. Aider for git-native transparency. OpenCode for provider flexibility and lower token costs.

Deep, iterative sessions → Claude Code or OpenCode
"Build the entire payment integration from scratch." "Debug this race condition in the event loop." Full agentic capability territory. Claude Code if you value tight Anthropic integration and can absorb the overhead. OpenCode if cost matters.

Prompt prototyping and logging → llm
Building new prompt templates, testing system prompts, comparing model responses. The SQLite log lets you A/B test prompts across models and review results days later.

Local LLM experimentation → Ollama + ollama launch
Trying new open-weight models, benchmarking local inference, running private code through a local model. Ollama manages the model lifecycle. ollama launch wires it to your agentic tool.

Raw control → llama.cpp
Benchmarking, custom quantization testing, hardware-specific tuning, or anything where Ollama's abstractions get in the way.

What CLI Tools Do AI Developers Actually Use Day-to-Day?

Cutting through the tool sprawl, the daily-driver stack for most AI developers in 2026 comes down to five things:

1. A configured shell (fish or zsh with AI-focused aliases)
2. One agentic coding tool (OpenCode for cost efficiency, Claude Code for Anthropic-native workflows, Aider for git transparency)
3. llm by Simon Willison for quick queries and prompt logging
4. Ollama for local model management and the ollama launch bootstrap
5. A dotfiles repo that makes the whole setup reproducible

Five tools. Not fifteen. The developer tools space is noisy, but the signal is clear: pick one tool per layer, configure it well, version your configuration.

Running this site's multi-agent publishing pipeline taught me something that applies directly here: model-per-job-shape beats one-model-everywhere on both cost and quality. The same principle holds for your terminal stack. The right tool at the right scope, wired together with aliases and a bootstrap script.

What Comes Next

The terminal is becoming the primary interface for AI development. Not the IDE, not the browser, not the chat window. Every major move in 2026 reinforces this: ollama launch collapsing setup to one command, OpenCode reaching 7.5 million monthly developers in the terminal, Claude Code expanding to routines and scheduled tasks.

My prediction: by the end of 2026, the majority of professional AI development will happen in terminal-first workflows, with IDEs serving as secondary views rather than primary environments. The developers who invest in their CLI stack now — the shell config, the agentic tool choice, the prompt management layer, the dotfiles repo — will have a compounding productivity advantage that's genuinely hard to catch.

Stop copy-pasting API keys into browser chat windows. Stop using one tool for every task. Build the stack, version it, and ship.

---

Originally published on kunalganglani.com