antirez Ported MiniMax H3 to Apple Silicon — in C and Metal

On August 10, 2026, Salvatore Sanfilippo — antirez, the creator of Redis — published h3.c: MiniMax's H3 video model running natively on Apple Silicon in C and Metal. MiniMax reposted it with a line worth keeping: "You can't hire this, you can only open-source and let it happen."

The MiniMax post hit 139.6K views in under twelve hours. But the interesting part isn't the celebrity contributor — it's the specific thing that became possible. H3 shipped as open weights on August 3, 2026; seven days later it ran on a Mac in a language the original lab never targeted, through an engine nobody paid for. That is the entire open-weights argument compressed into a week.

TL;DR

What antirez actually built

Not a wrapper. h3.c is described in the README as "Native MiniMax-H3 inference for Apple Silicon," developed as "a sequence of working vertical slices: deterministic host/model metadata first, then portable Metal block parity, prompt encoding, prompt-to-video/audio, and first/last-frame conditioning and then ordered references."

That ordering is the craft. Each slice is independently verifiable — metadata parity before block parity before generation — which is how you port a diffusion pipeline to a new backend without spending three weeks debugging a silently wrong tensor layout.

Supported generation paths:

The 5 + 17n constraint is the kind of detail that only shows up when someone reimplements a model rather than calling it — it's H3's temporal block structure leaking into the API surface.

The performance numbers

Benchmarked on a 128GB M5 Max, 512×512 at 22 frames:

The memory engineering is the underrated part: the M5 implementation uses "persistent transformer weights mapped directly from safetensor shards" instead of copying into anonymous buffers, and a native int8 quantization path cuts peak tensor storage while holding visual coherence across the test sequences.

The README also advises changing "one control at a time when evaluating quality" and ships validated presets rather than aggressive defaults — the same conservative-defaults instinct that made Redis pleasant to operate.

Why this is a bigger deal than one repo

The reply that got it right, from the thread: open weights are "a bat signal for obsessive engineers: release the model, go to sleep, wake up and someone has already made it run faster on hardware you never optimized for."

Within a day, a Swift/Metal implementation also appeared from another developer. Two independent Apple Silicon ports of a Chinese video model in roughly a week — neither commissioned, neither on MiniMax's roadmap.

This is the pattern we've tracked across local inference: Kimi K3 on M1 Max, Gemma 4 in 2GB of RAM, and 1-bit quantization work like HY3 GGUF on a single GPU. The models are Chinese; the portability work is global and unpaid.

The honest counterpoint — also from the thread — is that open-sourcing doesn't guarantee a Redis-level engineer shows up. It's mostly luck. Open weights buy you a lottery ticket, not an outcome. Most open releases get zero third-party ports. What they do guarantee is that the ticket exists at all: no amount of API generosity lets an outsider rewrite your inference kernel.

The license question nobody in the thread raised

Here's the part worth sitting with. MiniMax's H3 Community License Agreement excludes the European Union, United Kingdom, Republic of Korea, and United States of America from its "Applicable Territory" for local deployment — a restriction we covered in detail in the H3 open-weights post.

antirez is Italian and works from Sicily — in the EU.

To be precise about what this does and doesn't mean: h3.c is an independent, MIT-licensed inference engine. It ships no weights, and writing software that can load a model is not the same act as deploying that model under a restricted license. The territorial terms attach to obtaining and running the weights, and that obligation lands on whoever downloads them.

But the optics are worth naming plainly: MiniMax publicly celebrated a contribution from a developer in a region its own license bars from running the weights locally. If "open weights mean anyone can bring H3 to any hardware," the license currently says anyone except roughly the EU, UK, US, and South Korea. Both things are in the same week's news cycle, and the second one is what an enterprise legal team will find.

Practical guidance: if you're evaluating h3.c for anything beyond personal experimentation, the engine's MIT license is not your constraint — the weight license is. Check the Applicable Territory clause against where your machines and your company are, and note that MiniMax offers separate commercial licensing by application.

What people are asking

"As a non-coder, what does this mean?" — It means a video-generation model that normally runs in a datacenter now runs on a high-end Mac laptop, in about 3.5 seconds per short clip, without sending anything to a server. That's a privacy, cost, and latency shift, not just a benchmark.

"Do I need a $5,000 Mac?" — Effectively, yes, for the full path. Peak memory of 26–36 GiB rules out base-configuration machines. One reply argued that anyone who can afford a 64GB+ M-series Max is rich enough to just buy the highest AI subscription tier — fair as economics, wrong as reasoning. Local inference buys no rate limits, no per-second billing, no data leaving the machine, and no territory clause on the API. Those aren't subscription features.

"Is this production-ready?" — No, and it doesn't claim to be. Vertical-slice development means the engine is deliberately incomplete. It targets roughly 4–15 second videos, and the author notes short clips are primarily useful for development iteration.

"Will this help Draw Things?" — antirez explicitly noted that h3.c "contains code from [liuliu] which is welcomed in taking back whatever parts he likes" for Draw Things, if H3 support is ever planned there. Bidirectional borrowing between MIT projects — the low-drama version of open source.

Update — the ComfyUI comparison is the real benchmark

h3.c reached the Hacker News front page on August 11 with 266 points and 49 comments, and the discussion surfaced the number that matters more than any README figure: what people were doing before.

An order-of-magnitude difference against the tool most Mac users actually run. One M4 Max user reported roughly 1/5 speed improvement on a first pass after switching — less than antirez's own numbers, but on different silicon.

On memory: the README's 40.1 GB peak footprint for end-to-end image+audio renders suggests 64GB machines are workable. antirez confirmed h3.c "could be executed on 64GB with a few changes" — not currently supported, but not architecturally blocked. When a commenter attributed the M5 Pro/Max gap to memory bandwidth (300 GB/s vs 600 GB/s), antirez's answer was blunt: "Does not matter much in this case. GPU bound."

What's coming: antirez is testing a --sparse-attention mode based on MiniMax's own statement in a Reddit AMA that H3 could support sparse attention — potentially another large speedup.

Also worth noting: the tutorial added a native 256×256 preview canvas that automatically halves spatial RoPE coordinates, which removed repeating lattice artifacts in long renders. Native 128 remains unsupported — its 4×4 token grid couldn't recover a recognizable subject even with adjusted RoPE. That's the kind of finding you only get from reimplementing rather than wrapping.

The counterweight, from the same thread: an RTX Pro 6000 does the 15-second 480p job in 2–3 minutes. Unified memory is still far behind discrete GPUs on diffusion workloads specifically — the gap is much wider here than for LLM inference. h3.c narrows a Mac-versus-Mac gap dramatically; it does not make a laptop competitive with a workstation GPU.

What to actually take from this

• Open weights are an option on a future you can't schedule. MiniMax's phrasing — you can't hire this — is marketing, but it's structurally true. A closed API forecloses third-party kernel work entirely.
• C and Metal are back on the table. No Python, no PyTorch, no framework tax for inference. That matters for shipping models inside apps rather than beside them.
• Portability is a real competitive axis for model labs. If Chinese labs keep publishing weights while US labs keep publishing endpoints, the hardware coverage story diverges fast — a theme running through the open vs frontier gap debate.
• Licenses are the actual bottleneck now, not capability. The most interesting constraint on H3 in August 2026 isn't VRAM. It's a territory clause.

For the model itself — specs, benchmarks, and full license terms — start with our MiniMax H3 open-weights breakdown. For the agentic video side, see ViMax.

Related on explainx.ai

• MiniMax H3: open weights, license excludes US/EU — the model h3.c runs
• Kimi K3 on Apple Silicon M1 Max — the same local-inference push, LLM side
• Gemma 4 in 2GB of RAM — extreme-constraint local inference
• HY3 GGUF: 1-bit and 4-bit on a single GPU — quantization as portability
• ViMax: agentic video generation — orchestrating video models
• Open vs frontier AI gap — the strategic backdrop
• WorldClaw runs on Claude Opus 4.8 — the other side of the open/closed split

Official sources: antirez/h3.c on GitHub · MiniMax-H3 on Hugging Face

Accurate as of August 11, 2026. Repository stats (796 stars, 38 forks, 120 commits) and benchmark figures are from the h3.c README at time of writing and will change; the project is under active daily development, so presets and flags may shift. License terms are summarized, not legal advice — read MiniMax's Community License Agreement before deploying.