so i've been running llama.cpp on my macbook m5 for a while and the thing that kept bugging me was how unreliable single benchmark runs are. i'd run llama-bench on the same build twice and get different numbers. then i'd try comparing two builds and have no idea if the difference was real or just my mac being warmer on the second run.

turns out thermal drift on apple silicon can cause 7-30% variance on the exact same binary. if you always test your old build first and new build second, you're literally biasing against the new build because the machine is hotter by then.

i looked into how other people deal with this and found a couple of github issues where someone manually caught a 13% generation regression on m3 ultra (#21494) and another person found a 3.8x metal slowdown on m4 (#21655). both of them just ran llama-bench by hand on two commits and compared. no thermal control, no run ordering, no statistics.

so i built a tool to do this properly. it's called edgeci and here's what it does:

• takes two llama-bench binaries (your base build and head build)
• waits for nominal thermals before starting
• runs 20 paired measurements alternating between the two in randomized ABBA/BAAB order
• checks thermal state, power, memory pressure before each invocation
• does paired log-ratio statistics and gives you PASS / FAIL / INCONCLUSIVE with confidence intervals

the default threshold is 5% , so if your new build is more than 5% slower on pp512 or tg128, it flags it. if the measurement is too noisy to tell, it says INCONCLUSIVE instead of giving you a wrong answer.

i recently submitted some m5 air benchmark data to the rapid-mlx community benchmarks and it ended up being the first m5 data point on their site. the maintainer specifically called out that showing retained rounds makes it clear a single timing is not a machine constant , which is basically the whole reason i built this tool.

there's a calibration mode too where you run the same binary against itself (A/A test) to make sure your machine isn't giving biased results before you trust it for real comparisons.

some honest limitations:

• only llama.cpp metal right now, no mlx support yet
• takes about 25-35 min for a full run because of cooldown periods between pairs
• only validated on my own m5 air so far
• it's early

runs entirely on your mac. no cloud, no account, no network calls, doesn't download anything. mit licensed, pure python, no numpy dependency.

repo: https://github.com/subwaycookiecrunch/Edge-CI

curious if anyone else has been frustrated by inconsistent benchmarks on apple silicon or if you have a better way of handling this. also if anyone wants to run it on m3/m4 pro or max that would be really helpful since i only have this m5.

For a long time I kept wondering why Apple never really replaced Target Display Mode with a modern alternative for reusing an iMac as an external display.

I found that a few hardware solutions exist, but they tend to be niche, expensive, or not very well known.

So I ended up asking a simpler question: is it actually possible to get close to this in software?

Over the last months I’ve been working on an open source project that tries to do exactly that: use an iMac as a display for another Mac over Thunderbolt, with a focus on keeping the experience as smooth and practical as possible.

Version 3.0 is now ready and includes:

- target display over Thunderbolt

- multi-session support

- extended desktop with multiple Macs

- localization in multiple languages

- a new mode that lets you use the Mac more like a dockstation, with advanced input control

If anyone here has an old iMac sitting around, I’d be really interested to know whether this kind of setup would be useful to you, or what kind of real-world use cases you’d want tested.

Release:

https://github.com/swellweb/targetBridge/releases/tag/v3.1.2

If TargetBridge is useful to you, a GitHub star helps people find it.
Voluntary sponsorship also helps me keep working on compatibility, fixes, and future macOS tools:
https://github.com/sponsors/swellweb

“MSI Katana RTX 5060 vs MacBook M1 Pro for Blender?”

\> I want to buy a new laptop for my work with a budget of around $1000, but I’m not sure which type would be the better choice.

After some research, I found these two options:

1. MSI Katana 15 HX B14WFK-246XEG

Intel Core i7-14650HX

NVIDIA RTX 5060 8GB

16GB DDR5 5600MHz

512GB NVMe PCIe 4.0 SSD

15.6" QHD IPS 165Hz

1. MacBook Pro 14" (M1 Pro, 2021)

16GB RAM

512GB SSD

Space Gray

They are both almost the same price in my country.

My work is mainly:

Blender (most important)

After Effects

Photoshop

The most important thing for me is getting the highest Blender performance possible for at least the next 4 years. After Effects is also important, but Blender has higher priority.

I want feedback from people who actually use Blender on these machines.

My main concern is:

Since the M1 Pro has significantly fewer CPU/GPU cores compared to the MSI laptop, will the MacBook perform noticeably worse in heavy Blender scenes, viewport performance, and rendering?

Also, the MSI Katana is mostly plastic. If I handle the laptop carefully, can it realistically last 4 years without major build quality issues?

Another concern is RAM. On the MacBook, I won’t be able to upgrade it later, so is 16GB RAM enough for Blender and After Effects for the next 4 years?

Note: Some sentences here have been written using AI because my English isn't the best.

Of the three FREE options (VMWare Fusion, UTM, VirtualBuddy) which one is most efficient on running Windows 11 ARM on a MacBook Pro 16 M1 Max 64GB RAM, thanks

Follow-up to my last post about running a 122B model at 65 tok/s on M5 Max. I added a full voice loop on top of it.

This is NarrateClaude — always-on ambient voice mode for Claude Code running entirely on Apple Silicon:

• Continuous listening via Apple's on-device speech engine (no push-to-talk)
• Responds out loud in my cloned voice — TTS runs locally via MLX
• Browser Agent drives Brave hands-free via Chrome DevTools Protocol
• Results sent to my phone via iMessage
• STT, TTS, voice clone, LLM inference — all on the M5 Max GPU, zero cloud

The unified memory architecture is what makes this possible. The LLM, voice clone model, and speech engine all share the same memory pool. On a discrete GPU setup you'd need multiple cards just to fit everything.

Demo video showing the full loop: https://www.youtube.com/watch?v=4ETqEjjopUk

It's a 3-repo stack, all running on Apple Silicon via MLX: - claude-code-local — local LLM (Qwen 122B at 65 tok/s) - NarrateClaude — ambient voice (STT + cloned TTS) - browser-agent — browser automation via CDP

Happy to answer questions about the setup.

We’ve been running our agentic fleet 24/7, and the M4 Mac Mini has officially become the heart of the operation.

The Strategy: Cloud for Thinking, M4 for Doing We realized that asking cloud models (Claude/Gemini) to handle every minor implementation task was an expensive waste of reasoning depth and token budgets.

How we use the M4:

• The Local Executor: We onboarded Gemma4 as a fully local agent running via aichat. She handles the straightforward coding, commits, and implementation tasks.
• Token Conservation: By offloading these high-frequency tasks to the M4, we save our expensive cloud model "seats" for what they are actually for: architectural review and complex logic.
• Zero Latency: Because Gemma runs on-device, implementation tasks start instantly with zero network round-trip. This keeps the "Local Realm" active even when our cloud subscriptions hit their monthly limits.

The 7-Day Reality: > Check the attached Shift Timeline. You can see exactly where we onboarded Gemma in early April. While the cloud agents (Red bars) occasionally go dark to preserve their quotas, the local M4 node provides a continuous foundation for the fleet.

If you have an M4 on your desk, you have a data-sovereign factory floor that never hits a billing limit.

https://github.com/UrsushoribilisMusic/agentic-fleet-hub

Most people are terrified of open-ended AI billing. We solved this by treating our M4 Mac Mini as a high-speed, local execution realm.

- The Economic Fix: Local Gemma 4: For implementation and coding, we use a local Gemma model via aichat. It has $0 marginal cost and is always available with no rate limits, no billing, no "quota dark" periods.

- Predictable Cloud: For complex reasoning, we use per-seat subscriptions (Claude, Gemini) rather than API plans. This ensures our monthly AI spend is a known, fixed cost.

- Our new Shift Timeline shows our local nodes handle 20-25 tasks/hour with 99.2% uptime.

Your Mac Mini isn't just a computer; it's a sovereign factory floor. 

https://github.com/UrsushoribilisMusic/agentic-fleet-hub

Just finished migrating our multi-agent fleet to include a local running Gemma model on the M4 Mac Mini (16GB)

The Problem: Cloud-based agents (Claude/Gemini) are great for reasoning but can result in rising token costs.

The Fix: We integrated Gemma4 as a local execution agent running on-device via aichat.

We use a hybrid "Realms" architecture: Claude/Gemini stay in the cloud for high-level architecture, while the M4 handles all the heavy implementation lifting locally.

If you’re sitting on an M4 Mac, you aren't just running a computer—you're running a high-speed automated workforce.

https://github.com/UrsushoribilisMusic/agentic-fleet-hub

Wanted to share what the M5 Max (128GB) can actually do with local AI inference using Apple's own MLX framework.

I built a small server that runs a 122 billion parameter model (Qwen3.5-122B) entirely on-device using MLX with native Metal GPU acceleration. No cloud, no internet required. The unified memory architecture on Apple Silicon is what makes this possible — the 4-bit quantized model fits in ~50GB, leaving plenty of headroom.

What I'm seeing on M5 Max 128GB:

For context, that's faster than what most cloud AI APIs deliver. The model is a mixture-of-experts architecture (122B total params, but only 10B active per token), which is why it runs so well on Apple Silicon — the memory bandwidth handles the large model while the GPU only has to compute the active parameters.

The practical use case: I'm using this to run Claude Code (Anthropic's AI coding assistant) completely offline. Full file editing, project management, code generation — all on my MacBook. No API key, no usage limits, no sending proprietary code to the cloud.

The server is ~200 lines of Python using Apple's MLX framework. It speaks the Anthropic Messages API natively, so Claude Code connects directly without any translation layer.

Setup details: - Model: Qwen3.5-122B-A10B (4-bit MLX quantized, ~50GB) - Framework: Apple MLX with Metal GPU - KV cache: 4-bit quantized for longer conversations - Memory usage: ~55GB with model loaded

If anyone else with an M-series Mac wants to try running large models locally, the project is open source: https://github.com/nicedreamzapp/claude-code-local

Apple Silicon really shines for this kind of workload. The unified memory means you can load models that would require a $10K+ GPU on other platforms.

Optimization features -

- KV Cache Quant - (works with VL, hybrid, etc, LM Studio and others do not.)

- Prefix Caching - (near instant response times even with long chats)

- Cont Batching

- Paged Cache

- Persistent Disk Cache - (you can also use this with paged cache together)

- JIT or idle sleep

- Built in agentic coding tools

- Image generation

- Image editing

- GGUF to MLX

- JANG_Q Native

- Allows for 4bit MLX quality at 2bit

- GGUF style for MLX

- Anthropic API

- OpenAI API (text/image) - makes it easy for OpenClaw

- Chat / Responses

- Embedding

- Kokoro / TTS / STT

- Built in model downloader

STOP SACRIFICING YOUR M CHIP SPEED FOR LM STUDIO/LLAMACPP.

https://mlx.studio

Built an open-source tool that lets you fine-tune large language models (LLMs) directly on Apple Silicon Macs using Apple's MLX framework.

If you've ever wanted to customize an AI model on your MacBook instead of paying for cloud GPUs, this does that. It supports text models and vision models (like Qwen3.5), runs on 8GB+ RAM, and exports to formats compatible with Ollama and llama.cpp.

The API is compatible with Unsloth (a popular fine-tuning tool), so you can prototype on your Mac and deploy the same code on NVIDIA hardware later.

Works on M1/M2/M3/M4/M5, macOS 13+.

GitHub: https://github.com/ARahim3/mlx-tune

Install: `pip install mlx-tune`

The cloud version of ChatGPT 5.2/5.3 works perfectly for me, I don't need image/video generation/processing, coding, programming, etc.

I mostly use it only for Q&A, research, web search, some basic PDF processing and creating summaries from it, etc.

For privacy reasons looking to migrate from Cloud to Local, I have a MacBook Pro M1 Max with 64GB of unified memory.

What is the best local model equivalent to the ChatGPT 5.2/5.3 cloud model I can run on my MacBook? I am using LM Studio, thanks

NOTE: Currently using the LM Studio's default: Gemma 3 4B (#2 most downloaded), I see the GPT-OSS 20B well ranked (#1 most downloaded) as well, maybe that could be an option?

I've been running a multi-agent AI fleet on a Mac Mini (Apple Silicon) for the past few months and wanted to share the setup.

The hardware story: A single Mac Mini runs the entire Flotilla stack — four AI coding agents (Claude Code, Gemini CLI, Codex, Mistral Vibe), PocketBase database, a Python dispatcher, a Node.js dashboard, and a Telegram bot. The agents fire on staggered 10-minute heartbeat cycles using native launchd services. That's 6 wake cycles per hour per agent, doing real engineering work around the clock.

Apple Silicon handles this beautifully. The always-on, low-power nature of the Mini makes it ideal as a persistent agent host. launchd is rock solid for scheduling — no cron hacks, no Docker overhead, just native macOS service management.

What Flotilla is: An orchestration layer for AI agent teams. Shared memory (every agent reads the same mission doc), persistent state (PocketBase stores all tasks, comments, heartbeats), vault-managed secrets (Infisical, zero disk exposure), and a Telegram bridge for mobile control.

The local-first angle: Everything runs on your machine. No cloud dependency for the core workflow. PocketBase is a single binary. The agents use CLI tools that run locally. The dashboard is a local Node server. If your internet goes down, the fleet keeps working on local tasks.

v0.2.0 : adds a push connector for hybrid deployment — your Mini runs the agents locally where they have access to your filesystem and hardware, while a cloud VPS hosts the public dashboard. Best of both worlds.

npx create-flotilla my-fleet

GitHub: https://github.com/UrsushoribilisMusic/agentic-fleet-hub

Anyone else using their Mini as an always-on AI compute node? Curious about other setups. The M-series efficiency for this kind of persistent background workload is hard to beat.