Head of SRE at @leaf_space . Space engineer (ground stations · ExoMars · Galileo). I benchmark AI models for DevSecOps and developers.

Earth
Fable 5.1 is in DevBench. On the developer track it jumps from a collapse to second place. 1. Opus 4.8 → 94.4 2. Fable 5.1 → 92.5 3. Grok 4.5 low → 92.5 Fable 5 was unusable on this suite. Bug fixing, refactoring and review were close to zero because it refused most of those cases. 5.1 actually does the work. It scores 98 on bug fixing, 99 on refactoring and stays strong across Python, TypeScript, Go and Rust. The catch is the price. Fable 5.1 cost $34 on this run. Opus did it for $11. Grok 4.5 low matched the 92.5 score for $3. So 5.1 is now a real coding model again. It is just a very expensive one. For a planner or a hard review pass, that can make sense. For the rest of an agent stack, a cheaper model still does the job. Results: dev-bench.phybyte.space/#/re…
4
524
Rocket Lab is clearly running the SpaceX playbook: own the launcher, own the spacecraft, own the constellation, own the customer. With Iridium, they get the last two pieces in one move. But there's a big difference. SpaceX built Starlink from scratch, inside the same company, with the same engineers, the same culture and the same leadership. Launch cadence, satellite design and ground network were shaped for each other from day one. Rocket Lab is buying a mature operator with 25+ years of its own processes, its own teams and a constellation that was designed and launched without Rocket Lab involved. Fun fact: Iridium NEXT went up on Falcon 9. Vertical integration on paper is easy. Making two organizations move at the same speed is the hard part. Different tooling, different release cycles, different risk culture. An operator running a critical 24/7 network doesn't think like a launch company pushing cadence. The real test isn't the close in 2027. It's whether the next generation of Iridium satellites is designed around Electron and Neutron, and whether both teams end up operating as one.
It’s official: @IridiumComm shareholders have voted and approved the acquisition by Rocket Lab ✅ By joining forces, we’ll be creating a vertically-integrated space powerhouse that designs, builds, launches, and operates its own constellations to bring critical communications capability to millions of users worldwide. Full details and next steps: bit.ly/3T53qq1
1
5
332
Great coordination between the team and the community, we are back!!! If you want to support dont forget to stack on @CryptoBaySpace !!!
After carefully reviewing yesterday’s logs, our engineering team confirmed that the recovery hard fork completed successfully. It does not need to be repeated. Validators are now upgrading and synchronizing for the coordinated restart. Please continue to wait for the separate all-clear before submitting transactions. Thank you to our validators, partners and everyone standing with us through these difficult days. We keep building, together.
3
9
92
1,491
I got tired of watching people announce opposite views from the same repo. Reading the code is useful. Running it is better. So I turn up a private local chain and tested the off switch myself. Two doors. The local command is dead on mainnet. 404. The gossip path still works, one signed message stopped a node. Then it stopped three. That is not what halted mainnet on Sep 19. I was in the validator chat. Operators stopped their own machines by hand. The switch existing and the switch being pressed are different claims. @Justin_Bons was right that it exists. @SasuRobert was right about the channel, and wrong that there is no off switch. @vinibarbosabr already put the files on the table. I pressed the button to verify it all... @MultiversX @CodeMultiversX
5
18
98
8,144
Why is it even there? This looks like an old emergency hard-fork tool, not a hidden implant. After a bad state you need a way to freeze nodes, export, and restart from a clean point. That is a reason to build it. It is not a reason to leave a single key in the default config for six years with no public custody. The key in the files is only a public key. I cannot prove anyone still holds the matching private key. I cannot prove the foundation holds it. I cannot prove it is lost. No published custody, no rotation log, no on-chain record. “Who owns the switch” is unproven. We will probably never know. What is proven is narrower: the door is in the software, gossip is on, the signature check works, and closing the API does not close that door. It is not removed yet. After this went public, @SasuRobert opened a change to delete the whole feature: config, API route, gossip hook. That merge request is still open. Until it lands and validators run that binary, the door I tested is still in the tree. You can call the old design an acceptable emergency tool. Just say that. Do not say the door is not there. Test Yourself : github.com/PhyByte/MVX-OFF-S… Pending Removal: github.com/multiversx/mx-cha…
1
1
18
553
There’s a lot of talk right now about MultiversX downtime, off-switches, first halt, all of it. Fine. Let’s go through what actually happened since launch, six years ago, from a validator’s chair. I’ve run a node since day one. Before it was MultiversX. When the chain was still Elrond. You remember the weekends more than the marketing. The nights Telegram lights up. That’s the job. People talk this week like the chain never broke before, or like someone pressed a button on my servers. Neither is true. December 2021 — RIDE Nobody asked us to stop nodes. The chain kept making blocks. Listing traffic, bots, timeouts. Unusable for hours. Congestion. Consensus downtime: none. I didn’t reboot the server. June 2022 multiversx.com/blog/incident… VM bug. executeOnDestContextByCaller in a callback. Same shard. ~1.65M EGLD out of the wrap contracts, dumped on Maiar. They paused DEX, WEGLD swap, bridge, public API send. Not the chain. The report says the blockchain was never turned off. Own API still worked. In-place upgrade, most nodes on the new binary in ~30 min. Users made whole. Consensus downtime: none. Apps dark ~2 days. May 14, 2025 multiversx.com/blog/sc-bug-i… First real consensus halt. transferValueAndExecute. Missing check. Huge wrapped USDC credit, then USDT. They called verified / red-line operators, community delegation, 25+ SPs. Enough to break 66%. Quorum died. Patch v1.8.13.0. Back in 2h30. 99.999% recovered. No users directly affected. I wasn’t on that call. If you weren’t in that group you just watched it stall. Consensus downtime: 2h30. September 19, 2026 nitter.net/MultiversX/status/2101… Same idea, bigger. VM atomicity. Invalid state already on chain. Official line: order-of-operations on an edge case. This time they asked everyone to keep mainnet nodes down. Hard fork from a checkpoint. That’s why it’s days, not two hours. I stopped my own nodes after the announcement. Nobody flipped a switch on my servers. I can still refuse the upgrade. PublicKeyToListenFrom in my config.toml is empty. I never cleared it. Should be back this afternoon. Call it ~4 days. ~96h. The map 2021 RIDE: consensus 0 2022: consensus 0, apps ~2 days 2025: 2h30 2026: ~96h, restart this afternoon SLA since launch: Since genesis (July 2020.) : ~98.5h down → about 99.82% uptime. Since 1 Jan 2026: only this one → about 98.5% this year. We’ve had incidents. We’ve had downtime. This is just the first time it stayed down more than a few hours. Not a fairy tale about a button. Those are the facts.
Update: We have confirmed that a actor attempted to exploit a VM-level atomicity issue. The attempt caused invalid state changes, and network progression remains paused to prevent any further impact. Engineering has prepared a fix and will validate it on a shadow fork. Subject to successful testing, deployment to Mainnet will be coordinated with validators, exchanges and infrastructure partners. In parallel, we are evaluating a targeted recovery approach designed to preserve finalized transaction history and legitimate user state while addressing only incident-related invalid changes. No action is required from users beyond waiting for the all-clear. Please do not submit or rebroadcast transactions, or use EGLD and ESDT deposit and withdrawal routes through exchanges or bridges. We will communicate again when there is confirmed progress to share. A full technical incident report will be published once the response is complete and the findings have been finalized. Thank you for your patience and continued support while we work through this.
12
39
143
8,528
Running a node since D1 here. We stopped ourselves after the announcement. Nobody has a button on my machine. And I can still say no to the upgrade if I want. The tokens that hit exchanges got locked. They weren’t sold. Of course there was a hack, I’m not pretending there wasn’t. I just don’t see the story people are spinning. Team and validators spent the weekend cleaning it up. Ugly, we lost 100% uptime, but nobody’s funds disappeared.
EGLD has been totally exposed for its lies & hidden centralization today! ⚠️ 3 days of downtime is only the tip of the iceberg: 76M EGLD (2.5x supply) was minted & partially sold! EGLD did not halt; the foundation used an off-switch! All consequences of its reckless design! 🧵 Unlike a normal chain halt, where the chain stops due to a "consensus failure/disagreement", this was far, far worse. Instead of the chain stopping because an "inflation bug" caused consensus to fail, it kept going... That is what allowed the hacker to actually send their EGLD into exchanges & cause considerable harm. What comes next is even more unbelievable. As I was wondering how it was even possible to shut down a chain with 3k validators in 66min... That is what made me uncover the next bombshell: There is a literal foundation-controlled off-switch in the code!!! The Off-Switch Every mainnet node runs with a hard-fork trigger enabled that listens for a message signed by one specific public key. That is a remote stop switch held by the Foundation! We cannot know for sure if they pressed that switch, but it is highly unlikely they could have stopped the chain that quickly otherwise & the fact that it even exists is bad enough! This is all a direct consequence of the shortcuts they had to make to bring a sharded chain down to 600ms... Reckless Design Sharding comes with certain trade-offs: EGLD claimed to overcome these trade-offs through its unique design. Turns out, in reality, those trade-offs had some extreme consequences we are feeling now: EGLD sharding splits every transfer into a sender-shard debit & a destination-shard credit that must be reconciled by hand, & on one path the credit had no debit: a money printer. With no global supply invariant, finality before execution, & no protocol-level freeze, the only fix was manually shutting down the chain & a hard fork erasing the "final" history! Lack of Disclosure Given what I just explained, you can judge for yourself whether the team's disclosure is adequate. I argue it absolutely was not. The fourth screenshot shows their communication on the matter so far & exactly what they failed to mention Including the mint, the hackers' success & the off-switch! The fact that it took my own chain & code analysis to reach these conclusions tells us the team cared more about minimizing PR damage than properly disclosing the incident. At least with this piece out, they will not be able to get away with that anymore & will have to also include this information in their report The community deserves to know what is really going on, how centralized EGLD really is & how the tech is not a magical panacea but instead comes with serious trade-offs Chain Analysis The record is clear, all on a public chain for all to see. The attacker exploited this vulnerability in the chain & managed to mint 76M EGLD! Over 2.5x the supply! Along with 430M bridged USDC, about 430M bridged USDT & 5,540 bridged WBTC... The hacker then proceeded to split these into 16 wallet addresses & then send EGLD to multiple exchanges. If we look at the timing of when these exchanges "froze" EGLD, we see that MEXC did not act in time & it perfectly corresponds with very suspicious selling activity on that exchange, which was not even arbitraged out when the full freeze took effect. We cannot tell whether the hacker managed to exit the exchange afterward, but they certainly could have! Which means the hacker was likely able to walk away with around $1M USD, effectively defrauding the exchange in the proccess, by leveraging this EGLD vulnerability Please look at the visuals, as they provide all of the supporting evidence that can also be independently verified with publicly available information Conclusion This is BTC's 2010 inflation bug & ETH's 2016 DAO's hack rolled into one. That this all happened in 2026 is even more embarrassing Unlike those historic failures, there was no full disclosure of the problem as it was happening. People deserve to know; we are blowing the lid off this story now! This is also nothing like SOL's historic downtime, which involved network halts caused by bugs. Something that has happened in over two years. While EGLD managed to beat SOL in total downtime with this single incident! SOL also never ever had an off switch! The irony & I apologize; some degree of schadenfreude cannot be helped in my situation. As the EGLD community was one of the loudest spreading that false narrative. Turns out it was unknowingly a projection! The biggest red flag is still the team itself, after my fallout with EGLD last year. The toxicity & dishonesty became too much to bear This will likely trigger another ad hominem campaign against me, as it did last time & as it did for other influencers/journalists/thinkers. Fortunatly, I am specialized in weathering the storm. While these facts are undeniable & mostly speak for themselves EGLD certainly has some good technology; we can learn something from everyone. However, what we saw here over the last few days is beyond the pale That's where the value lies: In also understanding the character of a chain's leadership, especially at an early stage, as even with decentralized governance, bad leadership can still mess it all up! This is a truly worst-case scenario for a blockchain; there are very few examples of this level of collapse in blockchain history. After such an event, we have to question the competence & the wisdom of the underlying design choices EGLD's design is flawed & reckless, making centralization trade-offs other chains would never even dream of. All while claiming to be holier-than-thou It is never too late to change our minds in the face of new evidence; please study the supporting visuals for yourself. The truth cannot be credibly denied What occurred here is undeniable, while the silence of EGLD's leadership speaks louder than words: 🎓
15
57
223
12,066
A satellite that looks like a server changes the ops problem. You are no longer just flying a radio. You are flying a computer with a thermal budget, a power budget and a link that has to stay up. The hard part will be the ground segment, not the slide about Tbps.
Elon Musk says future $SPCX satellites could support ~10Tbps in both directions with a path to 100+Tbps powered by a 250kW $NVDA Vera Rubin NVL72 system. Wild to see each satellite start to look more like an AI server in orbit connected to a massive high-speed networks.
1
140
This chart is also a map of the training data. Most models on the left were fed Wikipedia and the public web, which is dominated by the same newsrooms and institutions. Grok sees that too, plus the actual arguments people make on X. That second source is messier. It is also much wider. If the pre-X public web already leaned one way, the models trained only on it will lean the same way.
Someone gave the leading AI models the Political Compass test. Grok 4.5 landed by far closest to the political center. Every model from Anthropic, Google, Meta, OpenAI, Deepseek, and others clustered far to the left. This is why building a maximally truth-seeking AI matters.
2
128
This is the whole point of measuring models on real work. A planner, a coder and a reviewer should not run the same model. On DevBench, Fable 5.1 is strong again on coding but expensive. Grok 4.5 low matches a 92.5 score for a fraction of the cost. Pick by task, not by hype. nitter.net/PhyByte/status/2095050…
There is no single “best” LLM, the real advantage comes from knowing which model to use for which job. ChatGPT, Gemini, Claude, Grok and DeepSeek each have different strengths. The smartest workflow may not be choosing one, it may be using several strategically. For executives, founders and professionals, AI literacy is becoming less about knowing how to prompt a chatbot and more about knowing how to orchestrate the right AI for the right task. That’s the thinking behind 10xme: Don’t just use AI, learn to work with AI. 🔗10xme.biz⁠
1
78
Most Grok Bot and other agents demos are sales, inbox and procurement. That is useful. It is not where companies get stuck. The missing bots are the ones that sit next to production: - watch Grafana and alarms - check a deploy after a code bot pushes and merge. - read logs and metrics before a human gets notify to add context. - pick a cheaper model for the bulk of the work and a stronger one for review if you want to go local. Agents become interesting in a company when they close a loop, not when they draft another email.
1
91
Great marketplace. Haggle Bot is a strong example. Still missing the bot that matters for engineering teams: a Grafana monitoring bot that works with the bots that edit code. Modify, push, deploy, then verify it still works. Close that loop and add it to the list.
You can now add Bot templates from our marketplace. We’re sharing Haggle Bot, our in-house procurement specialist. It negotiates vendor contracts, finds unused SaaS seats, and price-checks recurring purchases. One week in, it's saved us over $100K.
4
116
Finally it's there. You can access your @bot directly from your android phone!!!
Grok Bot is now officially available on Android You can download it now from the Google Play Store play.google.com/store/apps/d…
1
107
DevBench now has a developer track to help you choose the best fit for you different agents. You can compare models by language, not just by a single global score. 22 models. 280 coding cases across Python, TypeScript, Go and Rust. Generation, efficiency, bug fixing, refactoring and review. Top overall: 1. Opus 4.8 → 94.4 2. Grok 4.5 low → 92.5 3. Grok 4.5 → 92.0 The useful part is the split. Sonnet 5 looks excellent on Python and TypeScript, then drops on Rust. Opus stays the most consistent across all four languages. Grok 4.5 low sits right behind Opus for about 4x less cost. Qwen3.8-27B lands at 89.9 for $0. Fable 5 collapses on this track. It can still generate code, but bug fixing, refactoring and review fall close to zero because a large share of those cases get refused. That is why this matters for agents. A planner, a Python worker, a Rust worker and a reviewer should not all run the same model. Once you know the language and the job, you can pick a cheaper or local model for the bulk of the work and keep the expensive one for the hard pass. Results: dev-bench.phybyte.space/#/re… More languages and models coming.
2
2
443
This is exactly why locking a whole workflow to one IDE plus one model family is risky. When the harness changes, you still need to know which model is actually good for which job. Planning, execution, review and production analysis do not want the same model. That is the gap I built DevBench for. Real production tasks, not abstract exams. More tests coming. nitter.net/PhyByte/status/2092173…
We’re ending our partnership with Cursor following its acquisition by SpaceX. Under our proposal, Cursor’s direct access to our models would end on November 12. We know that the people most affected by this decision are the developers who rely on OpenAI models in Cursor. We care about their experience in this transition and we’re ready to go above and beyond to support them. openai.com/index/our-decisio…
104
Philippe Martin retweeted
Grok Bot Android App is coming
10
14
218
17,057
The same pattern shows up on production-style work, not only coding benches. In the latest DevBench run Grok 4.6 low scored 72.6 versus Opus 4.8 at 73.3, at roughly 4x lower cost. Fable landed lower because several log and metrics cases now get refused. Once you run many tasks, price, consistency and refusal rate start to matter more than a small raw-score lead. More tests and categories are coming. nitter.net/PhyByte/status/2092173…
Grok 4.6 just took #1 on CursorBench 3.2 at 70.8% — and costs $2.81 per task while Fable 5 Max runs $17.32 and Opus 5 Max runs $8.23 for similar scores. 6x cheaper than the nearest competitor at the same performance level. For agentic coding that runs hundreds of tasks, that gap compounds fast.
1
130
DevBench just got a major update. 23 models. Hardened tests. Higher complexity. xAI, OpenAI, Anthropic, Gemini + 7 local models. This is not another abstract reasoning leaderboard. It measures real production work: log parsing, anomaly detection, metrics analysis, root cause, multi-modal RCA. Top results: 1. Opus 4.8 → 73.3 2. Grok 4.6 low → 72.6 3. GPT-5.6 Terra → 70.6 Grok 4.6 low sits almost on top of Opus while costing roughly 4x less ($1.10 vs $4.24). Fable 5 dropped harder than expected. Several production-style cases now get refused by its cyber classifier, which is reflected in the score. Local models are getting interesting too. Qwen3.8-27B lands at 66.9 and Gemma-4-26B is close behind, both at $0. Live site: dev-bench.phybyte.space Still early. More categories and models coming.
1
6
2,379