Kakehashi is a userspace translation layer that loads macOS ARM64 binaries and runs them on Linux aarch64, with no virtual machine, no emulator and no JIT. It surfaced on Hacker News on August 2 and took 214 points and 55 comments, which is a lot of attention for something the author labels experimental. The goal is narrower and more interesting than the headline suggests. Continuous integration jobs that need Darwin command line tools currently have to run on macOS runners, which are scarce and cost roughly twelve times what a Linux ARM64 runner does. Kakehashi is an attempt to move those jobs off Apple hardware.
The short answer
Kakehashi is a userspace macOS ARM64 to Linux aarch64 translation layer written in Rust and licensed Apache 2.0. It loads Mach-O executables, maps a freestanding libSystem, and translates BSD system calls, with no JIT and no virtual machine. Verified guests today are 7-Zip, including multi threaded compression, curl over HTTPS with OpenSSL, and clang probe fixtures. Missing pieces include the full curl feature set, Security.framework, GUI support, git and the Xcode Command Line Tools, and codesign or notarization. The stated goal is running Darwin command line tooling on cheap Linux aarch64 CI runners instead of scarce macOS capacity.
The awkward part of any pipeline that has to touch Apple software is the runner bill. Most of the job is ordinary work that any machine could do, one step needs a Darwin binary, and that one step drags the whole job onto expensive and frequently queued macOS capacity. Kakehashi, which reached the Hacker News front page on August 2 with 214 points, is an attempt to break that dependency at the binary level.
What it is doing, and what it is not
The name of the problem matters here, because it is not the one people assume.
Apple silicon binaries are already ARM64. Running one on a Linux ARM64 machine does not require translating a single instruction. What it requires is convincing the binary that the operating system underneath it is Darwin, which is a much more tractable problem than emulation and a much less tractable one than it sounds.
Kakehashi does four things to get there. It parses and maps Mach-O, the executable format macOS uses instead of ELF. It provides a freestanding libSystem, the library every Darwin binary links against for its runtime. It translates BSD system calls into their Linux equivalents. And it bridges filesystem paths, exposing the host through a /Volumes/linux/ path so a Darwin binary can reach Linux directories.
There is no JIT and no instruction emulation anywhere in that list. This is a compatibility layer in the sense that WINE is one, pointed in an unusual direction.
The architecture
The repository splits into four crates, and the split tells you where the work is.
kakehashi is the CLI users install. kh-loader handles Mach-O parsing, mapping and execution. kh-runtime owns memory, traps, BSD system calls and the embedded dylib. kh-libsystem is the source of the freestanding dylib, which is the only piece built for aarch64-apple-darwin rather than Linux.
That last detail is neat: the guest dylib is compiled for Darwin, then vendored into the Linux runtime binary through include_bytes, so the thing that gets shipped is a single Linux executable carrying a Darwin library inside it.
What runs, and what does not
The verified guest list is short and the project does not oversell it.
7-Zip works. Creating archives, testing them, extracting them, and multi threaded compression exercised with 7zz and mmt=4, which is worth noting because threading is where a half finished syscall translation layer usually falls over. curl works for HTTP and HTTPS with OpenSSL and CA bundle handling. There are clang probe fixtures that demonstrate basic compilation.
Now the other column. curl is partial: POST bodies, proxies and HTTP/3 are all listed as not working. Security.framework is absent, so anything reaching for keychain or Apple's trust APIs is out. There is no GUI support, and the project is explicit that it is command line first. git and the Xcode Command Line Tools do not run, although git is named as a goal by way of the Xcode tools.
codesign and notarization are also unimplemented, and that pairing is the honest limit of the current design. A macOS release pipeline typically ends by signing and notarizing, both of which talk to Apple services through Apple frameworks. Kakehashi can plausibly take over the build and archive steps long before it can take over the last one.
The named next step is git, delivered through a kh install xcode-tools guest. That is the right thing to reach for next, because git is the one Darwin command line tool almost every pipeline touches.
The arithmetic that justifies it
Performance first, because it is the objection everyone raises. On Ubuntu aarch64 running bare metal under UTM, a multi file 7-Zip archive over roughly eight thousand files and 240 MiB took about 22.5 seconds natively and about 118 seconds under Kakehashi. That is the 5.2 times figure.
The project is careful about where that number comes from, and the caveat is worth repeating. On compression heavy samples with few files, the gap narrows to around 1.1 to 1.2 times. The large multi file gap is dominated by path walking and the per syscall boundary, not by the compression itself. In other words the tax scales with how chatty the guest is, not with how much work it does, which is exactly what you would expect from a syscall translation layer and not at all what you would expect from an emulator.
Then the prices. The project quotes GitHub Actions hosted runner rates for private repository overage: 0.005 dollars per minute for a Linux two core arm64 runner, against 0.062 dollars per minute for a macOS three or four core runner, with larger macOS runners between 0.077 and 0.102. That is roughly ten to twelve times the Linux arm64 minute before any wall clock difference enters the picture.
The illustrative sum the project offers is the clearest way to see it. Five minutes on Linux arm64 at 0.005 is about 0.025 dollars. One minute on macOS at 0.062 is 0.062. A job running five times slower still costs less than half as much.
Whether you take that trade depends on what you are optimising. If a developer is waiting on the result, five times slower is painful. If it is a nightly job, a matrix build, or anything where the bill and the queue matter more than the clock, the maths is favourable before you even count the scarcity of macOS capacity, which is what makes those runners queue in the first place. The project is also clear about when macOS runners still win outright: anything involving a GUI, codesign or notarization, or Xcode UI tests.
Where we would place it today
Kakehashi is a Rust project needing a 1.88 or newer toolchain, licensed Apache 2.0, installed with cargo install kakehashi and then driven through kh bottle ensure and kh install. It runs on Linux aarch64, bare metal or virtualised, on 4 KiB or 16 KiB page sizes.
What it is not, yet, is something to put in front of a pipeline you depend on. The gap between running 7zz and running a real Darwin toolchain is wide, and the missing pieces are not decoration.
What makes it worth watching is that the approach is sound and the scope is disciplined. Someone looked at the CI runner problem, concluded that the actual obstacle is the operating system interface rather than the instruction set, and started translating the interface. If the git and Xcode Command Line Tools goal lands, the set of jobs that genuinely need Apple hardware gets smaller, and that is a useful thing for anyone who has watched a build queue for a macOS runner.
Sources and further reading
Frequently asked questions
How is this different from a virtual machine or from Rosetta?
Rosetta translates x86 instructions so they run on ARM hardware, which is an instruction set problem. Kakehashi does not translate instructions at all. The binaries are already ARM64, they simply expect Darwin rather than Linux, so what has to be translated is the operating system interface: the Mach-O executable format, the dynamic linker behaviour, the libSystem the binary links against, and the BSD system calls it makes. That is why there is no JIT and no emulation layer. A virtual machine solves the same problem by running an entire macOS guest, which needs an Apple licence, Apple hardware and a full operating system boot. Kakehashi runs the binary as a Linux process.
What actually runs today?
The verified set is small and honest about being small. 7-Zip works for creating, testing and extracting archives, including multi threaded compression tested with the 7zz flag mmt=4, which means threading is functional rather than stubbed. curl works for HTTP and HTTPS requests with OpenSSL and CA bundle support. There are clang probe fixtures demonstrating basic compilation. Host filesystem access is bridged through a /Volumes/linux/ path so a Darwin binary can reach Linux paths. That is enough to prove the approach and nowhere near enough to run a real macOS build.
What does not work?
The list is longer than the working one, which is what experimental means. curl is partial: no POST bodies, no proxies, no HTTP/3. Apple's Security.framework is absent, which rules out anything touching keychain or system trust APIs. There is no GUI support at all, and the project is explicit that it is command line first. git and the Xcode Command Line Tools do not run yet, though git is named as a goal. codesign and notarization are not implemented, which matters because those are exactly the steps a real macOS release pipeline ends with.
What is the performance and cost trade off?
The project measured a multi file 7-Zip archive over roughly eight thousand files on Ubuntu aarch64 at about 22.5 seconds natively against about 118 seconds under Kakehashi, a ratio of 5.2. On compression heavy samples with few files the gap narrows to around 1.1 to 1.2, because the cost is the per syscall boundary and path walking rather than the compression work itself. Put that next to the GitHub Actions rates the project quotes: 0.005 dollars per minute for a Linux two core arm64 runner against 0.062 for a macOS three or four core runner. Five minutes of Linux arm64 is about 0.025 dollars against 0.062 for one macOS minute, so a job running five times slower still costs less than half as much.
How do I try it, and what do I need?
It is written in Rust and needs a toolchain of 1.88 or newer, and it installs from crates.io with cargo install kakehashi. After that, kh bottle ensure fetches the runtime pieces and kh install pulls a guest, for example kh install 7zip or kh install curl. The host has to be Linux aarch64, which can be bare metal, a virtual machine, or Colima or Docker, with a 4 KiB or 16 KiB page size. The licence is Apache 2.0. Treat it as something to evaluate on a spare runner rather than to put in front of a pipeline you depend on.