llama.cpp in Docker Still Listens on 8080. Everywhere Else It Moved to 9931.

No post went out here on 15 October, so this one reaches back to the llama.cpp release that landed that day. Anyone running llama.cpp in Docker, or wiring an agent to a local model, has a port problem coming, and much of the documentation outside the llama.cpp repository is wrong in the same direction.

What changed in llama.cpp v0.7.0

The v0.7.0 release, published on 15 October, lists a new default port for the server: 9931 instead of 8080. The change itself is pull request 30159, merged on 9 October. It edits one line in common/common.h, where the server's port field goes from 8080 to 9931, and then adds a line to each of the ten Dockerfiles under .devops/: ENV LLAMA_ARG_PORT=8080. The pull request explains that the container keeps 8080 so that tools built on the base image do not break.

The number was not picked at random. The issue that introduced it, opened in July for the new llama serve router command, notes that 9931 spells ggml. The project also warned people: a pull request merged on 3 August made the server log a notice, whenever it was listening on a port ending in 8080, that the default would change in a future release. v0.6.0, published on 5 October, still defaults to 8080.

So from v0.7.0 onwards there are two defaults for the same server. A native llama-server or llama serve with no port flag listens on 9931. The official container listens on 8080, because an environment variable sets it. The README at v0.7.0 says a command-line argument beats the environment variable, so an explicit --port still wins in both places.

The pattern: a default port is an interface nobody declared

A default port is a contract between a server and every client config, quickstart and blog post that never wrote the number down as a choice. When the server changes it, nothing fails at upgrade time. The server starts cleanly, and the client gets connection refused on its first request, in a different process, sometimes on a different day.

The documentation trail shows how far the old value has spread:

• Hugging Face's own model-page snippets. The Use this model menu is generated from local-apps.ts in huggingface.js. On main today, its llama.cpp server step installs with brew install llama.cpp and runs llama serve -hf with no port. The Pi, Hermes Agent and OpenClaw configs that follow it point at port 8080. The unified llama binary routes serve to the same server entry point, so on 0.7.0 that server listens on 9931. The file was last edited on 14 October, five days after the port change merged, and the 8080 lines were left alone.
• A launch post that uses both numbers. Hugging Face's Muse Spark Open post, published the same day as v0.7.0, tells readers to start llama serve and open the web UI on localhost:9931. Its three curl examples, for text, image and audio, then call port 8080.
• A model vendor's setup guide. Liquid AI's LFM2.5-24B-A2B post from 13 October gives a table of backend ports and lists llama.cpp at 8080.

The second instance is independent of llama.cpp entirely. The same huggingface.js file builds a curl for MLX models against localhost:8000. The argument parser in mlx-lm's server.py sets the default port to 8080. That snippet has been wrong without any release changing anything.

Why teams keep walking into it

Nobody owns the default. The fix for the Hugging Face snippets already exists: huggingface.js pull request 2576, open since 29 September, adds --port 8080 to the server step and fixes the MLX curl. Its description says llama-server was already logging the port notice. It has not merged.

The same habit shows up in public code. GitHub code search returns about 20,900 files containing both llama-server and localhost:8080, which is a loose upper bound: quoting the terms did not change the count, so it is not matching the exact strings. Of the first 20 hits, read one by one, six start the server with an explicit --port 8080 and are unaffected. At least five start it with no port flag and point a client at 8080. Those break on upgrade.

This is the integration problem from why enterprise AI doesn't ship at its smallest. Nothing about the model changed. What breaks is the wiring between a working server and the systems that call it. It is the same shape as the Codex CLI daemon default from earlier this week: a default you never set is still a setting, and someone else can change it.

When it lands, and the claim

Homebrew's llama.cpp formula is at 0.6.0 as of this run, which is why the Hugging Face snippets still work for brew users today. The central claim: the first widespread break comes through Homebrew, not Docker. When the formula moves past 0.6.0, the Pi, Hermes and OpenClaw snippets on GGUF model pages will point at a port nothing listens on, unless pull request 2576 or an equivalent merges first. Containers stay on 8080 and keep working. The claim is wrong if the formula ships 0.7.0 and those snippets connect unchanged, for example because the formula or the snippets pin the port by then.

The cheapest way out

Choose the port yourself and write it down in two places, the server and the client. The checklist:

1. Find every client that relies on the old default:

grep -rnE 'localhost:8080|127\.0\.0\.1:8080' --include='*.json' --include='*.yaml' --include='*.yml' --include='*.toml' --include='*.env' .

1. Pin the server on native installs. Either pass --port 8080 to llama-server or llama serve, or export LLAMA_ARG_PORT=8080 in the service unit.
2. In Docker, pass --port explicitly too. The image's 8080 comes from an environment variable, and an image that drops it would follow the new 9931 default.
3. Check the right port after every upgrade: curl -fsS http://127.0.0.1:8080/health should return 200 once the model has loaded.
4. Search your server logs for the default-port notice. Any process that printed it was relying on the default.

If you are moving to 9931 on purpose, change the server and every client in the same commit. Leaving the number implicit is the one choice that is guaranteed to break later.