AI coding locale su MacBook 64GB: tagliare i costi senza spezzare Docker e IDE

Puoi abbassare i costi di coding AI (Opus/GPT/Grok) con un mix di cloud economico e modelli locali sul MacBook da 64GB di RAM unificata, tenendo aperti Docker e IDE. Conta quanto del lavoro quotidiano resta in piedi mentre tagli la spesa. Se spezzi Docker o l’IDE per “risparmiare” sui token, hai solo spostato il costo.

I costi da migliaia di euro al mese sono il motivo. Il vincolo è la macchina di lavoro: stessa giornata, niente lab isolato.

Cursor chiude il rubinetto dove conta

Cursor blocca BYOK e modelli custom in Agent Mode. Custom resta su Ask e Plan. Base URL OpenRouter usata in sessione: https://openrouter.ai/api/v1/cursor.

In pratica Cursor non ti lascia controllare modello e costo quando lavori in agent mode. Cambi editor.

Cloud economico: DeepSeek V4.1 Flash (listino vendor)

Uscito il 10 settembre 2026. Causal Encoder-Decoder, 552B, da 8 a 16B attivi. DeepSeek riporta benchmark competitivi su Terminal-Bench e DeepSWE; li cito come eval vendor, non come misura mia.

Prezzi di listino: $0.15/1M input, $0.60/1M output (fino a x2 nei picchi), cache-hit $0.003/1M. Caveat loro: robustezza sui contesti lunghi non del tutto caratterizzata.

Questo pezzo del mix paga i task dove il cloud economico basta. Il locale entra dove vuoi tenere token e dati sulla macchina, o dove il round-trip non ti serve, e dove il costo di una sessione lunga su Opus o GPT smette di avere senso rispetto a un modello che gira in locale con limiti noti.

Editor: Zed, con il costo dichiarato

Cercavo nativo più BYOK reale in agent. Scelta finale: Zed.

Trae sul piano tecnico regge; la telemetria ByteDance no. Nova e Lapce scartati. OpenCode TUI resta alternativa leggera se il file-tree non è indispensabile.

Nessun editor 2026 chiude nativo e BYOK agentico senza buchi in UI. Zed è il compromesso che tengo. Non la soluzione definitiva.

Dove il locale brucia ore (e RAM)

LM Studio fa da motore e espone API su localhost:1234. Non scrive file. L’agente sta sopra.

Ho messo Bionic sopra LM Studio. Bug sul parser dei tool-call: disinstallato. Stack attuale: Zed + LM Studio, con JIT e Auto Unload TTL (carica e scarica il modello; chat history lato client).

Qui inizia la parte che costa tempo vero.

Su MacBook 64GB la RAM “mangiata” spesso è il workflow (Docker e IDE aperti, browser incluso), non macOS da solo. Context Length e KV Cache pesano su RAM e lentezza più del nome del modello: se li lasci a caso, anche un modello “piccolo” ti mangia comunque la giornata, perché la cache e il context competono con i container e con l’IDE sullo stesso pool di RAM unificata.

Config MLX tipiche da sessione: Context Length esplicito; Max Concurrent Predictions = 1; KV quant caso per caso; Reasoning parsing off se non è un reasoning model. Su VLM MLX, KV Cache Quant OFF (bug batched vision). Context troppo basso e Truncate Middle spezza i tool-call.

Denso contro MoE: in sessione ho confrontato Devstral Small 2 24B (denso) e Qwen3 Coder A3B (MoE). Trade-off RAM contro token/s. I MoE veloci sono meno prevedibili in long-context; i densi più stabili e più lenti. Nessun moltiplicatore inventato: è comportamento osservato, non brochure.

Poi lo swap thrashing. Modello duplicato via JIT, macchina in thrashing, eject, reboot Mac: fine della giornata produttiva. Quello è il costo reale del locale mal calibrato, misurato in reboot a metà lavoro.

Si può obiettare: lascia Cursor, paga il piano cloud caro, finisci le consegne. Regge, se i migliaia di euro al mese non ti bruciano.

A me bruciano.

Per questo il mix esiste. E per questo lo swap thrashing conta come costo di prodotto: sbagli Context e JIT sulla stessa macchina dove gira Docker, con Docker e IDE ancora aperti quando la RAM finisce, e la giornata finisce in reboot invece che in consegne.

Bonsai 27B ternario: meglio finora, loop aperto

Bonsai 27B (PrismML), ternary 2BIT MLX, 8.52GB. Vision e tool use, hybrid thinking, context fino a 262K. Ternaria, non 1-bit, per il tool-calling. Benchmark base Qwen3.6-27B vs Sonnet: vendor/eval, non miracolo.

In riposo 12-18GB; picchi intorno ai 35GB su 64GB. Con Docker e IDE aperti il margine c’è, se non spari Context e KV a caso.

Problema aperto: loop di ragionamento lunghi sul ternario (list/read/think senza scrivere). Diagnosi ancora sospesa tra compressione estrema e config: non so ancora se il loop nasce dalla ternaria o dai parametri di sessione che lo spingono a girare a vuoto senza scrivere. Compressione estrema ha un costo su autonomia tool-calling e convergenza. Test su Qwen3-14B non fatto. Mitigazioni da provare: non-thinking, oppure Repeat Penalty e Temperature.

Il prossimo pezzo da misurare è quello: chiudere o smontare il loop su Bonsai, oppure confrontare con Qwen3-14B. Poi monitor RAM su sessioni lunghe. Se il file-tree non mi serve, OpenCode contro Zed.

Se cerchi la gallery del mese o la guida “passa tutto in locale”, altrove.

Se ti serve un pezzo di esperienza su costi da migliaia €/mese, MacBook 64GB, e cosa si rompe quando tieni Docker e IDE aperti: sessione del 14 settembre 2026. Limiti ancora aperti.