What options do we have realistically to filter out or block unwanted traffic?
What clever schemes can we come up that don't rely on centralised serices like Cloudflare?
Our experiment did have an interesting leaderboard but even more surprising was the measurements of each LLM. We scored each on four behavioral dimensions, two of which lean heavily on an LLM classifier. When we removed those two, one of the frontier models fell six positions. When we then checked the classifier against a second judge, the per-model agreement between them ranged from 85% to 22%. The aggregate kappa (0.04 on probe detection) indicated the instrument was noisy without saying which models the noise was hitting. The most affected model shared a model family with the classifier. This isn't proof of bias, just one observation we recorded.
We realize LLM judges can be unreliable, and while it wasn't our original intent to test this, it ended up being the most interesting finding. The divergence between the two judges is the finding we think generalizes to other judge-based benchmarks.
We emphasize this is just a proof of concept and not a validated benchmark. We prepared a thorough limitations section in the paper, including just 50 runs per model, overlapping CIs among the top models, no human raters, a tiny environment, etc.
Everything we did is publicly available, the paper and data are CC BY 4.0, while the code is MIT. The paper, transcripts, code, and complete API billing export can be found at https://doi.org/10.5281/zenodo.21386663
If you find issues, please let us know, that's why we're sharing this. We're currently designing Phase 2 and want it to be as robust as possible. We're looking at human baselines, multiple judges, more objectives, a larger environment, etc.
The ecosystem is fragmented into a few distinct camps, each sacrificing user experience or runtime compatibility to balance isolation, startup latency, and their own profit margins.
Docker: Heavier and slower because it has to supervise more than web apps. Paying overhead you don't need. MicroVM's: Good isolation, but huge maintenance surface area and substantial overhead. Great for untrusted code, overkill for your own apps. Workerd: Tries to dance around hardware isolation by enforcing an in-process V8 isolate model. Neutered runtime to prevent arbitrary syscall execution. Personally I still find the tradeoff worthwhile for their edge footprint, but I still find myself complaining about it from time to time. Vercel/Managed serverless: Delivers a great developer experience, uses microVM's which is good for compatibility but has a business model that eventually hands you a six-figure bill with a straight face ($0.15/GB bandwidth when budget providers charge cents per TB) and makes you sacrifice statefulness.
These constraints make sense for hyperscalers or enterprises, but I don't have those kinds of needs.
I just wanted something as light and fast as workerd(not exactly but closest i guess), but more rigid than just running them as bare userspace processes. Containers are just standard Linux processes wrapped in namespaces, cgroups, seccomp, and netns. You can do the same with systemd. And with Bun mature enough for production, combining an all-in-one JavaScript runtime directly with native Linux kernel primitives becomes a no-brainer.
So I combined them into Cygnus, a single Rust daemon that turns raw kernel primitives and Bun into a self-hosted, scale-to-zero application platform.
[ CLIENT: HTTP/1.1 · HTTP/2 · HTTP/3 (QUIC) ] | v [ Cygnus Daemon ] ├─ TLS termination (rustls) + ACME manager ├─ H1/H2/H3 front, normalized to H1 upstream ├─ Routing: SNI/Host → ArcSwap<HashMap> ├─ io_uring proxy loop (splice UDS↔TCP) ├─ Cage supervisor (spawn, health, drain, reap, crash backoff) └─ Admin API (root-only UDS) + Tenant-0 bridge (typed commands) | | HTTP/1.1 over per-app UDS (pooled, keep-alive) v ========== CAGE — per app, warm, reused ========== userns · mntns · pidns · ipcns · utsns · netns cgroup v2 (mem/cpu/pids) · seccomp allowlist
bun (text shared via page cache, per version)
├─ preload shim: listen()/Bun.serve → UDS
└─ artifact: bundle.js + bundle.jsc (RO mount)
egress: veth ─ nftables policy ─ host NAT
DNS: host-side forwarder at gateway IP
- ~50ms cold starts with 0 guest kernel overhead - Page-cache shared runtime(low resource usage) - 100% native compatibility(it's literally running bun) - Zero-config setup(injects a listener shim to serve the app, no manual changes needed) - Dogfooded control plane with a great UX and dashboard running as tenant 0
Cygnus uses cages, a shared-kernel process isolation model. The way it currently is, it's designed for trusted code(your apps or apps you trust). It provides defense-in-depth against buggy code, supply-chain attacks, and SSRF. However, it is not designed for untrusted, anonymous multi-tenancy (yet).
I'd love to hear your thoughts on the architecture, kernel primitive choices, and seccomp filtering strategy!
Trying it out is a 1 liner, it works on macOS too but without any of the Linux isolation benefits, for testing it out or running locally.
curl -fsSL https://cygnus.run/install.sh | bash
Github repo has a demo gif if you want to see what it looks like!