public digest · 5 picks
Rust agents, hook-based game engines, and a billing reading list
Five picks this week that share a theme without planning to: each one is someone's strong opinion about what a category of tool should look like. Open Interpreter rewrote itself in Rust and threw out the Python version. Hex Engine bet that hooks are a better model for game objects than class hierarchies. Teleport decided the right answer to SSH key management was to eliminate keys entirely. Opinions, implemented.
The other two are less dramatic but just as opinionated: a billing awesome-list that goes deep enough to cite accounting theory and EU VAT law, and Akamai's internal developer platform layer for Kubernetes that picked a specific stack and wired it together so you don't have to. None of these are neutral tools. That's the point.
// pick 1 of 5
Open Interpreter is a terminal coding agent built in Rust that runs code locally and works with cheap models like Deepseek, Qwen, and Kimi. It's a full rewrite of the original Python project — the Python version is now community-maintained elsewhere. It targets developers who want a Claude Code or Codex-style agent but don't want to pay frontier model prices.
The headline here is the harness emulation system: the same local model can be prompted using the swe-agent strategy, the claude-code strategy, or a minimal baseline, and you switch between them without touching model config. That's a genuinely useful knob when you're trying to run Deepseek or Qwen on real tasks — different prompting strategies have dramatically different success rates on different task types, and being able to test that without changing models is practical rather than theoretical.
The Rust rewrite also matters more than it sounds. The original Python Open Interpreter was notorious for dependency hell and slow startup. A self-contained binary with native sandboxing removes a whole class of 'it works on my machine' problems. ACP support means editors can use it as a backend agent rather than just shelling out to it, which is the right architectural direction.
What to know going in: the README is honest that this is a fork of OpenAI Codex, which means the core agent loop was designed around OpenAI's models. How well those design decisions translate to non-OpenAI models is genuinely unproven at scale. The harness abstraction is the most interesting part of the repo and also the least documented — external docs exist, but the repo itself won't tell you what each harness actually changes about the prompt structure. The Bazel + Cargo hybrid build system is a real barrier for contributors; you need to understand both to add anything non-trivial.
View on GitHub → Our full take →
// pick 2 of 5
Hex Engine is a browser 2D game engine that maps Entity-Component-System onto React-style hooks — every component is a function, behavior is composed via hook calls, and there's a built-in dev inspector. It targets TypeScript-first developers who already think in hooks and want that mental model for game objects rather than learning a new paradigm.
The hook composition model is the right idea for a browser game engine and it's surprising more projects haven't gone this direction. Stacking `useDraw`, `useUpdate`, and `useNewComponent` calls to build behavior reads naturally if you've spent time with React, and it avoids the brittle inheritance chains that make class-based engines annoying to extend. The built-in inspector — a full React app that lets you pause and inspect the entity tree at runtime — is the kind of thing that saves hours of console.log debugging and most browser engines don't bother with it.
First-class Aseprite and Tiled support is a real quality-of-life feature for solo developers. Those are the two most common tools in that workflow, and not having to write your own asset loaders matters when you're one person trying to ship a game.
What to know going in: 678 stars over roughly six years is a signal about community size, not quality — but community size matters for a game engine. When you hit a bug or a missing feature, you're likely debugging it yourself. The build tooling is Webpack with Babel, which is a maintenance liability in 2026 and will eventually require a significant migration. Canvas2D only means you'll hit performance walls before engines with WebGL renderers, and there's no clear path to changing that without a major rewrite.
View on GitHub → Our full take →
// pick 3 of 5
Teleport is a unified access plane for infrastructure: SSH, Kubernetes, databases, RDP, and internal web apps all go through a single identity-aware proxy that issues short-lived certificates instead of managing keys or passwords. It's aimed at teams who want to kill their VPN and bastion host setup and get real audit trails in return. At 20k stars and actively shipping (v18.x), it's not experimental.
The core value proposition holds up under scrutiny: short-lived certificates that auto-expire across SSH, Kubernetes, databases, and RDP from a single auth plane. The practical win is eliminating the key rotation ceremony and the shared credentials that accumulate in authorized_keys files on servers nobody remembers to clean up. That's a real operational problem and Teleport actually solves it rather than wrapping it.
The JIT access request flow is the other genuinely well-designed piece. Users request elevated roles, policy decides whether human approval is required, and the privilege window closes automatically. The 'no manual cleanup step' part matters — in practice, temporary elevated access granted through ad-hoc processes stays temporary only if someone remembers to revoke it. Session recording that works consistently across protocols is also harder than it sounds and Teleport's implementation is more complete than most per-protocol approaches.
What to know going in: AGPL-3.0 covers everything outside /api, which is a real constraint if you're building internal tooling commercially on top of a modified fork — you'd need a commercial license. The community vs. enterprise feature line is blurry in the documentation and you can design an architecture around features that turn out to be enterprise-only. Building from source requires Go, Rust, Node.js, and libfido2 simultaneously, which is a heavier contributor setup than most Go projects. Self-hosting the full cluster topology is operationally non-trivial — the docs are extensive but assume you already know what you're doing with certificate authorities and proxy infrastructure.
View on GitHub → Our full take →
// pick 4 of 5
A curated awesome-list covering the full billing stack: pricing models, usage metering, accounting theory, fraud, taxes, invoicing, and SaaS metrics. Maintained by a single author (Kevin Deldycke) who clearly has hands-on billing system experience. Aimed at developers who need to build or understand billing infrastructure from scratch.
The double-entry and accounting sections alone justify bookmarking this. Most billing resources for developers skip the accounting theory entirely; this one pulls in Kleppmann's accounting-for-CS writing, points at TigerBeetle and Formance Ledger as concrete implementations, and gives you a path from 'I need to understand debits and credits' to 'I need to pick a ledger.' The usage-based pricing section goes similarly deep — including academic papers on Riemann sums and interval algebra that are directly relevant when you're actually building a metering engine, not just specifying pricing tiers.
The consistent annotation of open-source tools with license and maintenance status is genuinely useful editorial work that saves real research time. The EU VAT coverage in the tax section is more specific than most English-language billing resources bother to be.
What to know going in: it's a list of links, not a guide — the connections between sections are implied, not explained, and you still have to read everything yourself to understand how it fits together. Some entries are clearly stale (dead links rescued by Wayback, dormant projects that haven't shipped in years). There's a sponsor placement that shows up twice in the README including inside a content section, which is worth knowing before you treat the tool selections as purely editorial.
View on GitHub → Our full take →
// pick 5 of 5
APL Core is Akamai/Linode's opinionated Kubernetes platform layer — it bundles ArgoCD, Istio, Keycloak, Tekton, Gitea, cert-manager, and a handful of other tools into a pre-wired developer self-service platform. It's aimed at platform engineers who want an internal developer platform on LKE without assembling all the pieces themselves. Think of it as a Backstage-adjacent control plane, but built on GitOps primitives rather than a plugin portal.
The component selection is defensible in a way that a lot of 'opinionated platform' projects aren't: ArgoCD for GitOps, Keycloak for SSO, Tekton for CI pipelines, Sealed Secrets for keeping secrets in git. That's a stack with a real track record. The ADR directory — with entries from 2020 through 2026 — is the most credible signal in the repo: it shows that decisions like dropping SOPS for Sealed Secrets and migrating to Gateway API were made deliberately and documented with rationale, not just shipped and forgotten.
The multi-tenancy model is the practical win: teams get namespaced self-service without touching cluster-admin, which is the actual hard problem for platform engineering teams trying to give developers autonomy without handing out God-mode access.
What to know going in: the automatic installation path is LKE-first and Akamai-flavored — if you're on EKS, GKE, or on-prem, you're on the documented-but-manual path and doing more configuration work than the happy path suggests. The bundled Helm charts are vendored copies pinned to whatever version APL tested against, so you're not getting upstream chart updates automatically and version bumps require PR coordination. Infrastructure provisioning is entirely out of scope — no Terraform, no Pulumi, nothing. You need to bring your own cluster before this tool is relevant.
View on GitHub → Our full take →
That's the week. If you want these in your inbox before they hit the site, the email signup is at the bottom of the page — one issue a week, no noise.
Get this in your inbox →