I love the idea of complementing the user's shell. Augmenting their experience rather than attempting to hijack it. Our latest experiment allow you to insert a path to ✨anything, anywhere✨ with instant fuzzy matching as well as traditional path navigation. As useful for your `cat` as your `claude`.

The Complete Guide to pstack Pt. 1

Opus 5.5 on Max effort - "make a dynamic 15-second motion graphics video that shows what an incredible motion designer you are, like it's your showreel for a résumé. go all out." https://t.co/nWPOFUOlvr

Antigravity 2.0 now features a dedicated planning mode, just like the Antigravity CLI. Type /plan and the agent steps back to think through the task, and conduct extensive research, before generating an implementation plan for your review. The agent will ask for your approval before it begins executing on the task. You can also ask for a plan naturally in your prompt, for a lighter version of a plan.

The company that makes these SXM4 connectors for A100's have ceased production. Plans have been made to invest in, and create new tooling to begin our own connector production and supply the market into the EOL connectors and hundreds of physically damaged A100 sxm modules. https://t.co/lNyFh57eZR

If your sandbox is DNS, you belong in prison, along with your models. My own LAN is literally more professionally secured than this.

TensorFold Inference Engine is here 🚀 I spent six months making one weight read count for more than one token on Apple Silicon. Draft tokens run through parallel lanes; the model verifies them together and keeps only what passes. Qwen 3.8 27B MLX 4Bit - 120-124tks Nemotron Lightning MLX 4Bit - 188-206tks Qwen3.8 Flash Next MLX 4Bit - 88-92tks CUDA Implementation is in Alpha showing strong gains. The Repo is in the comments 👇🏼

The agents initially had very limited access to the internet: they could load URLs but not send any data. Agents created a series of workarounds, using a link-shortener site to create almost a million URLs that, when chained together, let them execute code to hack Hugging Face. https://t.co/kj68uzgxdI

you can use Jev judgments to build your own “embedding” of agent traces where every dimension has a name. E.g. conversation signals from chat agents: [user_frustrated, follow_up, corrected_agent, satisfied] [0.7, 0.8, 0.1, 0.0] Now you can cluster or search sessions like “frustrated users who had to correct the agent,” and see exactly why each one matched. Works both ways too: search for the happy users. Just as important to see what’s going right :)

it's f*cking insane Jev sat between GPT and me, killing every draft that broke my rules before i saw it. good setup. then Jev did not answer. the agent decided silence was safer and stopped sending me anything at all. took a second agent to unstick it. your checker needs a branch for the moment it goes quiet: > let it through tagged unverified and keep moving > hand the risky span to the big model > park it in a queue and retry in a minute > wake a human when the action is irreversible 70-500 ms one Jev call, by TypeSafe's own number. a half-second checker still takes down the whole pipeline when it has no default.

I’ve been experimenting a bit with Jev as a fuzzy linter that runs after edits in your agent harness: looks very promising so far in my evals. First I converted all of our coding guidelines to tiny rules that are very easy to judge. Then, only kept the ones that don’t require extra context/files/reasoning. I want it to be a single call, super fast, and Jev isn’t smart enough to handle complex or ambiguous rules. I then created a synthetic eval that has different kinds of tool calls to exercise and test every one of those rules. Also a held out set that we don’t train on so we don’t accidentally overfit (ie benchmax). One cool thing that seems to work well: Jev returns confidence, so in addition to high confidence violations, we can also return medium confidence and get the agent to double check. Adding that lower confidence tier seems to double what it catches, and only increases false positives a little. I still have yet to test this inside an actual agent to see how the agent reacts to this feedback. Hopefully next week I can get a decent eval going and see how well this works E2E.

jesus one-shot christ https://t.co/iACCP3CVde

I feel retarded for not knowing about OMO going full PI. OmO 5.0 now runs on a fork of badlogic's pi, and the onboarding alone sold me. First it gives you a feature tour and handles migration if you're coming from OpenCode. Then it asks before digging through your past sessions, mines them for how you actually work, and works out how much you've saved on cache from its own logs. It saves what it learns to memory and ends with a send-off. After that, ulw reads the repo, plans, and proves every step. mass ulw turns one job into a graph of agents, each on the right model. 69k stars and I'm this late. @q_yeon_gyu_kim https://t.co/lo0X0LQWyc

Why I'm Building Muse

SCOOP: OpenAI, Anthropic and security researchers are investigating tens of thousands of incidents - not dozens - in which their frontier models took steps that outside evaluators would consider problematic, sources told Axios. The sheer volume of incidents found in our reporting indicate that the problem is orders of magnitude more complex than what is currently publicly known and disclosed. The findings also raise questions about what level of control anyone working on AI development can expect to have over their own technology, and whether these kinds of incidents are becoming synonymous with frontier deployment. Read my latest for Axios here: https://t.co/42h9aR4sem

A humble attempt to est. the infra required to serve 100M DAU @Muse Rough conclusion is: 1 GW of power to serve 100M DAU in the base case, of which only ~0.1 GW comes from the CPU/VM layer. Depending on the # of reasoning-equivalent model calls one Muse DAU generates per day, 3-4GW is entirely plausible. Maybe that’s why @Meta is rumored to be adding 7-10GW of compute next year. The sandbox layer = sub $1B of CPU content and ~$2B of DRAM content, which is much smaller than many expected. Lot of moving assumptions. Welcome all feedbacks/ pushbacks. ------ Two very different pieces of infrastructure behind Muse. 1. Muse VM / sandbox infrastructure 2 vCPUs, ~8 GB of RAM and ~100 GB of persistent logical storage per user. https://t.co/7rP5vDKnT7 2. Muse Spark inference Model inference goes out through Meta's external inference infrastructure. https://t.co/e203XUp6jq ------ 1/ Sandbox infrastructure A. CPU The first mistake is assuming that 100M DAU means 100M VMs are actively consuming compute at the same time. Suppose the average Muse DAU has an agent actively working for two hours per day. 100M users * 2 hours / 24 hours = ~8M average simultaneous active VMs Meta obviously cannot provision only for the daily average. Usage will be concentrated during waking hours and bursty. Assume a 2.5x peak-to-average ratio: 8M * 2.5 = ~20M peak active VMs Then add roughly 20% capacity headroom: ~25M provisioned live VMs. So the base assumption is effectively that Meta needs enough infrastructure to support roughly 25% of DAU being live simultaneously. The next important distinction is between virtual CPU allocation and physical CPU demand. Agent sandboxes are particularly well suited to CPU oversubscription. They spend a lot of time waiting. During those periods, the VM may still be alive, but it is barely using CPU. DeepSeek’s recently published DSec infrastructure provides a useful benchmark. Its production agent sandbox platform runs approximately 30,000 physical CPU cores and 250TB of DRAM across ~160 nodes, with peak concurrency above 380,000 sandboxes. https://t.co/PFlgc6nnUs DSec also demonstrates stable operation at around: 800 microVMs per node. With roughly 188 physical cores per node: 188 physical cores / 800 microVMs = ~0.23 physical cores per live VM. DeepSeek is obviously the King of efficiency. The number for Muse might be at 0.3-0.75 physical cores per live VM, or assume 0.5 physical cores per live VM as the base case. That is equivalent to roughly two simultaneously live Muse VMs per physical CPU core. Using the base assumptions: 25M live VMs * 0.5 physical cores per VM = 12.5M physical CPU cores. On a 256-core CPU: 12.5M cores / 256 cores per CPU = ~50K CPUs; Or on a 192-core CPU that would be 65K CPUs. At the current public pricing, that is ~$800M. B. DRAM CPU can be aggressively oversubscribed because a VM that is waiting may consume almost no CPU. Memory is harder to oversubscribe because a live VM still needs to retain its working state. Muse exposes roughly 8GB of RAM to the user environment, but one observed instance was actually using only around 3GB at the time of measurement. 25M live VMs * 3GB = 75PB of physical DRAM, call it ~75-100PB of physical DRAM feels like a reasonable base range. At the current public pricing, that is ~$2B. C. Sandbox power ~0.1 GW for the entire Muse sandbox / VM layer at 100M DAU. ------ 2/ Inference Muse’s personal computer executes tools and stores state locally, but the actual model runs on separate inference infrastructure. Meta’s Muse architecture Energy per inference event Microsoft’s 2026 study estimates that optimized frontier-scale inference consumes a median of approximately: 0.31Wh per normal query But a long reasoning query with roughly 15x the token count consumes approximately 13x as much energy, or around: 4Wh per long reasoning query The study specifically highlights reasoning and agentic workloads as significantly more energy intensive. https://t.co/z1YEsvVeMo Sensitivity analysis on # reasoning-equivalent events per DAU per day Suppose each active @Muse user generates the equivalent of 50 heavy inference events per day. At 5Wh each: 100M users * 50 events/day * 5Wh = 25GWh/day 25GWh/day / 24 hours = ~1.0GW average power So inference alone could require: ~1-2GW of average power A 3-4GW Muse is entirely plausible. Maybe that’s why @Meta is rumored to be adding 7-10GW of compute next year. ------ The popular framing around Muse is that giving every user 2 vCPUs and 8GB of RAM creates an enormous CPU requirement. But the naive calculation materially exaggerates the CPU requirement because it treats logical VM allocation as dedicated physical infrastructure. The more interesting conclusion is: Consumer agents may be a meaningful new demand driver for CPUs and conventional DRAM, but inference remains the real compute bottleneck. And as agents do more work, run longer trajectories and increasingly spawn other agents, inference demand can scale much faster than the number of users itself. +++ Calling my peer review group: @bubbleboi @damnang2 @Midnight_Captl @FundaAI @fi56622380 . Feedback/ Pushbacks pls :). ++ Better formatted: https://t.co/qVwYKNr1ZA