The Register

The hardest problem in AI is no longer the chip but the megawatt. For much of the past three years, the global AI race has focused on semiconductors, with governments competing for advanced chips, technology outfits scrambling to secure GPUs, and investors pouring billions into ever larger datacenters. Yet the binding constraint has shifted from compute to the power required to run it. For anyone trying to energize a new AI cluster today, the bottleneck is rarely silicon; it is grid access, interconnection delays, and aging infrastructure. That was the central message from Envision founder and CEO Lei Zhang at VivaTech in Paris this June, where he argued that AI amounts to an energy revolution as much as a computing one. The steam engine transformed the industrial age by converting coal into motion, and the GPU now transforms the AI age by converting electricity into intelligence. History offers another lesson: James Watt changed industry through the efficient use of energy rather than by producing more steam. AI faces the same problem today, because the binding constraint has shifted from how many chips can be built to how they can be powered. The real risk: AI competing with society for energy The numbers behind the argument are stark. Goldman puts US datacenter power demand at 31 GW in 2025, rising to 66 GW by 2027, while assuming only about 72 percent of scheduled facilities arrive on time because electricity, not construction, is what typically slips. The IEA estimates that datacenters consumed roughly 1.5 percent of world electricity in 2024, a share rising to 3 percent by 2030 as AI-specific demand triples. The structural mismatch sits at the heart of the problem: AI models iterate every six months and chips refresh annually, while power grids have changed little in decades. Rack densities that sat at 5 kW are climbing toward 200 kW, and the IEA notes that AI server power density rose elevenfold between 2020 and 2025, with a further fourfold rise expected by 2027, straining the supply chains for power electronics and transformers that keep a cluster stable. The growing gap raises broader questions about where the energy will come from and who will bear the cost. Around the world, communities are asking whether AI infrastructure should draw on electricity that households, factories, hospitals, and public services also depend upon, with familiar concerns surfacing about consumer bills, manufacturer access to limited grid capacity, and the burden that ever-larger models place on public infrastructure. Those questions have moved beyond the purely technical into the societal, because the future of AI cannot rest on a model in which humanity competes with AI for power. Mission Gobi: Let AI follow energy Envision's answer, Mission Gobi, unveiled at VivaTech, aims to develop 5 GW of green AI computing capacity across deserts and arid regions by 2030. For decades energy followed computing, and Mission Gobi reverses that logic on the premise that in the AI era, computing may need to follow energy. The logic is grounded in geography, because deserts offer some of the world's richest solar and wind resources alongside vast expanses of low-cost land, with the additional advantage of little competing residential or industrial demand. Rather than drawing power from homes, factories, and public services, Mission Gobi seeks to build entirely new renewable energy systems dedicated to AI, expanding the available supply instead of asking society to share a fixed pie. The philosophy reduces to a single idea: compute should chase power, not the other way around. The economics matter because electricity determines whether a facility is viable, with power consistently accounting for the single largest operating cost at a datacenter and some estimates placing it at as much as 60 percent of the operational budget. Building energy-native AI infrastructure Envision splits the system into three layers: an intelligent operating hub, Physical AI powered by its Tianji Weather Foundation Model and Dubhe Energy Foundation Model, and advanced power infrastructure. Together they integrate generation, storage, grid, power electronics, computing, and large-scale AI models into a unified architecture. The challenge lies in coordinating renewable power rather than merely generating it, because AI facilities require stable, high-quality electricity while solar and wind output fluctuate continuously. Envision argues that large-scale predictive models can help balance generation, storage, and demand in real time. The concept has already moved beyond theory. In Chifeng, Inner Mongolia, Envision runs a 2 GW system on 100 percent renewable energy, coordinating wind, solar, storage, hydrogen, and compute in real time, while a gigawatt-scale AI and computing campus in Ulanqab is being developed as a demonstration of what energy-native computing infrastructure could look like. A 5 GW pledge is ambitious, but the underlying read is sound: retrofitting decades-old city grids for gigawatt AI loads is a difficult undertaking, and purpose-built renewable compute, sited where power is cheapest, offers a credible alternative. SpaceX looks up, Mission Gobi looks out Envision is not alone in recognizing energy as AI's defining constraint. Elon Musk's SpaceX has explored concepts for orbital datacenters powered by uninterrupted solar energy in space, and the vision rests on the same recognition: the future bottleneck of AI may lie in energy rather than silicon. Both approaches seek to place computing where energy is most abundant. The two visions diverge in geography, with one reaching upward beyond Earth's atmosphere and the other outward toward deserts and Gobi regions, though both start from the same premise: AI should not compete with humanity for power. A new blueprint for AI infrastructure If the industrial age was built around coal and the electrical age around power grids, the AI age may be built around energy abundance. The success of future AI infrastructure will not be measured by GPU counts and model sizes alone. It will also depend on whether the industry creates new energy supply, eases pressure on communities, and enables technological progress without reducing others' access to power. Whether deserts become the preferred destination for future computing remains to be seen. What is becoming clear is that the next phase of the AI race will be defined not only by who builds the most powerful models, but by who can build the energy systems capable of sustaining them. The path forward runs through creating new energy supply rather than reallocating existing capacity away from households, factories, and public services. Contributed by Envision.

Meta seems to be having a bit of an identity crisis. On Monday, the social networking singularity said it would spend $50 billion to expand its Hyperion datacenter project in Richland Parish, Louisiana, from 2.2 to 5 gigawatts. The news comes less than a week after a report broke claiming that Meta was actively exploring options to offload its excess compute capacity to other AI labs. So, which is it, Zuck? Did you invest too much or too little in AI? The easy answer is that Meta overcommitted. Inspired by the early success of Llama, it made a huge bet on the AI gold rush. Offloading spare compute to the highest bidder is just a hedge in case its Superintelligence team turns out to be another pipe dream, like the Reality Labs Metaverse that utterly failed to spark enthusiasm for immersive environments accessible through Meta's Quest cybergoggles. The more pragmatic read is that Zuckerberg has woken up to the fact he’ll never be as cool as OpenAI boss Altman or Anthropic's Amodei, and renting out spare compute is just the natural progression for any sufficiently large hyperscaler. Dawn of the Meta cloud? Meta's business model is closer to Google's than those operated by OpenAI and Anthropic. Both Meta and Google offer various services which generate revenues by connecting users with advertisers. For Google it’s a search and entertainment empire. For Meta it's enabling an endless feed of content generated by friends, family, influencers, and yes, bots. Both are immensely profitable, earning $132.2 billion and $60.5 billion in profits last year, respectively. That's profit, not revenue. But both are now plowing over $100 billion a year into AI infrastructure to power large language and image and video generation models. As we learned from Meta’s recent earnings calls, the most commercially potent of those models get the right ads in front of the right eyeballs. The open secret is Meta was already one of the most successful AI companies long before ChatGPT debuted. Except, it's not large language models (LLMs) that make Meta money, at least not in the conventional sense. Instead, Meta’s most profitable AI models are the recommender systems that mine profiles for context and use it to infer your needs. Meta's devs evolved those models considerably over the past few years, and their architectures now look a lot more like an LLM than the now-pedestrian neural networks on which Zuckerberg built his empire. Google is in a similar situation. It’s investing heavily in AI to feed its fast-growing and profitable cloud business, even as advertising still pays most of the bills. But unlike Google, Meta hasn’t yet made the leap from hyperscaler to cloud provider. Amazon, Google, Microsoft, even Oracle got there eventually, and it seems AI may be the catalyst that turns Meta into a cloud, too. Recent reports suggest that Zuckerberg is warming to the idea. “I think that’s certainly a thing that we could do and that I think would make sense to consider,” he said in an interview with Bloomberg last week. “As a backstop, even if for whatever reason we don’t need all the compute ourselves or for any number of reasons, there’s a very large amount of demand that I think you could sell it long-term like AWS or Azure or Google Compute.” But while the demand may be there, Zuckerberg emphasized the compute capacity is not readily available. But as Ben Thompson of Stratechery put it, cashing in on this compute may be more than a backup plan. In a post channeling an imaginary Zuckerberg, Thompson suggested that becoming a neocloud would force Meta to stop chasing pipe dreams and pet projects. His logic is that if Meta can't make money with infrastructure it buys for AI ventures, the social networking giant can lease the orphaned hardware to the highest bidder. The takeaway for investors — should Meta follow its fellow hyperscalers-turned-cloud-providers down this road — is that the profitability of its hardware investments would no longer be tied to its ability to commercialize them. Seizing the means of production If history tells us anything, scale matters. Building a cloud like Amazon Web Services (AWS) is next to impossible unless you've already figured out how to profit from those same resources. Meta's scale puts it in a position to acquire compute in volumes impossible for smaller players. Its ability to capitalize on infrastructure demand relies entirely on having something others want but can’t get anywhere else. For what it’s worth, Zuckerberg wouldn’t be the first to come to this conclusion. Earlier this year Musk-owned xAI surprised many when it announced plans to rent out its Colossus supercluster in Memphis to rival model dev Anthropic. The calculus here is the same. Making a profit off LLMs, like Grok, isn't easy — just ask OpenAI — but selling the means of AI production to those that haven’t yet figured that out is enormously lucrative. The logic appears to have gotten Zuck's attention. “The SpaceX model I think is quite interesting in terms of just making these short-term deals that are at a big premium,” Zuckerberg told Bloomberg. “So we get offers for all kinds of stuff like this and we’ll evaluate them and see what makes sense.” Reports suggest Meta is seriously considering two strategies for commoditizing its compute assets. The first would be a usage-based compute platform similar to Amazon Web Services' Bedrock. The service would allow customers to run models and serve them through APIs — interfaces that abstract operational complexity. To be clear, Meta already offers API access to its homegrown models, at least the ones it didn’t pull after realizing the way they’d been implemented could be abused. So, from what we gather the difference would be allowing customers to run third party models as well. The second scheme reportedly being explored would involve selling raw compute resources available to end customers — similar to CoreWeave or Lambda. All the right ingredients Meta’s silicon strategy may help as well. One thing all the major cloud providers have in common is a growing catalogue of custom cloud silicon. Once they've identified a core use case, Amazon, Google, and Microsoft all rolled their own silicon to maximize their margins. AWS Trainium, Microsoft Maia, and Google TPUs are all examples of AI accelerators originally built for internal workloads but later made available to the broader public. Meta has been building its own AI chips for years. The first few Meta Training and Inference Accelerators (MTIA) were designed to speed up its recommender models. But new designs, developed in collaboration with Broadcom, are far better suited to running LLMs like Llama and Muse Spark, and whatever else its customers are willing to pay for access to. More importantly, this mix of compute means that Meta can take advantage of the fact GPUs are extremely flexible to bring new products to market quickly. Then once they’ve proven performers, Meta could transition those workloads to its custom chips and offload spare GPU compute to its cloud customers. Meta has all the ingredients, compute, scale, and capital necessary to become a major cloud provider. ®

An AI rewrite of a popular Anthropic-owned JavaScript runtime and toolchain has sparked praise for the speed of its execution, but also criticism of the coding practices behind the project itself. Last week, Bun creator Jarred Sumner announced that he ported Bun from the Zig programming language to Rust in only 11 days, using a fleet of Claude agents running in parallel. The work cost an estimated $165,000 at API pricing, suggesting that software revisions previously considered too large to undertake could actually be feasible now with AI. Sumner said the port was necessary given the growing number of bugs Bun users were finding, including one implicated in the recent Claude Code source leak. But the creator of Zig, Andrew Kelley, didn’t want his project to be seen as the culprit behind Bun’s woes, which he blames on Sumner’s bad programming practices. For Kelley, the move to Rust was not about the feature differences between the two languages, or even the use of AI, but rather “the diverging value systems of the two projects,” he wrote. Bun in the oven Bun is a JavaScript suite consisting of a runtime, package manager, bundler and test runner. Some developers like it because it is a fast one-stop shop that plays well with Node.js. To make Bun speedy, Sumner used Apple's low-memory fast-start WebKit JavaScriptCore (JSC) engine, rather than Google’s stock V8 engine. He used the up-and-coming Zig because he appreciated its performance and low-level control. Anthropic acquired Bun in December 2025. The company built its core state machine on Bun. By then, Sumner had also grown to appreciate AI’s coding abilities, and was using it heavily in the upkeep of Bun. By the time of acquisition, a Claude Bot called RoboBun had been doing a lot of the heavy lifting in the Bun repo. It supplied the most merged PRs of any contributor, fixing bugs and remediating test failures. But as Bun’s user base grew, more cracks started appearing in the code. Users found issues across the software. Anthropic’s 512,000-line code leak in March? That was Bun’s fault, thanks to a bug in the bundler that generated source maps during builds even when told not to, NodeSource reported. All these bugs weren’t Zig’s fault, Sumner explained in a blog post last week detailing the migration. Bun’s architecture mixed garbage collection and application-driven memory management. Sumner admitted that Zig wasn’t designed for that task. Rust was just better at automating memory management. The Rustification of Bun Rewriting 500,000 lines of Zig into another language would be a gargantuan undertaking if done by hand. “A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time,” Sumner wrote. Instead, Sumner went with Claude. He spun up about 50 dynamic Claude Code workflows, reaching a peak of about 1,300 lines of code per minute and generating over a million lines of Rust code. The job took 11 days and cost about $165,000 at API pricing. Claude Fable did most of the heavy lifting. The Rust-based Bun was then subjected to Bun's exhaustive test suite of more than one million assertions. According to Sumner, it passed 100 percent of those tests across all supported platforms without skipping or deleting any. “There’s absolutely no way an engineer with that salary would’ve been able to achieve the milestones Claude did in 11 days,” an impressed HashiCorp co-founder Mitchell Hashimoto noted on X. Zig zags But does Bun’s speed of execution betray the core tenets of good software development? One person not impressed has been Zig’s Kelley, who shared his misgivings in an impassioned post entitled “My Thoughts on the Bun Rust Rewrite." Even before the Anthropic acquisition, “we became increasingly horrified at the programming practices we saw in Bun's codebase,” Kelley wrote. Bun was one of the largest and highest profile projects using Zig and, up until the Anthropic acquisition, a regular financial contributor to The Zig Software Foundation. In Kelley’s view, the project aggressively released new features, resulting in piled-up bugs, bad error-handling code, and technical debt. Sumner “was already writing slop well before he had access to LLMs,” Kelley quipped. He speculated that Sumner may have been under pressure to meet business objectives rather than technical ones, a pressure that increased with Anthropic’s acquisition. In fact, Bun’s codebase had grown so suspect in Kelley’s estimation that Bun parting with Zig was good news. As he put it, no longer would “the publicly presumed poster child for Zig programming language actually [be] the prime example of How Not To Write Zig Code,” he wrote. The Bun team also tried to upstream some of its AI-assisted work to Zig, to no avail. Leading up to the Bun rewrite, the team maintained a fork of Zig that it said improved debug compilation speed fourfold, as eagle-eyed Reg reporter Tim Anderson revealed in May. But the Zig project would not accept Bun’s changes, citing a policy of not accepting AI-based contributions. Zig had been getting an influx of LLM-generated submissions, most of dubious quality. This lack of engineering oversight around AI-generated code would lead to countless problems down the road, Kelley reasoned. Kelley pointed out that if Bun’s tests missed these bugs in Zig, how would they be caught in unsupervised Rust code? “The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything,” he wrote. “It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in [a] million lines of unreviewed slop?” ®

The Excel games have gone extreme, tossing four top competitors into urban wilds around the world in a one-off battle, which reigning champion Diarmuid Early won at the last minute. Irish phenom Early captured the win in the Microsoft Excel World Championship’s (MEWC) inaugural Landmark Battle over the weekend after a last-minute comeback that saw him take down Andrew Ngai by a mere 40 points (1060 to 1020) in the 30-minute contest. Jaq Kennedy and Nicolas Micot made up the back half of the chart. The conceit of the whole one-off contest, which was co-sponsored by hardware manufacturer Asus, was to stick the four contestants in the wild around four landmarks, forcing them to deal with weather, potentially flaky internet, and - shudder - the public who might wander over and question what exactly they were doing. Early, who now resides in New York, competed overlooking the Statue of Liberty; Kennedy near Big Ben; Micot at the Eiffel Tower; and Ngai overlooking Sydney Harbour. Hardware for the contest was provided by Asus, which doled out ExpertBook Ultras and wireless portable second screens to each contestant. MEWC said the contest was inspired by the remote work undertaken by many modern professionals, who increasingly work “across client sites, airports, cafés, co-working spaces, and remote locations, instead of behind a desk in an office.” The competition goes back to 2021. It was a 2022 broadcast on ESPN, however, that made competitive Excel a … um … popular thing to watch. MEWC competitions pit Excel experts against each other to solve complex problems designed ahead of time by other Excel experts. In the 2025 World Championship in Las Vegas, where Early beat Ngai to win the trophy, puzzles included doing things like solving a jigsaw puzzle using Excel. The 2022 competition broadcast on ESPN included the spreadsheet platformer Modelario, as well as tasks involving a yacht regatta and slot machine-style games. The one-off Landmark Battle took its inspiration from Jules Verne’s novel Around the World in Eighty Days, and saw the quartet of competitors racing through a seven-part puzzle to decipher the fastest travel route for a group of spreadsheet-bound characters intent on duplicating Phileas Fogg’s feat. According to MEWC, Early came from behind to win the contest using his signature strategy of “core-first, bonus-later,” which involves solving all the core challenges of a puzzle before returning after completion to see how many bonus questions he can pull off. Having been deployed to the field with nothing but a cameraman and the laptop they were working on, none of the competitors were aware of their opponents' live scores, meaning that Early won without knowing how close the contest had become. Qualifiers for the 2026 world championship are ongoing, and Early is an early favorite so far. Six of nine Road to Las Vegas qualifier matches have taken place so far, and Early has won three of them. ®

When it comes to AI services, you don't necessarily get what you pay for. It turns out that AI models with expensive tokens may cost less than models with cheap tokens for particular tasks. And the tooling attached to those models can have a significant effect on cost and output quality. Databricks, which sells data analytics software and services, recently devised an internal coding benchmark to assess the tradeoff between price and performance using various AI models. Matei Zaharia, CTO of Databricks and associate professor of computer science at UC Berkeley, said the company undertook the evaluation because models are often tuned to existing benchmark tests like SWE-Bench – which is "broken," according to OpenAI. Databricks devised its benchmark using real engineering tasks performed by its staff to assess how AI agents perform. Zaharia said while the results reflect the company's internal codebase, other companies should be able to conduct similar evaluations using their own code. One of the things Databricks found was that open weight models like Z.ai's GLM 5.2 are competitive with frontier models, like Anthropic's Opus 4.8. "It landed in the top capability tier, statistically tied with Opus 4.8 on quality, but costing $1.28/task against Opus’s $1.94," the company said in its report. But the price-per-token doesn't tell the whole story. Databricks contends that price-per-task needs to be considered. "Cheaper per-token does not imply cheaper per-task," said Zaharia in a social media post. "For example, Sonnet 5 costs less per token than Opus 4.8 but used more tokens, resulting in higher cost and lower quality." So while Anthropic's Sonnet 5 was around 1.7x cheaper than Opus 4.8 on a per-token basis, it was more costly on a per-task basis – $2.09 for Sonnet 5 compared to $1.94 for Opus 4.8. That's because it completed tasks less often (81 percent compared to 87 percent), and consumed more tokens to achieve the desired result. Academics already reached this conclusion, noting back in March that in about a third of the model comparisons they conducted, the model with the lower listed price ended up costing more. "For example, Gemini 3 Flash's listed price is 80 percent cheaper than GPT-5.4's, yet its actual cost across all tasks is 38 percent higher," they observed. The other thing that had a significant impact on test results was the harness – software like Claude Code, OpenAI Codex, and the Pi coding agent – which passes user input to the model, invokes various tools, and returns results. "Harnesses make a huge difference in cost-performance," said Zaharia. "The very simple Pi harness got the same success rate as harnesses from the LLM vendors with Opus and GPT 5.5, but at 2x less cost!" Zaharia attributed the difference to the size of the input – the context – passed to the model with every turn. When Claude Code served as the harness for Opus 4.8, Databricks measured a context of 742,000 tokens per task, compared to 236,999 for Pi. That's about 3.2x fewer tokens overall. With Codex, the total context per task was 1,235,000 tokens, compared to 665,000 tokens for Pi, which is known for its minimal system prompt. Zaharia said the results explain why Databricks built a tool called Omnigent to harness the harnesses – it's a wrapper for combining and swapping multiple coding agents. It's the front-end equivalent of the kind of back-end model swapping that OpenRouter enables. ®

Seemingly unaware of the concept of irony, Satya Nadella is warning AI-using enterprises to take care not to give away their business secrets alongside the massive piles of cash they’re forking over to frontier labs every month. Writing in a long-form post on X over the weekend, the Microsoft CEO and chairman warned of what he called the “reverse information paradox,” a situation in which purchasers of AI essentially pay for the intelligence product they’re getting twice: once with cash, and again “with something even more valuable,” namely the proprietary business knowledge one has to feed an AI model in order to make it worth using in the rare instance an AI investment actually pays off. “Over time, the information asymmetry becomes increasingly skewed,” Nadella noted. “The seller learns more and more about you as you use what you purchased, while you learn very little about what the seller is learning in return.” The irony is thick, given that Microsoft itself pushes AI that slurps up business data, and Redmond helped get this entire messy AI ball rolling by investing billions into early generative AI leader OpenAI. Azure was the former exclusive cloud home for ChatGPT, and Microsoft leadership arguably helped Altman get his job back when OpenAI ousted him in 2023. The pair’s relationship grew strained in the intervening years, and they loosened several exclusivity provisions in early 2026. It also comes after a number of large organizations paused or restricted Microsoft Copilot deployments in 2024 over a related concern: weak data governance and sprawling internal access rights. Enterprise data security outfit Securiti told The Register in 2024 that about half of the more than 20 chief data officers it polled had grounded Copilot deployments, either switching the assistant off or severely restricting what it could access. The problem was particularly acute in organizations with years of accumulated SharePoint and Microsoft 365 permissions, where overly broad access rights risked exposing sensitive information through Copilot. Fast forward a couple of years, and now Nadella is warning that data protection measures aren’t even enough for a business to stay safe in the AI age. “Models learn from ‘exhaust,’ the prompts people write, the tools agents use, and especially the corrections people make,” Nadella warned. “It's the kind of knowledge a competitor could never buy, and the kind that leaks almost imperceptibly: trace by trace, correction by correction, eval by eval.” Consuming intelligence through AI, Nadella added, creates more organizational intelligence. The Microsoft chief argued that the knowledge generated through those interactions ought to belong to the companies that create it. “Enterprises need a real trust boundary for their human capital and token capital to compound,” Nadella wrote, describing his ideal solution as having “a hard boundary across which nothing crosses, not even the intelligence exhaust, without consent.” In other words, welcome to the post-cloud era when all your AI infrastructure will come home to roost inside your own network. If you think we’re exaggerating, Nadella even mentions that one of the things enterprises need to do to solve the reverse information paradox is to build their own proprietary AI learning environments “within the tenant boundary.” We asked Nadella and Microsoft whether solving the problem goes beyond good data governance, as Nadella suggested in his article, and a spokesperson told us yes, describing the matter as a structural problem with the current generally accepted model of AI business in which companies rely on hosted services. Anyone and everyone using AI for business is at risk, they explained. In addition to isolating learning environments, Nadella’s X note also suggested AI-using businesses should create their own private evaluation systems and retain ownership of organizational AI memory and decouple their orchestration layer from any particular AI model, essentially creating “your own continuous learning loop.” “A company should be able to use a model without giving up the knowledge that makes it unique,” Nadella wrote. The Microsoft spokesperson argued that agent harnesses and memory should be independent of models, and called for enterprises to have the rights to their own usage data and model outputs, echoing Nadella’s comments about the irony of leading AI firms crying foul about model distillation while reserving “the right to learn from customer usage and interaction data.” As for whether this is a generic warning that something in the AI industry’s got to give or a sales pitch with Microsoft positioned as the hero, the spokesperson made that clear, telling us that Copilot and Azure AI Foundry (a hosted solution, it’s worth pointing out) are Redmond’s solution to the problems Nadella outlined in his weekend post. Both separate context, memory, and agent harnesses from AI models themselves, giving businesses an additional layer of assurance that their data is safe, the company told us. It's debatable whether or not Microsoft is actually the AI data protection hero enterprises are looking for. But the bigger point is true: Frontier labs are rolling in valuable proprietary data, and that could come back to bite the businesses that forked it over for free. ®

German textile company ZEGO Textilveredelungszentrum has filed for insolvency and is blaming the financial fallout from a March cyberattack that knocked its production offline for nearly six weeks. ZEGO's filing adds another name to the short but growing list of companies that say a digital break-in was commercially fatal to their business. The Bavaria-based company provides textile finishing, processing, and treatment services for customers across industries, including automotive, workwear, and technical textiles. In a notice to customers and suppliers, the organization said it had exhausted every available option before seeking insolvency protection. Managing director Johannes Zenglein described the filing as "one of the most difficult steps in our company's 37-year history." "The cyberattack of March 29, 2026, however, impacted our company to an extent that we could not fully compensate for despite our best efforts," Zenglein wrote. "The consequences resulted in a production outage of nearly six weeks and significant financial strain. These effects ultimately impacted our financial situation so severely that filing for insolvency became necessary." ZEGO did not disclose what kind of attack it suffered, whether ransomware was involved, who was behind it, or whether customer or employee data was compromised. What it has made clear is that the operational disruption alone was enough to push the business beyond the point of recovery. ZEGO said insolvency proceedings have now been initiated, but insisted the filing does not necessarily spell the end of the business. It said it plans to keep production running while administrators attempt to restructure the business, preserve jobs, and keep customers and suppliers on board. Cyberattacks have long been capable of bringing factories and production lines to a standstill, but relatively few businesses publicly acknowledge that the resulting financial damage ultimately tipped them into collapse. Perhaps the best-known example is Knights of Old, the 158-year-old British haulage company that collapsed after a ransomware attack. Criminals broke in using an employee's password, encrypted the company's systems, and left more than 700 people out of work. Paying the ransom made little difference. Last year, another German business, a phone repair company, also blamed a cyberattack for its demise after concluding the cost of recovering its systems and rebuilding customer confidence was simply too much to bear. For everyone else still debating whether cybersecurity spending pays for itself, ZEGO's message is difficult to miss: sometimes the highest cost isn't the ransom, it’s surviving the downtime. ®

Scientists have detected a sugar in interstellar space, suggesting the galaxy may be liberally sprinkled with some of life's chemical ingredients. A new study shows that a sugar molecule containing four carbon atoms, called erythrulose, has been found near the center of the Milky Way, the first confirmed detection of a monosaccharide in the interstellar medium. Living organisms use sugars as energy sources, structural components, and constituents of genetic material. While scientists have previously found ribose and glucose in meteorite and asteroid samples, indicating they also exist in space, monosaccharide forms of sugar in deep space had remained elusive – if we're not counting glycolaldehyde, which is often loosely described as the simplest sugar, or a sugar precursor. Astrobiology researcher Izaskun Jiménez-Serra and her colleagues found the sugar in large clouds of gas and dust near the center of our galaxy using ultrasensitive spectral surveys performed by Spain's Yebes 40-meter and IRAM 30-meter radio telescopes. The researchers identified the sugar compound by matching 12 sets of signals in the survey data with erythrulose's laboratory-measured spectral signature. "Erythrulose appears to be at least eight times more abundant than analogous three-carbon sugars, which remain undetected in our ultrasensitive observations," says the paper, published in Nature Astronomy this week. Quantum chemical and astrochemical models indicate that erythrulose forms efficiently on interstellar dust grains from simpler two-carbon molecules, the study found. The researchers say the findings suggest that erythrulose can be made from simpler molecules on dust grains in space, eventually becoming part of more complex chemical systems. "The discovery of interstellar erythrulose suggests that the interstellar medium could be a viable source of sugar feedstock for the prebiotic synthesis of the first nucleic acids, not only on the primitive Earth but also elsewhere in the Universe," the paper states. While the discovery of sugars in deep space may be tantalizing for any budding explorers of the galaxy, there's no need to travel that far to find erythrulose. It occurs naturally on Earth, including in raspberries. ®

Philips is replacing Hue Bridge Pro devices after a software update left several units bricked with no way for users to restore them. Rumblings began in forums in June after a seemingly innocuous update left users, quite literally, in the dark. After a few weeks attempting to resolve the issues, Philips has thrown in the towel and said it will replace affected devices. A spokesperson told The Register, "We have identified a firmware issue affecting a limited number of Philips Hue Bridge Pro devices under a very specific software update scenario. Our data shows that fewer than 100 devices have been impacted." As for the problem itself, "The issue can occur when a Bridge Pro with automatic software updates disabled has remained on an older software version for an extended period, and a software update is then manually installed under a specific set of conditions. "In affected cases, the Bridge Pro can become inoperable and display a red LED, resulting in a loss of connectivity with the Philips Hue app and connected devices." The spokesperson told us that affected users should contact the company's customer support: "All Bridge Pro devices confirmed to have been impacted by this specific issue will be replaced free of charge, regardless of warranty status." Which is great, except that if you have to set up a network of lights and devices again from scratch, that's a substantial amount of work. Backing up a configuration isn't an option at the moment. The Hue Bridge Pro is a hub for the Philips Hue lighting system. It can support more than 150 lights and over 50 accessories. According to Philips, "Equipped with a new chip capable of running complex algorithms and AI-powered features, it's faster and stronger than ever." Except, it appears, when Philips emits an update that bricks some of them. The incident highlights the risks associated with smart homes and their devices. Support could be abruptly pulled, the device's origin might not be what you expect, or, as in the case of the Philips Hue Bridge Pro, a firmware update could leave a device hopelessly bricked. Philips should be commended for its replacement plan, particularly when a device is out of warranty, although questions remain about its validation and qualification procedures. As for the device itself, Philips released an update on Monday to address the issue (where devices haven't been bricked) and urged users to enable automatic updates to receive the firmware update as it rolls out. ®

The UK and EU are demanding urgent action from critical infrastructure organizations after formally attributing the December 2025 cyberattack on Poland's power grid to Russia's Federal Security Service. The Foreign, Commonwealth & Development Office (FCDO) described the attack, carried out by the FSB's Centre 16 division, as "another example of the Russian state's irresponsible attempts to sow chaos across Europe." Milosz Motyka, Poland's energy minister, confirmed the attack on the country's power grid in January. He said experts suspected that whoever was behind it attempted to disrupt communication between renewable hardware and power distribution operators. The attack was ultimately unsuccessful, but suspicion quickly fell on Russia. Attackers tried to deploy the destructive DynoWiper malware, a move typically associated with Russian state-backed operations. Mandiant previously tied the 2023 blackouts in Ukraine to Sandworm's deployment of CaddyWiper malware, while the NCSC and its allies fingered the same military intelligence unit for the 2022 WhisperGate wiper attacks at the start of Russia's invasion. As The Register reported at the time, the FCDO said the attack in Poland could have left half a million Poles without power in midwinter – a cyberattack with potentially lethal consequences. We asked the NCSC to provide more information about what evidence allowed it to attribute the Poland energy attack to Russia's FSB, but it declined to comment on operational matters. Time to act The UK NCSC co-authored a technical advisory, published Monday, which highlights the latest developments in Russia's tradecraft, urging those most at risk to apply the recommended mitigations. It said organizations in the following sectors are most at risk from Centre 16 cyberattacks: communications, defense industrial base, energy, financial services, government services and facilities (especially organizations at the state and local level), and healthcare and public health. The headline mitigation recommended by the intelligence agencies is to disable SNMPv1 and SNMPv2, opting instead for SNMPv3 with authPriv, which comes with strong authentication and data encryption, and to disable Cisco Smart Install on all devices. Centre 16's common tactics involve scanning for devices that respond with SNMPv1/2. These support default or easily guessed community strings, which are commonly abused to gain access to network devices such as routers – a technique the NCSC and others issued separate warnings about in April. Attackers can abuse SNMP access to obtain device configuration data and transfer it to a server under their control, which can later facilitate persistent access. Although SNMP scanning is the principal tactic described, the advisory also covers the exploitation of Cisco devices, including those with Smart Install enabled. Defenders examining the document will notice overlapping tactics, techniques, and procedures (TTPs) between Centre 16 and other Russia-aligned threat groups, the intelligence partners wrote. Jonathon Ellison, director of national resilience at the NCSC, said: "The NCSC, alongside our international partners, have repeatedly exposed the advanced tools and coordinated campaigns of Russian cyber actors who persistently seek to exploit any vulnerability they encounter. "Today's joint advisory provides decisive, actionable directions from the global security community that network defenders should implement to protect against Russian Intelligence operations and secure the UK's critical infrastructure. "I'd strongly encourage all organisations, especially those entrusted with UK critical networks, to adopt these recommended measures immediately, thereby reducing the risk of compromise." Fresh sanctions The UK and EU have each added an array of Russian individuals and entities to their sanctions lists, including GRU officials, cybercriminals, and hacktivists. Members of pro-Kremlin outlet Rybar also makes an appearance, owing to its false narratives about Ukraine and alleged interference with European elections. The most high-profile designations concern Vyacheslav Stafeyev, Ivan Senin, and Ivan Kasyanenko – three GRU leaders accused of orchestrating cyber and hybrid operations. They also allegedly worked with cybercriminals and a company called IMPULS with a view to recruit cybersecurity specialists from universities and academies across Russia. UK Foreign Secretary Yvette Cooper said: "These sanctions strike at the core of the cybercriminal networks propping up the Russian state's aggression, and the UK and EU are sending a clear message that Russia cannot hide behind its use of these proxy groups.  "From directing criminals to targeting businesses, and striking Poland's energy grid in the depths of winter, the Russian state is sinking to new lows in its attempts to undermine European security. "Together with our partners, Britain will continue to call out this behaviour, bolster our resilience and respond to the hybrid threat posed by the Russian state. This will not deter us from supporting Ukraine." Sanctions were also imposed against three individuals accused of being operators of Lumma Stealer, one of the major infostealer malware strains that play a significant role in the cybercrime economy. National Crime Agency data suggests that in the UK alone, at least 2,100 victims were identified as infected over six months. The UK confirmed that the Russian state has used Lumma Stealer to gather stolen credentials and launch cyberespionage operations against global targets. The 24 sanctions unveiled on Monday add to the 3,400-plus individuals and entities that have been designated for their roles in supporting Russia's war efforts. Don't forget those cameras The coordinated international warnings and sanctions come days after Dutch authorities issued their own alert about Russian espionage units targeting internet-connected cameras to gather intelligence about military logistics routes. Its separate advisory warned that at least one Russian intelligence unit carries out operations targeting the Netherlands and other NATO members, using IP camera footage to track military logistics routes and the transport of materiel, and to map infrastructure such as bridges and roads. Dutch intelligence services added that Russia uses image recognition software to detect military vehicles, transport routes, shipments to Ukraine, and locations of Ukrainian soldiers. The advisory went on to say that Dutch intelligence suggests Russia's use of compromised IP cameras and their imagery has systematically increased recently and become a normal part of its tradecraft. It said abusing default passwords was the most common way in which Russian spies were gaining access to the cameras, although the most recent security updates were rarely applied, opening up vulnerabilities to exploit when using guessable passwords doesn't work. ®

Trusting an AI agent to summarize user complaints about downtime is one thing; trusting it to fix the problem unattended is something else entirely. A survey of 696 experts The Register ran with NeuBird AI in April 2026 found that 73 percent are not using AIOps at all, another 19 percent are in pilot, and only eight percent have it in production. Asked what's stopping them, 60 percent of respondents cited a lack of trust, by far the biggest issue, with concerns about ROI, security and data quality each registering at around 12 to 13 percent. NeuBird AI's Production Ops Agent is designed to close that trust deficit. Rather than summarizing the alert queue, it continuously correlates metrics, logs, traces, infrastructure telemetry, deployment activity and dependency relationships, then runs investigations across that combined picture to suggest probable root causes and next actions. It also works a step upstream. Rather than bolting a faster responder onto a noisy alert queue, NeuBird AI fixes observability at its source: through agentic instrumentation it generates the right signals, so the alert is high-signal by design. As Martel puts it, the point is to fix observability at the source, not patch the output. Field CTO Francois Martel sat down with The Register to talk through what the survey found, and why the next phase of AIOps will look nothing like the dashboards engineers have stared at for a decade. He also has views on what must change before SRE teams will let agents near their production systems. Lots of interest, very little deployment The data confirmed what Martel was already hearing in the field. "There's a lot of interest, but not a lot of action," he says. The pattern is familiar across agentic workloads: the categories that have taken off are the ones that come with an obvious human in the loop and an obvious verification path, such as coding agents and content generation. Operations is harder, because the work happens inside the running environment, on data the engineer hasn't seen yet, with consequences that show up in customer-facing systems. He saw the same gap inside enterprises long before he joined NeuBird: a backlog of 300 candidate AI fixes and a flurry of early enthusiasm, followed by a year of slog before the first one shipped. Part of that delay comes down to the speed of market development, since waiting six months for the tools to catch up with your expectations is sometimes the right call. Another part of it is the wrong choice of tool category, because general-purpose agents do not fit SRE problems. "There are specialized agents that can do a much better job," Martel says, "and address some of the concerns" of safety, security, guardrails and hallucinations. The tool also has to fit into the team's existing workflows. Trust is built, not declared Martel doesn't try to argue with the trust-heavy concerns the survey surfaced. "Working with AI is a trust-building exercise, and AI has to learn in order to gain trust," he says. "I would say that's kind of the killer feature for AI agents. If you can show that you're learning and getting better, then you can gain trust." That's why explainability sits at the center of NeuBird AI's design rather than being grafted on for the security review. The platform records the reasoning behind every decision so an engineer can interrogate it the way they'd interrogate a colleague's incident report. "Whenever you have an agent, you want to be able to audit the decisions that were made, and understand the reasoning behind the decision," Martel says. Internally, NeuBird AI captures every reasoning step via Langfuse. Explainability is only half of it. The platform is also SOC 2 Type II certified, read-only, and stores nothing, so trust is built into the architecture, not just the reasoning. Externally, the harder problem is presentation: early versions of the system surfaced so much detail that users described it as a wall of text. The fix was to make the reasoning interrogable rather than dumped, so engineers can chat with the system's memory the way they'd query a more senior teammate. Context is what makes the answer credible The same survey found that 59 percent of respondents require near-perfect accuracy before they'll adopt, while another three in every ten will tolerate around 80 percent accuracy. That bar is unforgiving, and Martel argues it can only be cleared with better context engineering, not bigger models. "The key to accuracy is this sweet spot between just enough context so that you're not missing things, and then discoverability of context," he says. "Certainly not too much context." Creating a solution that achieves that balance is beyond the reach of anybody with just a coding agent on their desktop, he argues. NeuBird AI's argument rests on the fact that most outages cannot be reasoned about inside a single dashboard or service. Any enterprise large enough to need an SRE team has silos throughout the tech stack, from storage and networking through to operating platforms and applications, especially after microservices fragmented the estate. An investigation has to traverse boundaries that no single human has full visibility into , and NeuBird handles this by doing the dependency mapping before the incident starts, so that when an investigation kicks off the system already knows where to look and how the pieces relate. Co-pilot now, autonomy later, maybe The clearest signal from the research, and the one Martel finds least surprising, is the preference for co-pilot models, with 62 percent wanting AI to assist rather than replace. He recognizes this stage from his own work with coding agents, though he also acknowledges an evolutionary arc. A year ago he wouldn't walk away from a coding agent for a minute, and now he's tempted to flip it into dangerous mode and let it run. He still checks in and architects everything, though. "I'm not going to completely surrender my responsibilities," he says. The pragmatic path he describes for operations looks similar. NeuBirdAI is starting to wire up automation through Ansible's Model Context Protocol (MCP) server, with certain playbooks marked as safe to automate in production and the rest gated behind human approval. Adding memory to a pod up to a known ceiling is something an agent can handle; anything riskier waits for a person. How much an engineer delegates, Martel says, depends on their appetite for risk and the experience they have built up working alongside the tool. The five-minute clock and the death of the war room Response time dominates the AIOps brief: just over half of survey respondents expect operational answers in under five minutes, and 75 percent want them inside ten, putting immense pressure on workflows that were never built for the cadence. Getting six specialists up to speed and pulling them onto a war-room conference bridge takes time the SLA cannot absorb. Martel's argument is that the on-call experience has to change before the clock can. "You want to get to the situation where you're not on a call with 20 other teams. Instead you're in front of a document that's outlining the explanation of what's happening and either giving me a solution or telling me who should get involved," he says. The agent does the legwork before the engineer logs in, so by the time the engineer arrives, the early triage questions have already been answered and only the interesting decisions remain. What IT means for the observability bill The most provocative finding, for incumbent observability vendors at least, is that 52 percent of respondents would consider switching telemetry tools if AI-driven insights worked across any back-end. Asked where this goes, Martel doesn't hedge. "In the future observability will be dominated by open source, cost effective storage indexing technology like Grafana, Elasticsearch, or OpenSearch." In that scenario the strategic asset shifts from whoever hoards the most telemetry to whoever can investigate it most intelligently, which means a context engine sitting above whatever storage layer is cheapest. This is a useful lens for buyers about to renew an observability contract, because the dashboards they have paid a fortune for are the human-readable layer of a system that increasingly has machine readers too. What next? The survey describes a market that badly wants AI in operations but has learned to be suspicious of vendors promising results without evidence. Martel's pitch is that the platforms surviving the next two years will be the ones that show their work and fit into the existing change-management apparatus rather than demanding a rewrite of it. The winners will treat operational context as a first-class engineering problem rather than a prompt-stuffing exercise. Martel has a blunt answer for SRE leads still wondering whether their team is behind the curve. "There are advantages you'll gain in terms of keeping up with a growing production estate with flat operational budgets," he says. "If you don't adopt it, what are you going to do? You're going to struggle." Sponsored by NeuBird AI.

KETTLE Like a drug dealer who's hooked you and raised their prices, business leaders are simply shocked to learn the AI their organizations are becoming dependent on is suddenly a lot more expensive. You can listen to the latest episode of The Kettle right here on this page, as well as on Spotify, Apple Music, or YouTube where you can subscribe to get notified of the latest episode. Kettle host Brandon Vigliarolo is joined by Reg reporter Lindsay Clark and contributor Joab Jackson this week to discuss their recent stories about the rising cost of enterprise AI - and one way a popular open source project is trying to fight tokenmaxxing with tokenminning - but the question remains whether such measure will be enough to prevent cost-benefit analyses from popping that bubble. Will the AI industry adapt to the fact it's still unprofitable, blowback from usage-based billing, and a desire to not pay AI models as much as the human devs they're supplementing or replacing? That's what's on the hob for this week's episode. A lightly edited transcript is below: Brandon: Welcome back to The Register Kettle podcast. I'm Reg Reporter Brandon Vigliarolo, and you're going to be absolutely shocked to discover what we're talking about this week. I'm kidding, of course, it's AI. Specifically the fact that it seems the world is starting to wake up to how much it costs to actually run these giant models that are supposed to make life easier for enterprises and their employees, but it seems like they're leading to some invoice shocks. With me to talk about the latest panic over AI costs are Reg reporter Lindsay Clark and our contributor Joab Jackson. Thanks to both of you for coming on. Lindsay Clark: No problem, thank you. Joab Jackson: Thank you. Brandon: So Lindsay, let's start with a story you wrote recently about the fact that C-suite occupants are apparently having trouble getting a handle on new usage-based AI costs. What exactly has them so confused? Lindsay Clark: I get the impression that big companies are diving in with both feet with AI. It's the latest trend. They're using it for a lot of coding and business apps, trying to do stuff in the business with it. KPMG is a massive global consultancy. They provide IT services and outsourcing services. Brandon: And they're the ones who wrote the report, correct? Lindsay Clark: That's right; they wrote the report and they have some skin in the game. They did a survey of more than 2,000 senior execs over 20 countries and found that 29 percent of them struggled to understand the operating costs as they scale with enterprise AI deployments. Nearly half of them were also looking to re-phase their AI deployments when the costs outweigh the expected value. Brandon: Explain re-phase. Are they rethinking the deployment itself or are they changing the scope? What's that mean exactly? Lindsay Clark: It's just slowing down and looking at what they're doing. They're looking at lower-cost models and high-fidelity models. It's looking for a mix of models to deploy rather than just maxing out on the most expensive ones. Brandon: Usage-based billing seems to be a relatively recent development in this space. It was all free samples until we get you in the door to the point where you're dependent on this, and then we realize we actually have to make money off this. Speaking as an AI frontier lab, we're going to have to charge you per token because we're just not able to turn a profit. Lindsay Clark: Anthropic, OpenAI, and GitHub have all moved from a subscription, flat-fee, all-you-can-eat model to usage-based billing based on tokens. The vendors, both the model providers and the application vendors that want you to use AI agents in their applications, want people to jump in with both feet and use this stuff as much as possible. Then, as is typical for the IT sector, they try to change the commercials as we go. Brandon: It's a big enough issue that more than a quarter of C-suite people are getting bill shock and realizing that they might not be able to afford this. But they're maybe a little bit hooked in because their engineers have been using this long enough. I wrote a story recently about an open source tool that someone wrote to test engineers to make sure they're not losing their edge in this environment, because a lot of them are. We've written plenty of stories about developers becoming dependent on this, forgetting how to do some of the basic things they used to be able to do. It gives these AI companies a big inroad to basically say, "Well, now we're going to actually try to make money." But it does put them in a precarious position. If you charge too much, these enterprise customers are going to try to find a way around it, whether it's an open source Chinese model or some other solution, rethinking their deployments and trying to go with smaller, large-scale models. But if you charge too little, you're never going to make enough money. Is this a needle that these AI labs can thread, or is it one that's pointed straight at the bubble? Lindsay Clark: There's a report from Gartner from a few weeks ago that was quite interesting. They had done some research about the cost on this topic for AI-assisted coding. Brandon: Right, this is one you covered back at the end of June, right? Lindsay Clark: That's right. A researcher called Nitish Tyagi was saying that there's a real lack of transparency from the vendors over the costs of their coding agents and they don't have cost optimization tools that you would expect in the cloud, for example. Because of this, the costs of the coding agent per developer was going to exceed the actual salary of the developer in 2028. That is the average salary globally. He was already finding that in areas of the world where salaries are a lot lower, like India, the cost of agents is actually exceeding the salary of the developer. This is because the cost of agents is the same throughout the world, whereas developers get paid differently according to where they're located. Brandon: I imagine the cost of these are maybe never going to exceed the salary of a developer in Silicon Valley; those guys are making a lot of money. Lindsay Clark: Exactly. Yes. Brandon: When I think about that, there's no way that you could have token costs being in the hundreds of thousands of dollars. But the overall global average is still a lot. I can understand that it's probably why you see a lot of companies concerned about the viability of AI deployments, causing companies to rehire the people they're laying off. It's another thing that screams, "How sustainable is this?" Lindsay Clark: That research, to your point about the bubble, means they have to recoup these costs somewhere. On the macro picture, a big investment house was looking at the capex across the industry for AI datacenters, and it was $1.5 trillion over five years until 2030. That's a lot of money, and it has to come from somewhere. Again, on the Gartner research, they were saying that all the model providers all have kind of different ways of doing the billing as well. There's no standard. So if you're looking at a way to approach this the model providers are likely to, then it's very hard. Gartner were encouraging people to take matters into their own hands, to look at optimizing their own usage, minimizing their own usage. And one of the things that came out of that call was that there was no direct relationship between any increase in token consumption and an increase in productivity and coding in this case. And that was very telling. It's not the case that the more that you use, the more that you get out of it. Actually, they were arguing that if you are careful with how you do this and controlled, then not only do you end up consuming less, but the quality of the code you produce is also higher. That was reflected in a conversation I had a few weeks ago with Spencer Kimball, who's CEO of Cockroach Labs. Spencer Kimball is well known in the coding world, spent a long time at Google, and he wrote the GIMP open source image processing tool. He said at Cockroach they don't do tokenmaxxing; they just use a whole bunch of models, including a lot of open source models and the cheapest models. He said there's no point in maxing out a model when you haven't provided the right context because you'll just get more rubbish back. He was in line with what Gartner had said; he's quite circumspect about how you deploy it on the commercial level. Brandon: Speaking of tokenmaxxing, that brings me to the next story. Joab Jackson, you wrote this a little while ago about a Netflix engineer who wrote an open source tool that has become popular very fast. It's apparently saved many users who have adopted it hundreds of thousands of dollars by trimming input to LLMs in order to save token cost. It's the opposite of tokenmaxxing; this is like tokenminning. What exactly did he come up with? Joab Jackson: This was a home project, as all good open source projects started out as. He had gotten a $287 bill from Claude Sonnet for some debugging and MCP type work he was doing. He was curious how you generate that large of a bill from that modest of a workload. He took a look at what he was sending over to Claude, and it's known that most token consumption is from input. You get charged for both token input and output, but most of the bills come from what you're putting into the system. He was inspecting the stuff that his agent was submitting, and the vast majority of it was completely redundant. It wasn't useful instructions; it was database schemas, JSON templates, or a lot of log work. He figured that if he could create a program that would tear out the redundant parts and then submit the useful information, he could save money. Claude does have a number of settings, but you quickly descend into AWS billing hell. There's a cache setting. Every time you give a query to an LLM, you're tagging on your complete history up until that point, so a lot of the same information gets passed up. You can set that history to stay for five minutes or an hour. This is how things get tricky real quick. You can set it for an hour, but it costs twice as much, though you get ninety percent savings in reads. Now you have to do the math of the stuff you're submitting versus your workload. Brandon: So this is basically trimming the fat, where instead of resending all that stuff as token input, it's basically telling the model, "You've already got this, use what you have." Joab Jackson: It's not even that you're being chatty. It's all these needlessly verbose schemas. If you have it execute a Rust command in verbose mode, you're going to get all that verbose stuff, even though the LLM doesn't need it. So he came up with a bunch of little modules that he calls squashers that look at these areas: database compression, JSON trimming, and so on. There are a lot of VC-backed token trimming tools now, but he wanted something inline that worked directly from the command line. Now, just a clarification, this wasn't work he was doing [for Netflix]; he has another job entirely at Netflix, but he built this program on his own. He let a few Netflix engineers try it and they liked it, but it just took off all of a sudden on its own anyway. Brandon: It's not an internal Netflix product; it's his own project. I'm curious how this would work. I'm assuming that this is entirely dependent on a context window? Joab Jackson: This is shaping the context window, basically. Brandon: If we go back beyond a certain point, because context windows have a termination, I'm assuming that at that point you're going to have to start resending stuff if you're still undertaking the same conversation. This is only effective as long as it remains in context. Joab Jackson: I use Gemini quite a bit, and they do keep a cache of the stuff so it does seem like a conversation. But after a certain point, although the conversation is seamless to you, all that data is being loaded back for the LLM to parse once again. Brandon: Gotcha. It's Project Headroom, right? So what's doing the work of clearing that headroom out? Is this another LLM or local algorithms that he's written to do this work? Where is that compression and trimming being performed? Joab Jackson: That's all being done on the client. He isn't using the LLM at all. He used some statistical analysis; say you send over a database table, the LLM probably doesn't need that entire table. It needs the first few entries, the schema, and any outliers to get an understanding, but it doesn't need all 100,000 rows. It's basically a series of tricks that he and other contributors have come up with to tidy it up. Brandon: I think you wrote in the story that his talk mentioned $700,000 in savings for the people who've been using it. You wrote the story at the end of May; do you have any update on how much money this thing has saved and how many people are using it? Joab Jackson: I haven't checked in lately, but originally he had estimated, just from the users who opted into telemetry, that they saved about two hundred billion tokens, which accounts for about $700,000. But there are other users who aren't submitting this information. It's open source, so you can't really track it. I did speak with him fairly recently and he said the project is taking off; it continues to attract attention. Brandon: I didn't see in your story whether there was an estimate of the percentage of a token budget or average query that this was trimming off, or is that going to vary by use case? Joab Jackson: Like sNinety percent of server logs aren't necessary. Seventy percent of JSON can also be cut because a lot of it is formatting. Anything that's routine formatting data you don't really need. He also had a nifty feature where he does some text compression. Everything is reversible, so if the LLM needs to go back and get more information, it can do that. Brandon: So this isn't a permanent thing. It's interesting; we're seeing horror stories about AI costs skyrocketing and huge bills. On the flip side, we see daily limits getting eaten up, leaving users with workflows and projects that are freezing in the middle of a workday. This might be what businesses need to free up tokens and trim AI expenses. What do you guys think? Is this going to be enough, or does something else have to give? Joab Jackson: We talk a lot about how generative AI is evolving, but if you really want to go back to evolution and you want to discuss Darwin, one of the core components was limitation of resources. Everything can grow indefinitely without limitations, but at some point, and that's when the real innovation kicks in, you only have limited resources. We have people complaining about data centers using too much electricity; I think the LLMs now are hitting that point. They're going to have to figure out how to make this work strictly with limited resources. I read a lot of AI research and I'm not seeing a lot of AI efficiency research coming out of the labs. Maybe it's just a necessary next part: we have this technology that we don't fully understand, but we have limits too. We have to start to factor in those limits. Lindsay Clark: I was going to add that as well as people looking at open source tools, the vendors, at least within the database market, see a big opportunity here. I've spoken to and read about a number of database vendors who are trying to improve the efficiency and reduce calls to LLMs. For example, a company called Pinecone which did vector databases a while back before everybody else did, is now looking to create a semantic layer between the agent and the business data and tech environment. You store the basics of the landscape in terms of database schema or how the company does financial processes, so you don't have to make calls to the LLM and create queries to find that out every time afresh. The point is, I think we're going to see a lot of people, perhaps from open source or proprietary vendors, see an opportunity here in selling to companies on the basis that they can reduce the costs of AI agents in their business. Brandon: I would hope that Oracle's working on that because, as we discussed last week, they're one of the most exposed to this bubble. Other big data center players that are courting the AI market, it's Microsoft, it's Amazon, it's Google, they all have big things to fall back on if the bubble ends up popping, whereas Oracle is on the hook for a lot of money without as much going on elsewhere. But if they can turn that database into a semantic layer that sits between and reduces calls, that might be pretty valuable. Lindsay Clark: I don't know, because they're also reliant on OpenAI. Last September, they announced a $450 billion pipeline of committed datacenter spending and the market reacted positively. Then a few weeks later, it turned out OpenAI were on the hook for $300 billion of that. Oracle is borrowing money to build these data centers as well. Joab Jackson: As Microsoft pointed out at the recent Build conference, you're going to need these in-between products anyway because the enterprise is a specialized task. There's domain knowledge you don't want to hand over to the LLM providers. There's going to be a whole set of middleware near the data, for analysis, and that will have to come from the channel. Lindsay Clark: It all depends whether the model builders' revenue forecasts are based on this trend for optimization that we're going to see in the next few years, or are the forecasts based on tokenmaxxing? That could be a big difference. Brandon: Based on what Joab just said, you don't see a lot of efficiency work coming out of these labs. My thought would be it's probably the latter, which probably doesn't bode well for the future of this industry. What do you guys think? Is this another thing that we have to watch out for as a potential part of the bubble? Is this going to exacerbate problems, or is this something that can be conquered and moved beyond without causing industry destabilization? Lindsay Clark: I don't know. We keep thinking about a bubble, there's been lots written about a bubble, but the markets seem fine. There are a lot smarter people than me investing a lot of money in this. But there is also cause for concern in terms of we don't really see exactly what the business model is going to be. Brandon: There aren't a lot of returns yet on investments. Lindsay Clark: Exactly. There are question marks over liabilities. There's a whole other side to this, there's AI agents doing coding, but all the big application vendors are looking to build AI agents that do business work for you in finance and HR, you talk about liability but they're not going to be liable for any of the decisions they make. So there's a question mark over that as well. We've seen bubbles burst in the past. My feeling is the capacity will be used at some point in the future, but there might be a few bumps in the road along the way. Brandon: We still have websites; the dot-com bubble burst but websites didn't go away. AI is not going to go away. It's just its scope and shape and use is probably going to be curtailed or changed. Joab, what are your thoughts? Joab Jackson: Weirdly enough, it reminds me of the dot-com bubble, but also reminds me the tablet craze. Microsoft refactored Windows for the tablet format even though 90% of their users didn't have any sort of touch screen capability. For 18 months, software vendors had to come up with touch-enabled versions and laptop manufacturers had to do touch screens. Eventually we got the iPad and the Surface. The tech industry does tend to go too far in one direction, but eventually it pulls back to gauge customer demand, and a much smaller but more useful industry is there somewhere. Brandon: The big question is whether or not we're entering this phase of constraint-driven Darwinian evolution in the AI industry that will save it from popping, or whether it's going to burst before then and as the Bank of International Settlements said, take the entire global economy with it. Either way, hopefully we will still be here to talk about it on the Kettle. Thanks for tuning in. ®

SpaceX is scheduling another test flight of its monster Starship rocket later this week. Flight test 13 will carry 20 Starlink satellites and, hopefully, will not repeat the anomalies seen during the previous test. The mission is set to launch on Thursday, July 16, with a 90-minute launch window opening at 2245 UTC. It will carry next-generation Starlink V3 satellites for the first time, deploying them during the vehicle's sub-orbital lob. The plan is for the 20 satellites to extend their solar arrays and antennas, and connect with Starlink's constellation via high-capacity lasers. Six of the satellites will have a suite of cameras to take a look at Starship's heat shield and, according to SpaceX, some of the tiles on the vehicle have been painted white to simulate missing tiles and serve as targets during the test. Since the satellites will be on the same sub-orbital trajectory as Starship, they will burn up in the atmosphere approximately 20 minutes after deployment. The previous flight test in May was mostly a success. However, there were problems, notably with the Super Heavy Booster, which failed to perform a "soft" touchdown in the Gulf of Mexico. SpaceX provided more details on what happened to the booster. "Slight differences in engine startup on the ship caused the directional flip of the booster to be off by approximately 90 degrees," it stated. Then, after the flip, five of the 33 booster engines failed to relight, and the boostback burn ended early. The result was a mishap, which prompted the US Federal Aviation Administration (FAA) to require an investigation before the Starship-Super Heavy could launch again. Starship also lost one of its three Raptor engines following stage separation, but still managed to reach its planned suborbital trajectory. SpaceX opted to not relight one of the Raptor engines during the suborbital flight, which is essential for showing that the vehicle can be trusted to enter orbit. The company intends to try again on Flight 13. "Several hardware and operational modifications have been made to address the interconnected causes with additional reliability improvements planned in upcoming versions of the Raptor engine," said SpaceX. It did not, however, elaborate on those "interconnected causes" nor what it had done to avoid a repeat of the booster flip incident. It only added: "The startup sequence has been modified to be more robust to timing variability and more reliably flip in the desired direction," and noted hardware modifications "to improve re-light reliability." Neither the booster nor Starship will be recovered on this flight. The booster is expected to make a controlled descent in the Gulf of Mexico, while Starship will again attempt a controlled re-entry and splashdown in the Indian Ocean, as on previous flights. An in-space reignition of one of Starship's Raptors is essential before SpaceX can send Starship to orbit, deploy Starlink satellites using the vehicle, or meet NASA's requirements forr the Artemis III and IV lunar landers. ®

Microsoft has begun sending its email of shame to Windows 10 consumers, reminding them that Extended Security Updates will run for an extra year. Strangely, some email clients are treating this latest emission as mere spam. Microsoft last month extended consumer ESU coverage through October 12, 2027. The company is now notifying those customers who might not have noticed the update on the support page that they've got another year to buy a new PC. The email talks about "our ongoing commitment to helping customers stay secure" while not mentioning Windows 11 or Copilot at all. Instead, it said: "We understand that moving to a new PC can take time." It also takes money. Windows 11's hardware requirements left millions of otherwise functional PCs ineligible for the upgrade amid soaring component prices, and the extension could further delay any Windows 10-driven PC replacement wave hardware vendors were hoping for. Consumers receiving the email have another year to see if hardware prices stabilize or Microsoft blinks again. After all, ESU for commercial purposes currently runs to 2028. Microsoft does not share official figures, but Statcounter shows that Windows 11 growth has mostly stalled in recent months. While Windows 11 accounts for about 70 percent of the Windows device market, there remains a substantial number of users sticking with Windows 10, many of whom will have received Microsoft's acknowledgement of the fact. For Windows 10 holdouts, the message amounts to this: keep the old PC for another year. Microsoft can try the upgrade pitch again in October 2027. ®

Hudson Rock says the suspected compromise of the Argentine Football Association (AFA) may be linked to an infostealer infection nearly a year earlier. The incident appears to be the work of an aggrieved football fan, or group of them, after Argentina eliminated Egypt from the World Cup round of 16. Egypt's coach and football association complained about several refereeing and VAR decisions, which they said contributed to the result. The compromise of AFA's systems was spotted after mass emails were sent from legitimate domains stating that Argentina "stole" the win from Egypt and that "the robbery will not go unnoticed." Hudson Rock said it found evidence of an infostealer infection dating back to September 8, 2025, on a device belonging to an AFA software developer who had been employed at the governing body for nearly a decade. The security shop operates a database of known infostealer victims, and noted that the compromised machine was added to its database the following day. Whoever was behind the attack, which was claimed by "All Egyptian Cyber Warriors," they either sat on the credentials for nearly a year, or sought them out after Egypt were controversially eliminated from the World Cup. Once they procured the credentials and authenticated themselves into the AFA's systems, Hudson Rock said they "likely had profound administrative control." This would have included direct access to phpMyAdmin database management panels, root access to certain AFA databases, access to the management portal of AFA's training HQ, the AFA media portal, and its competition management system. After looking at the stolen credentials in their database, the researchers said that weak, easily guessable passwords were reused across several internal systems. In addition to the compromised emails sent from AFA's management and admin portal (afasistemas.com.ar), Hudson Rock spotted a number of posts made to cybercrime forums advertising the body's data for sale. According to the advertisements, the data related to staff, professional clubs, and the AFA's external media partners. The samples appeared to include internal email addresses, phone numbers, user roles, and registration timestamps, as well as listings for access to AFA subdomains. Passwords were also among the data, although much of them were securely hashed. However, a small portion were in plaintext, which Hudson Rock said suggests "a significant security oversight." "The AFA breach is a textbook example of how devastating a single, unmitigated infostealer infection can be," the security outfit said. "A compromised machine belonging to a developer with high-level access highly likely handed a threat actor direct database administration rights and the ability to send authenticated internal emails. "Because the stolen credentials sat dormant for months, the organization was lulled into a false sense of security, completely unaware of the ticking time bomb in their network infrastructure." The AFA told reporters on Friday that it was investigating the compromise with its IT team after many received the emails sent by the intruders. "There is a possibility that our account has been subject to unauthorized access," the AFA stated. "We are currently working to clarify the situation and implement the necessary security measures." ®

"Idempotent" may be jargon, but the term performs an important job in HTTP as a hall pass that gives reverse proxies and gateways the go-ahead to cache complex query responses and automatically retry failed requests. HTTP has long allowed automatic retries for idempotent methods, but complex queries are often sent using POST, which intermediaries cannot safely assume is retryable. Developers have worked around that limitation for decades. The Internet Engineering Task Force (IETF) has published a new HTTP request method, QUERY (RFC 10008), joining familiar methods including GET, POST, PUT, and PATCH. In development since 2021, the QUERY request method provides a way for an HTTP client to make an idempotent request to an HTTP server. An idempotent request has the same intended effect whether it is sent once or multiple times (so retrying it should not charge a user's credit card again). The specification defines QUERY as safe and idempotent, and the solution was surprisingly simple. "Thanks to QUERY, we finally have functional HTTP caching for complex requests. Proxies, CDNs, and browsers can now cache requests with a body. This is huge for performance," writes developer Elie Treport in a recent blog post. Query operations have traditionally used the GET method. HTTP defines GET as safe and idempotent, as it made no changes to the server itself, but GET becomes awkward when the query data is too large or complex for a URI. The idea behind GET was to load all the necessary query parameters onto the form's URL, resulting in a very long string that the browser sent to the server. Many search services still work this way, appending query parameters to the URL after a question mark. Those URLs can expose sensitive data through browser histories, server logs, and bookmarks. Festooned with nested filters, sort rules, date ranges, and other database flotsam, GET URLs can become unwieldy. HTTP recommends support for URIs of at least 8,000 octets, but there is no universal maximum, so an oversized URL may be rejected by any of the systems it passes through. Long query strings are also a pain to read and debug. Faced with these Franken-URLs, many developers turned to POST instead. POST can carry query data in the request body, but its semantics do not tell intermediaries that the operation is safe and idempotent. The method is more commonly associated with operations such as submitting form data, uploading a PDF, or creating and modifying resources. For a basic HTML form, switching to moves the encoded form data from the URL into the request body. Crafty developers soon began placing complex query payloads, often encoded as JSON, in POST request bodies and having their applications process the responses. Many APIs adopted the pattern; GraphQL, for example, commonly uses POST for queries, although it also supports GET. It was a hack, though. This was not what POST was designed for. HTTP defines POST as neither safe nor idempotent by default. A POST request could change the server's state. And this is why internet networking software treats POST far more delicately than GET. Intermediaries generally cannot reuse POST responses for later POST requests or automatically retry POST without knowing the operation is idempotent. If the message fails, the browser or gateway will not resend it, necessitating intervention from either the user or the app. QUERY's long road to adoption So basically, QUERY combines request content similar to POST with explicitly safe and idempotent query semantics. No longer will the query URL need to be appended beyond recognition, but, like POST, apps and browsers will get a dedicated space to put their complex query data. Unlike POST, QUERY is a read-only operation, and hence receives the IETF's blessing as idempotent, freeing up HTTP clients and intermediaries to cache and resend QUERY requests after a connection failure. A QUERY request does not ask or expect the server to change the state of the target resource. It's just there to ask a question. Cloudflare and Akamai engineers co-wrote RFC 10008. Both companies provide edge caching for large clients. German internet engineering firm greenbytes also contributed. As a new standard, QUERY still has limited support. The HTML forms standard still only understands GET and POST for ordinary form submission, so it will need to be updated even before the browsers get on board. The good news is that the Web Hypertext Application Technology Working Group is already on the case. However, a whole ecosystem of network software still doesn't understand QUERY and may reject requests using an unfamiliar method. Reverse proxies, load balancers, content delivery networks, API gateways, firewalls, and web frameworks will all need to be updated. "The pattern one would expect is the same seen with other HTTP methods and headers that became standard over the last twenty years: first server-side adoption and dev tools, then consolidation in frameworks, and finally, more slowly, native browser support and JavaScript APIs like fetch()," wrote open source developer Daniele Teti in a blog post. Teti noted that Node.js is adding support in its HTTP module, and the Go programming language is ahead of the game because it can already send custom HTTP methods. Elsewhere, the PHP framework Laravel is already ingesting QUERY. But, as with IPv6, the IETF faces an uphill battle to get the HTTP ecosystem on the same page. ®

Progress Software has ordered some ShareFile customers to pull the plug on their own servers after detecting what it describes as a "credible external security threat" targeting the on-premises component of its enterprise file-sharing platform. The emergency warning, sent by email and seen by The Register, instructed organizations running ShareFile Storage Zone Controllers to take the unusual step of manually shutting down the Windows servers that host the software, with no patch or configuration workaround yet announced. "We have reason to believe there is a credible external security threat targeting Progress Software's ShareFile Storage Zone Controllers," the company wrote, adding that it had already disabled access to ShareFile accounts using Storage Zone Controllers, but warned this alone was not enough. "IMMEDIATE ACTION REQUIRED: You must manually shut down the server hosting your Storage Zone Controllers," the email continued. “This is a critical additional step to ensure the safety of your data." The company said the restrictions were being imposed "out of an abundance of caution" as it works with internal and external security experts to investigate the threat. Customers reported that Progress was also calling affected organizations directly to reinforce the message. A follow-up notice over the weekend offered little additional detail. Progress said it had "no indication of unauthorized access to any ShareFile customer account or data, and we have not identified any active threat," but instructed customers to keep Storage Zone Controllers offline even as cloud services were gradually restored. Exactly what prompted such a dramatic response remains unclear. Progress has not disclosed the nature of the threat, whether any customers have been compromised, which software versions are affected, or when administrators can safely power systems back on. A spokesperson at Progress Software did not answer our questions, instead they sent a statement to The Register: "Protecting our customers' data and maintaining the security of our services remain our highest priorities. As of 5 p.m. ET on Sunday, July 12, we notified all ShareFile customers with Storage Zone Controllers that their access to the Progress ShareFile cloud service has been restored. However, Storage Zone Controllers must remain turned off while we complete our investigation. At this time, we have no evidence of unauthorized access to any ShareFile customer account or data, and we have not identified any active threat. We will continue to provide customers with updates as additional information becomes available. " The information vacuum has fueled speculation. One Progress customer on Reddit speculated that if the vendor is telling customers to completely shut down servers, "it's almost certainly an unauthenticated RCE being exploited in the wild." Storage Zone Controllers are the on-premises component of ShareFile that allows organizations to keep files on their own infrastructure while continuing to use Progress's cloud platform for authentication and management. Because they typically sit on internet-facing Windows servers, they present an attractive target if a serious, remotely exploitable flaw emerges. The incident also arrives just months after Progress patched two critical vulnerabilities in ShareFile Storage Zone Controller v5 that could be chained into unauthenticated remote code execution, although the company has not linked the current incident to those bugs. Progress is no stranger to security crises. The vendor spent much of 2023 and 2024 dealing with the fallout from mass exploitation of its MOVEit Transfer software by the Clop ransomware gang, a campaign that snowballed into one of the largest supply chain breaches on record. Whatever Progress has found this time around, it has decided that customers are better off with their servers powered down than running. ®

Microsoft and backup are two words often uttered together, usually in the form of "Microsoft Windows has crashed again, where's my backup?" The question is: what would a backup look like for a digital sign in Derby? Spotted by eagle-eyed Register reader "nategee" on a stroll in Derby, this sign appears to have spent much of the day pleading to be backed up. This poses an interesting question. What, exactly, would constitute a backup for a sign? Microsoft would obviously like somebody to log in with a Microsoft account so the data on the computer behind the scenes can be squirted into its cloud. However, we'd contend that a more appropriate backup for a digital sign would involve glue, paper, and a person on a ladder, wielding a brush. Although the words "if anything gets my back up" is often muttered by Windows users faced with yet another surprise update or unexpected screen of blue, the backup suggestion usually pops up when Windows restarts after an update. Microsoft has examined the user's device and tightly clutched its pearls upon realizing that the PC isn't backed up. And now would be the perfect time to back it up by signing in with a Microsoft account, at least as far as the tech giant is concerned. The owners of the billboard might disagree. Sadly, there is nowhere obvious for a technically minded passer-by to attach a keyboard and mouse to let the sign continue the startup process, and the hard-pressed techie responsible, doubtless sitting behind a desk at the mothership, has yet to give a remote command to unbork the signage. Digital signage might be flexible, but we doubt Microsoft is advertising backups here - or reminding everyone that Windows has a habit of nagging users into doing what Redmond thinks is best for them. Perhaps it's best to back up to something that doesn't involve Microsoft's OS, or maybe even save the power, dust off the poster poster and glue pot. No tech required. ®

It is just over a year since a pilot project to install photovoltaics on a railway line kicked off. According to the CEO of Sun-Ways, the company behind the scheme, the challenge was not so much technical as regulatory. The project, a 100-meter photovoltaic installation on a railway line open to traffic, was inaugurated on April 24, 2025 in Buttes, Switzerland. It's fair to say it went well; the 48 solar panels wedged between the tracks have generated more than 19 MWh to date. According to the company's CEO, Joseph Scuderi, more than 11,000 trains have passed over the solar power plant without incident. There has been no impact on railway operations or solar generation. It's a novel idea – use the space between rails for solar power generation. While the angle of the panels might not be ideal, the losses would be relatively minor compared to the potential gains. In Switzerland alone, Sun-Ways reckons there is a potential 1 TWh available, enough to meet 30 percent of the country's public transport needs. The panels themselves use anti-reflection material to avoid distracting train drivers with glare, and are resistant to micro-cracks, which could lead to a higher risk of fires. And then there is the installation itself, which required coming up with a rail-mounted machine to deploy the panels. According to Scuderi, the company now has a machine capable of installing up to 300 solar panels per hour, over hundreds of kilometers, rather than the 100 meters of the pilot. However, as Scuderi told The Register, "Technology wasn't the problem. "After all, we're capable of sending people to the Moon… "The real challenge is regulation. The strictest safety requirements apply in the rail sector. It took us years to obtain authorization to test our Sun-Ways solar power plant on a line open to passenger trains." According to a report published in April by the European Environment Agency, renewables (including solar) accounted for 25.2 percent of final energy consumption in the European Union. In the past year, renewables have accounted for 43.3 percent of generation in the UK, according to the National Grid (the UK's power transmission network), with 6.9 percent coming from solar. The EU's minimum target is 42.5 percent from renewables by 2030, so sticking solar panels on the space between the rails carries a certain appeal. Scuderi told us that agreements had been made with Italy and France's SNCF, and that talks were underway with South Korea, Spain, and Portugal. He said, "I envisage a market launch as early as 2028, with the deployment of small Sun-Ways power plants of 10 km (10,000 m2), then an increase in capacity to reach 1000 km installed by 2035 and 10,000 km in 2040." It's an ambitious plan, and might have seemed the stuff of fiction when Sun-Ways was founded in the early 2020s. Maintaining the panels, track (and track bed), and keeping the units clean enough to generate a worthwhile amount of power were obvious concerns, but the project has shown that these technical challenges can be overcome. Indeed, equipment capable of installing 300 panels per hour beats the rate at which canopies and station buildings could be plastered with photovoltaics. That said, panels away from the line don't share the same concerns about impacts from rail traffic or the inconvenience of track maintenance. Scuderi told The Register, "The financial projection we have made show a LCOE [Levelized Cost of Energy] from 0.05 €/kWh to 0.09 €/kWh, depending on the amount of sunlight (southern or northern Europe)." "And for a customer such as a railroad company," he added, "the LCOE corresponds to the final cost of electricity, since it is not subject to taxes or fees on the public grid, as solar energy is fed directly into the traction grid." It is hard not to remember the initial excitement that surrounded solar roadways a decade ago, which unraveled as realities such as the weight of traffic and maintenance requirements struck home. Solar railways, however, appear to be a success thus far, with the panels requiring little maintenance and producing the expected power. The next challenge is scaling it up. ®

OPINION In Disney movies, if you wish really, really hard for what you want, it happens. In British courts, not so much. Prince Redmondia really, really wanted to stop the evil barons from reselling on-prem Office and Windows licenses, and made a fairy tale argument in court to make it so. Our hero did not get its wish, not then, and not now with the UK Court of Appeals. The traditional reason companies dislike reseller markets is the obvious one that they don’t get any revenue. The law, however, has an even more traditional take on this: that once you’ve bought something you can do what you like with it. Is this true for software licenses? In Europe, explicitly yes. So Microsoft made the novel argument that its Office's suite's icons and help files made it a creative work that deserved copyright protection. For veterans of the Great Wars Of Software IP, this is arrant nonsense that should be jolly well tossed, and tossed it jolly well has been. This is especially bad news for Microsoft. Not only does the reseller market continue, but the company could be on the hook for billions in damages over its efforts to date to shut things down. By itself, this is bad enough. But wait, there’s more. Microsoft, like any modern blue-blooded software company, would much rather rent you its software than sell it to you. As anyone with the integer math skills of a seven-year-old can tell you, this is a bad deal. Thus, on-premises systems have to die off for this to work, but the sector is alive and well, and Microsoft is stuck with a valuable friend. It can't walk away. This could turn out very badly indeed, due to one of the lost battles of those software wars. That lost IBM, at the peak of its powers, the IBM PC market it had itself invented. Forty years on, it could do the same for on-prem Microsoft. The IP wars were all about what legal protection the law gave software companies. Could the look and feel of software be copyrighted? No. How about programming interfaces? No again, not by copyright or patents. Actual software, as source code or binaries, was copyright and couldn’t be used without permission — which makes Microsoft's claim that text files and clip art confer extra protection so ridiculous. A lot of this was already accepted in 1981, when IBM launched its PC. The hardware was easy to legally clone, it was barely more than Intel data sheets made flesh. The built-in BIOS chip with the software which linked that hardware to software, was safely copyrighted. IBM even published the source code, knowing that anyone who used even a tiny part of it would meet death by a thousand leathery-winged lawyers. The market swiftly rejected anything other than 100 percent IBM compatibility. Job done. It took start-up Compaq a year to blow that assumption apart. Get a team of programmers to affirm they’d only seen the BIOS interface, not the source, and get them to implement the interface in entirely new code. 100 percent compatibility. Zero liability. Just like that, IBM lost control of its own invention. Compatibility is the primary reason people stick with Windows and Office. The UI, behavior, feature set, and file format fidelity matter a lot more than raw function. As every Reg reader knows, there are fantastic FOSS answers for office productivity, ones that obliviate license fees, yet practically nobody wants to know. If only Windows and Office could be cloned with the same degree of fidelity as that PC BIOS. That BIOS was an 8K binary built from around seven thousand lines of 8086 assembler. The whole listing was an appendix in a ring bound manual. Office and Windows, well, who knows. As much as 200 million lines of code and multiple GB of binary. That’s a lot of ring binders. The sheer heft of the monster and the army of data warriors tending to it made it unassailable, and the Redmond tax inescapable. Until now. Any sufficiently advanced AI coder is indistinguishable from open sourcery. Set it loose on a product and ask it to duplicate and test. It would be expensive, and we’re probably not there yet. Once done, though, you have a whole new code base that will plug into an MS-powered organization like a clone BIOS into a motherboard. As with the PC market, you could go beyond compatibility and introduce features that people actually want. It’s not that the sums add up, or that the LLM coding models can demonstrably do this yet. It’s that what was once so clearly impossible it wasn’t worth thinking about is now within the realms of possibility. If someone bet you of a crate of decent malt whisky that this could happen in two years' time, would you take it? Two years ago, who wouldn’t. Now you have to think about it. Now think how big the stakes are for Microsoft. One of the few things finer on the tongue than a fine Islay scotch is the irony of a company using AI like a chainsaw chopping its own legs off. Prince Redmondia, be careful what you wish for. ®