By Manuel Tardivo
Local AI coding on a 64GB MacBook: cut costs without breaking Docker and IDE
Cheap cloud plus local models on a 64GB MacBook with Docker and IDE open. Cursor blocks BYOK in Agent Mode; Zed, LM Studio, Bonsai: what held in the 14 Sep 2026 session.

You can cut AI coding costs (Opus/GPT/Grok) with a mix of cheap cloud and local models on a 64GB unified-memory MacBook, while keeping Docker and the IDE open. What matters is how much of the daily work stays standing while you cut spend. If you break Docker or the IDE to “save” on tokens, you only moved the cost.
The thousands of euros a month are the reason. The constraint is the work machine: the same day, no isolated lab.
Cursor shuts the tap where it counts
Cursor blocks BYOK and custom models in Agent Mode. Custom stays on Ask and Plan. OpenRouter base URL used in session: https://openrouter.ai/api/v1/cursor.
In practice Cursor does not let you control model and cost when you work in agent mode. You change editor.
Cheap cloud: DeepSeek V4.1 Flash (vendor list price)
Shipped 10 September 2026. Causal Encoder-Decoder, 552B, 8 to 16B active. DeepSeek reports competitive benchmarks on Terminal-Bench and DeepSWE; I cite them as vendor eval, not as my own measure.
List prices: $0.15/1M input, $0.60/1M output (up to x2 at peaks), cache-hit $0.003/1M. Their caveat: robustness on long contexts is not fully characterized.
This part of the mix pays for tasks where cheap cloud is enough. Local comes in where you want tokens and data on the machine, or where the round-trip is not needed, and where the cost of a long session on Opus or GPT stops making sense next to a model that runs locally with known limits.
Editor: Zed, with the cost declared
I was looking for native plus real BYOK in agent. Final pick: Zed.
Trae holds on the technical side; ByteDance telemetry does not. Nova and Lapce dropped. OpenCode TUI stays a light alternative if the file-tree is not required.
No 2026 editor closes native and agentic BYOK without UI holes. Zed is the compromise I keep. Not the final solution.
Where local burns hours (and RAM)
LM Studio is the engine and exposes an API on localhost:1234. It does not write files. The agent sits on top.
I put Bionic on top of LM Studio. Bug in the tool-call parser: uninstalled. Current stack: Zed + LM Studio, with JIT and Auto Unload TTL (loads and unloads the model; chat history on the client).
This is where the real time cost starts.
On a 64GB MacBook the RAM that gets “eaten” is often the workflow (Docker and IDE open, browser included), not macOS alone. Context Length and KV Cache weigh on RAM and slowness more than the model name: if you leave them to chance, even a “small” model still eats the day, because cache and context compete with containers and the IDE on the same unified RAM pool.
Typical MLX config from the session: explicit Context Length; Max Concurrent Predictions = 1; KV quant case by case; Reasoning parsing off if it is not a reasoning model. On VLM MLX, KV Cache Quant OFF (batched vision bug). Context too low plus Truncate Middle breaks tool-calls.
Dense versus MoE: in session I compared Devstral Small 2 24B (dense) and Qwen3 Coder A3B (MoE). Trade-off RAM versus token/s. Fast MoE models are less predictable in long-context; dense ones are more stable and slower. No invented multiplier: observed behavior, not a brochure.
Then swap thrashing. Model duplicated via JIT, machine thrashing, eject, Mac reboot: end of the productive day. That is the real cost of poorly calibrated local, measured in a reboot mid-work.
You can object: stay on Cursor, pay the expensive cloud plan, finish the deliveries. It holds, if the thousands of euros a month do not burn you.
They burn me.
That is why the mix exists. And that is why swap thrashing counts as a product cost: you get Context and JIT wrong on the same machine Docker runs on, with Docker and the IDE still open when RAM runs out, and the day ends in a reboot instead of deliveries.
Bonsai 27B ternary: best so far, open loop
Bonsai 27B (PrismML), ternary 2BIT MLX, 8.52GB. Vision and tool use, hybrid thinking, context up to 262K. Ternary, not 1-bit, for tool-calling. Base benchmark Qwen3.6-27B vs Sonnet: vendor/eval, not a miracle.
At rest 12-18GB; peaks around 35GB on 64GB. With Docker and IDE open there is headroom, if you do not fire Context and KV at random.
Open problem: long reasoning loops on the ternary (list/read/think without writing). Diagnosis still open between extreme compression and config: I do not yet know if the loop comes from the ternary or from session parameters that push it to spin without writing. Extreme compression has a cost on tool-calling autonomy and convergence. Test on Qwen3-14B not done. Mitigations to try: non-thinking, or Repeat Penalty and Temperature.
The next piece to measure is that: close or take apart the loop on Bonsai, or compare with Qwen3-14B. Then RAM monitor on long sessions. If I do not need the file-tree, OpenCode versus Zed.
If you want the monthly gallery or the “move everything local” guide, look elsewhere.
If you need a piece of experience on costs of thousands of €/month, a 64GB MacBook, and what breaks when you keep Docker and the IDE open: session of 14 September 2026. Limits still open.