llama.cpp 1.0 on a Mac: CLI Keeps Working, Ripple 65B Needs 64GB

llama.cpp 1.0.0 shipped on November 13, 2026, and for most Mac users nothing breaks. The release removes 35 deprecated functions from the llama.h C API, so apps and language bindings that still call them must update. The command-line tools lose only one option, --defrag-thold. The biggest new model it runs, Ripple 65B Preview, needs a 64GB Mac at Q4_K_M (GitHub release notes, 2026).

Below: what changed, who has to act, how to install it on macOS, and which Macs run the new models.

What changed in llama.cpp 1.0.0?

Version 1.0.0 is a stability promise more than a feature drop. From now on, both llama.cpp and ggml bump the major version whenever the public C API breaks, the minor version for new features or model support, and the patch version for bug fixes (Hugging Face blog, 2026).

The release notes list four groups of changes that matter on a Mac:

• API cleanup. llama_set_warmup, the 35 functions marked deprecated and the defrag_thold field are gone. The NextN and speculative decoding API moves from llama-ext.h into llama.h.
• New models. Kimi-K3.1-Pro, Ripple-65B-Preview and xing4_0 text models, drama-3 TTS, plus MageVL-Cowork and Kimi-K3.1 vision.
• Memory features. FP8 KV caches (-ctk f8_e4m3 -ctv f8_e4m3) and a host-memory MoE expert cache.
• Server and UI. llama-server gets SSRF, CORS and DNS rebinding fixes, an OpenAI-style /v1/audio/speech endpoint and a redesigned web UI.

The bundled ggml 1.0.0 also brings MoE fusion and few-row quantized matmul work for CUDA and Metal, per the same notes. The project now supports more than 150 architecture variants, according to the Hugging Face announcement.

Will upgrading break my Mac setup?

If you only run llama-server or llama-cli from the terminal, almost certainly not. The one removed command-line option is -dt, --defrag-thold. Delete it from your launch scripts, since an unknown flag stops the tool with an invalid argument error (PR #30565, 2026).

Two server changes can also bite. Tools or MCP on a non-loopback --host without an API key are now refused unless you add --allow-unauthenticated-tools (PR #32113, 2026). Media URLs pointing at a NAS or another LAN address now need --media-allow-private-urls (PR #32115, 2026).

App developers have more to check. The prune pull request lists what went away and what moved:

The clip.h removal comes from the multimodal refactor in PR #31865. Swift apps that embed the XCFramework should pin the old build until their wrapper compiles against the new headers.

Ollama and LM Studio users do not upgrade llama.cpp by hand. Those apps ship their own engine build and move on their own schedule.

How do I install llama.cpp 1.0 on macOS?

Homebrew is the fastest route. The Homebrew formula lists 1.0.0 as the stable version, so brew upgrade llama.cpp (or brew install llama.cpp) lands on it today.

The other macOS channels the project names are MacPorts, conda-forge, the prebuilt release archives and the XCFramework for iOS and macOS apps (Hugging Face blog, 2026). The v1.0.0 release points to nightly build b12359, which carries the macos-arm64 archive and the xcframework zip.

brew upgrade llama.cpp
llama-server --version

Which Macs can run Ripple 65B Preview?

You need 64GB of unified memory. The Q4_K_M GGUF is 38,798,820,576 bytes, about 39GB, in the community GGUF repo. That leaves too little room on a 48GB Mac once macOS and the context cache take their share.

Ripple support landed through PR #31692 as a new dense 65B architecture with no new ops. The speeds below are ModelFit engine estimates for Q4_K_M, labeled est., not measurements.

At 64GB the model fits but leaves little headroom, so keep context modest. The Ripple 65B model page has the full machine list.

To run it with llama.cpp directly:

llama-server -hf AtomicChat/Ripple-65B-Preview-GGUF --hf-file Ripple-65B-Preview-Q4_K_M.gguf -c 16384

Ollama also lists it. The ripple-preview tags page shows a 39GB q4_K_M tag:

ollama run ripple-preview:65b-q4_K_M

Kimi-K3.1-Pro is the other new text model, and it needs far more memory than any single Mac offers.

Do FP8 KV caches and the MoE cache help on a Mac?

Possibly, but the release does not prove it for Apple Silicon yet. FP8 KV caches store the attention cache in 8 bits, which halves its size versus F16 in principle (PR #28392, 2026). The backend-specific FP8 commit in the changelog is for CUDA; no Metal FP8 kernel is listed.

The MoE expert cache keeps hot experts on the GPU and runs misses on the CPU. The tuning example in PR #30966 was run on a CUDA desktop with separate VRAM. A Mac shares one memory pool between CPU and GPU, so the gain there is unmeasured.

The existing q8_0 KV cache type remains the safe choice on Metal. Our llama.cpp 0.4.0 Mac guide covers the earlier memory features that still apply.

What should I run on my Mac after upgrading?

The upgrade changes the engine, not the memory ceiling. Your RAM still decides the model class. Our RAM guide maps memory tiers to model sizes, and the Ollama requirements by model post covers tag sizes.

For a ranked pick on your exact machine, open the ModelFit wizard or run npx @modelfit/cli@latest in a terminal. Owners of a 64GB Studio can start with the best LLMs for a Mac Studio M5 Max 64GB.

FAQ

Does llama.cpp 1.0 break Ollama or LM Studio?

No. Ollama and LM Studio bundle their own build of the engine and update it on their own schedule. Nothing changes on your Mac until those apps ship a release based on the new code. When they do, the API cleanup is their work to absorb, not yours, so model files and your saved chats are unaffected.

What do I have to change in my llama-server scripts?

Remove the defrag option first. The -dt and --defrag-thold flags are gone, so delete them from launch scripts, launchd plists or shell aliases. If you serve tools or MCP on your LAN without an API key, add --allow-unauthenticated-tools. If chat requests fetch media from a NAS, add --media-allow-private-urls.

How much memory does Ripple 65B need on a Mac?

Plan on 64GB. The Q4_K_M file is about 39GB, and macOS plus the context cache need room on top of that. A 48GB Mac is too tight. The Q8_0 build is roughly 69GB across two files, so it needs a 96GB or larger Mac.

Is the version jump from 0.9 to 1.0 a big performance upgrade?

Not by itself. The number marks the start of semantic versioning and the removal of the deprecated API. Performance work arrives through the bundled ggml 1.0.0, which includes Metal MoE fusion, but the release notes publish no Apple Silicon speed figures for it.

Sources

• llama.cpp v1.0.0 release notes
• llama.cpp build b12359 (macOS assets)
• Hugging Face blog: llama.cpp v1.0.0
• PR #30565: llama prune
• PR #32113: tools opt-in on LAN
• PR #32115: private media URLs
• PR #31865: remove clip.h
• PR #28392: FP8 KV cache
• PR #30966: MoE cache CPU share
• PR #31692: Ripple architecture
• Homebrew formula llama.cpp
• AtomicChat Ripple-65B-Preview-GGUF
• Ollama ripple-preview tags