TL;DR: Llamafile packs llama.cpp and the model weights into one executable — chmod +x, run, and an OpenAI-compatible server is answering on port 8080 with no install, no Docker, no Python. Mozilla.ai revived the project in 2026; 0.10.5 tracks current llama.cpp. The catch: the default combined mode and every GPU run skip llamafile’s own sandbox.

What you’ll be able to do after this guide:

• Download llamafile 0.10.5, run a pre-built gpt-oss-20b or Qwen3.5-27B llamafile (or the bare binary plus any GGUF), and serve /v1/chat/completions with tool calling that works
• Wire that server into Cline (OpenAI Compatible provider), Continue.dev (provider: openai + apiBase), and Aider (openai/ prefix + OPENAI_API_BASE)
• Deploy the whole stack to a machine with no internet — knowing exactly which three things must happen before the network cable comes out

Honest take: If your constraint is “no installer, no internet, must run on whatever machine compliance hands me,” llamafile is the only backend in this series that genuinely delivers — one file on a USB drive is the entire stack, and it executes unmodified on Linux, macOS, Windows, and three BSDs. As a daily driver on your own workstation, Ollama still manages models better and bare llama-server stays closer to upstream. Carry llamafile for the machines you don’t control.

---

Back from the dead, and shipping again

Llamafile spent most of 2025 looking finished. The original Mozilla Builders project — the one that made “single-file LLM” a category in late 2023 — stalled after version 0.9.3 in May 2025, and everyone quietly moved on. Then Mozilla.ai took it over and rebuilt the core: version 0.10.0 landed on March 19, 2026 with a new build system whose whole purpose is staying synced with upstream llama.cpp, and the cadence since has been real — 0.10.4 on July 16, 0.10.5 on August 3, 2026, the latter alone pulling in three upstream llama.cpp syncs. The bundled engine now identifies as a 2026 llama.cpp build (commit 7f5ee54-lineage, with Qwen3.5 support), not the fossilized fork the 0.9 series shipped.

That history matters for this series, because the seventeenth backend we’re wiring into Cline, Continue.dev, and Aider earns its slot with a trick none of the previous sixteen can do: the server and the weights are one file. No pip install, no brew, no container runtime, no Python environment, no registry pull. RamaLama needs Podman. Docker Model Runner needs Docker Desktop. Even llama-server needs you to download a build for your platform plus a GGUF. A llamafile needs chmod +x.

The project is Apache 2.0 (its llama.cpp and whisper.cpp changes are MIT, kept upstreamable), and the same Cosmopolitan Libc packaging means one binary runs on Linux 2.6.18+, macOS, Windows 10+, FreeBSD, NetBSD, and OpenBSD, on any x86-64 chip with AVX or any ARMv8a+ chip — Apple Silicon down to a 64-bit Raspberry Pi.

Step 1 — Pick your file: bundled model or bare binary

Two ways to get a coding-capable server, and the right one depends on the target machine.

Option A: a pre-built llamafile with weights inside. Mozilla.ai publishes current-generation bundles built on the 0.10 server. From the official table, the two that matter for agent coding work:

Pre-built llamafile	Size	Why for coding agents
gpt-oss-20b-mxfp4.llamafile	12 GB	Tool-calling-trained MoE; the project’s own team tested it for tool calls; fits a 16 GB GPU or 24 GB Mac
Qwen3.5-27B-Q5_K_S.llamafile	19 GB	The strongest bundled generalist; wants a 24 GB card (RTX 3090/4090) or 32 GB+ unified memory
Qwen3.5-9B-Q5_K_S.llamafile	7.4 GB	The 8–12 GB VRAM fallback; chat and edits, not long agent loops

curl -LO https://huggingface.co/mozilla-ai/llamafile_0.10/resolve/main/gpt-oss-20b-mxfp4.llamafile
chmod +x gpt-oss-20b-mxfp4.llamafile

Option B: the standalone llamafile binary plus external GGUF weights. The releases page ships the runtime as its own single-file program; point it at any GGUF with -m. This is how you run the series-standard agent pick, Qwen3-Coder-30B-A3B-Instruct at Q4_K_M (18.6 GB from unsloth on Hugging Face), which has no official bundle:

./llamafile -m Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf [flags...]

Option B is mandatory on Windows, where executables cap at 4 GB — every useful bundled llamafile blows past that, so Windows runs llamafile.exe + external weights (or WSL, which also lifts the limit). One more Option B bonus verified in the official docs: llamafile can serve GGUFs that Ollama or LM Studio already downloaded — LM Studio’s live under ~/.cache/lm-studio/models/, and Ollama’s are the sha256-* blobs in ~/.ollama/models/blobs, runnable directly by digest filename. No re-download to switch backends.

When downloading the standalone runtime, grab llamafile, not llamafile-thin — the fat one bundles prebuilt CUDA and Vulkan libraries for x86-64 Linux and Windows, which is the difference between “works offline” and “compiles GPU support on the fly,” and that difference is the whole point of the next two sections. For hardware sizing beyond the table above, the runaihome.com VRAM guide has the full tiers; no GPU at all means a RunPod rental runs everything below unmodified.

Step 2 — The serve command, and why --server is not optional

Here’s the launch that works for agents:

./gpt-oss-20b-mxfp4.llamafile \
  --server \
  --host 127.0.0.1 --port 8080 \
  --jinja \
  --ctx-size 32768 \
  -ngl 999 \
  -a gpt-oss-20b

Sanity-check it the same way as every entry in this series:

$ curl http://127.0.0.1:8080/v1/models
{"object":"list","data":[{"id":"gpt-oss-20b","object":"model", ...}]}

The id is whatever you set with -a/--alias — set it, or you’ll be pasting a .gguf path into three client configs. Now, the flags, because four of them fix problems you’d otherwise discover mid-session:

--server — because the default mode skips the sandbox. Run a llamafile with no mode flag and you get combined mode: a chat TUI in your terminal plus the HTTP server on port 8080, simultaneously. Convenient for kicking tires, wrong for agent duty, and not only because closing the terminal kills your backend. Llamafile’s own security documentation is explicit: combined mode hosts an in-process HTTP client that must connect to the server, so the pledge()/SECCOMP sandbox — the project’s headline security feature — is skipped in combined mode. --server runs the sandboxed configuration. One flag, and the process goes from “ordinary program” to “cannot write files, cannot exec, cannot open outbound connections.”

--jinja — the tool-calling flag, with a 2026 twist. Sixteen backends in, you know the failure: launch a llama.cpp-derived server without --jinja and Cline’s tool calls come back as <tool_call> JSON narrated in chat text, executing nothing — the discovery that anchored the RamaLama guide. The twist is that the llama.cpp build inside llamafile 0.10.5 is recent enough that jinja templating defaults to enabled. So why pass it? Because llamafile’s own server docs still instruct agent users to add it, because the legacy 0.9-series llamafiles (still downloadable, still in circulation) default it off, and because a flag in your launch script is free insurance against a build where the default regressed. Pass it. If tool calls still arrive as prose, you’re on a 0.9-era file — check with --version.

--ctx-size 32768 — because the new default is a slot machine. Earlier series entries fought llama-server’s old 4,096-token default. This build is different in a sneakier way: -c 0 (the default) now means “load the model’s advertised context,” which for Qwen3.5-class models is enormous — and a separate feature, --fit (default: on), then silently shrinks unset parameters until everything fits in device memory, with a documented floor of 4,096 tokens. Translation: your effective context becomes a function of your VRAM at launch time, and you find out what you got by reading startup logs. An agent that plans against a 128K window and lands in a fitted 8K one re-reads files, forgets its plan, and loops — the same amnesia spiral as ever, new cause. Set the number explicitly; 32K is the practical floor for Cline work, and both models in the table hold it on 24 GB.

-ngl 999 — offload is not automatic outside a Mac. Metal offloads by default on Apple Silicon; CUDA, ROCm, and Vulkan need -ngl 999 requested. Worse, GPU setup failures fall back to CPU silently — the model runs, at one-tenth the speed, and nothing tells you why. The documented fix for a quiet fallback is forcing the backend: --gpu nvidia (or amd, vulkan) turns a misconfigured toolchain into a loud startup error instead. And note the security trade you make: llamafile’s sandbox is skipped whenever a GPU backend loads, because drivers need ioctl access no syscall filter can allow. A GPU llamafile server is a convenient server, not a sandboxed one — --gpu disable is the only way to have both, at CPU speed.

Optional but real: --api-key your-secret enables actual bearer-token auth — something RamaLama and bare llama-server defaults never gave you without a reverse proxy. On a shared-office LAN, use it. The server also inherits llama.cpp’s web UI at the root URL (--no-webui to disable).

Step 3 — Wire in Cline, Continue.dev, and Aider

Same OpenAI dialect as the rest of the series; only the alias changes.

Cline (VS Code): API Provider → OpenAI Compatible. Base URL http://127.0.0.1:8080/v1, API key = whatever you set with --api-key, or any non-empty placeholder if you didn’t (Cline requires the field; an auth-less server ignores it). Model ID gpt-oss-20b — exactly the -a alias. Set Cline’s context window to match your --ctx-size, and if tool calls print as text instead of running, re-read the --jinja paragraph above; there is no client-side fix.

Continue.dev (~/.continue/config.yaml):

models:
  - name: llamafile-gpt-oss
    provider: openai
    model: gpt-oss-20b
    apiBase: http://127.0.0.1:8080/v1
    apiKey: local-placeholder
    roles: [chat, edit, apply]

The frozen-at-v2.0.0 caveat from the Cursor acquisition still stands — the extension is static but speaks this API without complaint.

Aider (terminal):

export OPENAI_API_BASE=http://127.0.0.1:8080/v1
export OPENAI_API_KEY=local-placeholder
aider --model openai/gpt-oss-20b

The openai/ prefix routes Aider’s litellm layer to the OpenAI-compatible provider; the rest is your alias. The “Unknown context window size and costs” warning is cosmetic, and the Aider model-not-found guide covers silencing it.

The air-gap playbook: three things before the cable comes out

This is the section that justifies llamafile’s existence in 2026, so let’s be precise about what “works offline” means. After setup, a llamafile server makes zero network calls — the weights are local, and under the --server sandbox the process can’t connect() out even if compromised. But three things must happen while you still have internet:

1. Download the right artifacts. The .llamafile bundle (or llamafile binary + GGUF) onto a portable drive — a Samsung T7 moves a 19 GB model faster than most office networks. For NVIDIA or generic-GPU targets on x86-64 Linux or Windows, the fat llamafile binary already contains the CUDA and Vulkan libraries; the target machine needs only its GPU driver, no CUDA toolkit. AMD ROCm is the exception — it’s experimental, not bundled, and you’d pre-download the ggml-rocm library from the project’s Hugging Face repo or lean on the bundled Vulkan backend instead.

2. Do one throwaway run on the target hardware class. On Apple Silicon, Metal support compiles a small module on first launch using Xcode Command Line Tools — a one-time cost that requires the CLT to be present. On an air-gapped Mac, that means CLT installed and one first run completed before isolation, after which the built module is cached. On Linux, this shakedown run also catches the binfmt_misc/run-detectors interaction some distros have with APE executables (fixable offline by registering the ape loader, but you want to know before the machine is sealed).

3. Record the launch line. The full command from Step 2, --ctx-size included, in a shell script next to the llamafile. Six months later, nobody will remember why --jinja matters. The whole deployment is then two files and a script — which is also exactly the shape CI wants: a self-contained inference server you can cache as a build artifact and launch per test run, no registry pulls, no docker login, no version drift between what CI runs and what shipped to the isolated site.

That’s the complete story. Compare the same exercise with Ollama (installer + service + model pull), or RamaLama (Podman + container image + model pull), and the category difference is obvious: those tools assume a network and cache through it; llamafile assumes nothing.

What the sandbox actually buys you

Since we’ve now mentioned it three times: llamafile’s --server mode runs under a pledge()-derived SECCOMP filter by default — on Linux, the process is limited to roughly “answer connections and read files.” No outbound network (it can accept() but not connect()), no file writes, no spawning processes. An optional --confine-reads adds Landlock filesystem confinement so the server can’t even read outside the weights’ directories — your SSH keys become invisible to it. You can verify the filter is live: grep Seccomp /proc/<pid>/status returning Seccomp: 2 means active.

In a year that gave us Agentjacking, GhostApproval, and the Amazon Q MCP credential theft, the honest framing is the one we gave RamaLama: this hardens the layer that parses untrusted GGUF bytes and untrusted HTTP, not the agent that edits your files. And llamafile’s version comes with sharper asterisks than RamaLama’s containers: the sandbox is self-imposed (an attacker-supplied llamafile simply wouldn’t include it — only run llamafiles from sources you trust), it disappears under GPU offload, and it disappears in combined mode. The 0.10 server also ships opt-in built-in tools and an agent mode (--tools, --agent) that can read local files server-side; those relax the no-outbound-network promise and have no place on a coding-backend deployment — leave them off.

Practical ranking, if isolation drives the choice: RamaLama’s rootless container still wins on GPU workloads (containment survives GPU passthrough); llamafile wins on CPU-only boxes where installing Podman isn’t an option, which is a fair description of most air-gapped corporate hardware.

Where it breaks

The 4 GB Windows wall. Not llamafile’s fault — Windows caps executable size — but every bundled model worth using for coding exceeds it. Windows means external weights or WSL, full stop.

AMD and Windows GPU paths are self-declared best-effort. The docs say the 0.10 series hasn’t been tested across every GPU and platform yet. NVIDIA-on-Linux and Metal-on-Apple-Silicon are the paved roads.

IQ-quants don’t accelerate on the bundled CUDA build. The size-optimized CUDA library omits IQ-quant kernels; those layers quietly run on CPU (output stays correct). Stick to Q4_K/Q5_K/MXFP4 files — which you should anyway for coding — or build the full CUDA library yourself.

One model per process. The one-file philosophy is the anti-thesis of model management. No pull-and-swap, no keep-alive policies, no catalog. Run two llamafiles on two ports if you need the agent-model-plus-autocomplete pairing, or front them with llama-swap — at which point you’ve reinvented an installed stack and should ask whether you still need the one-file property.

Performance-claim discipline, as always: no tokens-per-second numbers we haven’t measured on hardware you don’t have. Architecturally it’s the same llama.cpp as bare llama-server — expect parity on identical flags and hardware, minus nothing measurable for the packaging.

Verdict

Llamafile 0.10.5 is the backend for constrained environments: air-gapped networks, locked-down corporate laptops where you can’t install anything but can run a file, USB-drive demos, CI jobs that want inference as a cached artifact, and onboarding a teammate who will not be talked through an Ollama install. In those settings nothing else in this series competes — the deployment is a file copy, and the offline story is engineered, not incidental.

On your own workstation, it’s the wrong default. Ollama manages a rotating model library better, LM Studio gives you a GUI, bare llama-server tracks upstream tighter for tinkerers, and LiteLLM Proxy handles the local-plus-cloud routing llamafile never will. Carry llamafile for machines you don’t control; live on something with a model manager at home. For the open-source deep-dive on the project itself, aifoss.dev covers the FOSS angle of the revival.

FAQ

Is llamafile still maintained? I heard it died. It did stall — nothing shipped between May 2025 (0.9.3) and the Mozilla.ai revival that produced 0.10.0 on March 19, 2026. Since then: five 0.10.x releases through August 3, 2026, a rebuilt core designed for fast upstream llama.cpp syncs, and current-model support (Qwen3.5, gpt-oss). Treat 0.9-era llamafiles as legacy.

Does the server require an API key? Off by default; --api-key your-secret enables real bearer auth, which the clients above then supply as their API key. Cline and Continue require a non-empty key field either way, so use a placeholder when auth is off, and keep --host 127.0.0.1 regardless.

Cline shows the model typing out tool-call JSON instead of running tools. Fix? Chat-template activation. On 0.10.5, confirm you passed --jinja (harmless if redundant) and that the model is tool-trained — gpt-oss-20b and the Qwen3 family are; llava is not. On a legacy 0.9 llamafile, --jinja support predates reliable tool parsing — move to a 0.10 build. Same symptom family as the Ollama tool-use loop, same diagnosis order.

Can I point llamafile at models Ollama already downloaded? Yes — Ollama stores GGUF weights as sha256-* blobs under ~/.ollama/models/blobs, and llamafile -m <blob-path> serves them directly (the official docs document the manifest-to-blob lookup). One caveat from those docs: some Ollama-repacked GGUFs deviate from upstream llama.cpp expectations and may refuse to load.

Does this work with Cursor? Not over loopback — Cursor’s BYOK requests originate from Cursor’s servers. The tunnel workaround in the Cursor + Ollama guide applies unchanged, though it defeats the air-gap purpose entirely.

Sources

• llamafile README — mozilla-ai/llamafile (GitHub): revival, quickstart, license, platform support
• Running llamafile — official docs: —server, —jinja for agents, combined mode, built-in tools
• CLI arguments — official docs: wrapper flags, —gpu modes, server-only flags
• Security — official docs: pledge/SECCOMP defaults, —confine-reads, GPU and combined-mode sandbox skips
• Getting started — official docs: OpenAI-compatible API, external weights, Windows 4 GB limit, Ollama/LM Studio model reuse
• Pre-built llamafiles — official model table with sizes and licenses
• llamafile releases — 0.10.5 (Aug 3, 2026) and the 0.10.x series
• README_0.10.0 — the rebuild timeline and feature status
• llama.cpp server README — function calling requires jinja; -c/-n/—fit defaults
• Llamafile 0.10.0 released — Help Net Security, March 20, 2026
• Mozilla Releases Llamafile 0.10 — Phoronix
• Cline OpenAI Compatible provider docs
• Aider OpenAI-compatible API docs

Last updated September 7, 2026. Pricing and features change frequently; verify current state before purchasing.

Recommended Gear

• RTX 3090 — the used-market 24 GB card that holds the Qwen3.5-27B bundle or the Qwen3-Coder Q4_K_M with agent-grade context
• Samsung T7 SSD — sneakernet transport for 12–19 GB llamafiles onto air-gapped machines

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.

Email address Subscribe