yet another fun jev experiment... i took a particle fluid simulation, pulled out the part that does the physics (what happens when two particles collide) and let jev handle it at the micro scale. 6.3 million decisions for this one, and the only laws it's told to follow are conservation of momentum and energy, and it never once broke them.

Attention isn't all you need - some attention is. I've been exploring ways to reduce the compute and memory footprint of LLMs. I put it together in a repo: Calibrated Sparse Attention (CSA) is a one-time calibration pass on an existing model that figures out which keys each head in each layer actually uses, and you skip the rest. At matched LM quality I'm seeing potential for: ~10× longer context at the same memory + bandwidth budget ~10× less KV-read bandwidth per token (with a sparse kernel) ~10× fewer attention FLOPs ~10× more requests per GB of KV memory (composed with eviction) No retraining or labels needed.

"Make each program do one thing well" assumed humans were writing them. Slow, deliberate, by hand. Agents flip this. They can author small, single-purpose programs constantly, for one task, for one user, torn down when no longer useful. The philosophy scales in a way its authors couldn't have imagined. But durable work needs somewhere to live. Not a conversation context that evaporates. Not a workflow SaaS built for humans clicking through a GUI. cue is that runtime. Agents push code into it over MCP. Actions they author become callable — by a schedule, a webhook, an app the agent spun up, another agent. Each call runs in a fresh sandboxed VM, so scale doesn't mean blast radius. Here's how an agent OS starts.

Pulled this out of a project I'm working on: unitask: a sandbox for the code your LLM (or your users) generate. Fresh unikernel per call. Super fast boot, run, destroy. I love the Unix philosophy of "make each program do one thing well." With AI in the loop, a program is dynamic and ephemeral, written for one task, run once, then thrown away.

most teams have no view into what LLM calls they're actually making, or how cost breaks down across their business. they can't even try a different provider or model version, locked in by an implementation decision they can barely remember making, and the unknown of how each model behaves is too much. most companies are juggling thousands of API keys and Claude Max subs so employees can use AI. no way to route by use case, no idea which teams are using which models. i've been working on modelux to fix this. the control plane for your LLMs. modelux.ai