Interesting! So based on architecture[1], the daemon responsible for container… scheduling(?) works directly with the VM. There's no traditional init system. The "guest agent" is the initd (kind of a unikernel, huh?) so the overhead of spawning a container is as directly through the kernel syscalls as possible while the other bits happen on the macOS host?

The question I have is, does that mean Kiri implements its own entire container runtime or does it use containerd or some other runtime as its backend?

[1]: https://docs.runkiri.com/features/#what-runs-where