@dxos/plugin-magazine 0.0.0

package/src/operations/sources/testing/feed.xml

@@ -0,0 +1,477 @@
+<rss xmlns:media="http://search.yahoo.com/mrss/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:lab="https://labradorcms.com/ns/rss" version="2.0">
+<channel>
+<title>www.theregister.com - Articles</title>
+<link>https://www.theregister.com</link>
+<description>Articles from www.theregister.com</description>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5250322</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/06/02/trump-ai-executive-order-sets-30-day-frontier-model-review/5250322</link>
+<pubDate>Tue, 02 Jun 2026 21:59:35 +0200</pubDate>
+<title>Trump's AI E-(I)-O could let feds pick winners and losers</title>
+<description>
+<![CDATA[ Government gets a say in 'trusted partner' access, and that worries policy experts ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Tue, 02 Jun 2026 21:19:13 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ After postponing a planned signing last month for an executive order addressing advanced cybersecurity AI models, President Trump has signed a largely similar version that’s just as questionably effective. The EO, signed in a private ceremony on Tuesday, directs various government agencies to take steps to protect their systems and data, as well as those of agencies they support, from cyber threats, while also facilitating access to advanced AI models that could help agencies bolster their cybersecurity defenses. The order also directs the Treasury Department to establish an “AI cybersecurity clearinghouse” that works with the AI industry and critical infrastructure operators to coordinate and deconflict the use of advanced AI tools for software vulnerability scanning, vulnerability discovery and validation, and remediation and patching efforts. Additional provisions are included to direct federal grant programs toward companies developing AI vulnerability detections, and to expand the US Tech Force's Information Cybersecurity Specialist hiring and placement pathways. Those elements are pretty cut-and-dried, but it’s the rest of the order that has raised eyebrows among policy experts who’ve weighed in on the order so far. Section three of the EO, Secure Frontier Model Deployment, is where the government’s AI model pre-release review scheme is outlined, and it is also where the most substantial change in the order compared to the earlier May draft appears. The version signed Tuesday directs various agencies to work with the National Institute of Standards and Technology to establish a “voluntary framework” through which the federal government would get access to “covered frontier models” for up to 30 days before their planned release to “other trusted partners” in order for the agencies to review them for potential cybersecurity risks. The May draft included a 90-day review period; the reduction to 30 days appears to be the most significant change between the two versions. Along with the review period, section three of the order also asks federal agencies to “develop and maintain a classified benchmarking process to assess the advanced cyber capabilities of AI models,” which would also be used to determine which AI models qualify as covered frontier models for the purpose of the order. The EO also asks that the voluntary framework enable AI companies to "collaborate with the Federal Government to select trusted partners that will have early access to covered frontier models,” meaning that the Trump administration would effectively have a role in picking which companies get to participate in programs like Anthropic’s Project Glasswing for its Claude Mythos Preview. Want early access? You'd better be on our side The Register was contacted by various policy analysts about the EO, and while all agreed some sort of rule was better than nothing, a number of them shared their concerns. “The White House executive order on frontier AI models, while imperfect, is a step in the right direction to prepare the nation for the release of advanced AI systems,” Cato Institute policy analyst Juan Londoño said of the order. “The lack of clear specifications on which criteria should be used to determine what constitutes a 'covered frontier model,' and the government's involvement in decisions about which 'trusted partners' can access these advanced models, gives the executive a great deal of discretion,” Londoño added. “This could open the door to potential weaponization against companies that have any sort of conflict with the administration.” Former FTC chief technologist Neil Chilson likewise said that the order is better than the “current informal approach,” but hopes Congress will take action to establish some actual rules. Gaps in the order, Chilson said, “could be used to pick winners and losers, or to give short-term national security concerns excessive weight at the expense of longer-term national security, economic growth, innovation, and other national interests.” The Center for Democracy and Technology’s VP of policy, Samir Jain, likewise said that the EO takes necessary steps to address risks to critical infrastructure, and like others, he praised the choice to make the framework non-mandatory. That trusted partners element, however, raised his hackles, too. “The EO should not become a mechanism for the Administration to punish companies for political or other arbitrary reasons, and so we will be closely monitoring the details of its implementation as they emerge,” Jain said. The White House didn’t respond to questions for this story. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=261924&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=261924&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5250291</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/06/02/cisco-praises-ai-bug-hunt-wont-reveal-flaw-tally/5250291</link>
+<pubDate>Tue, 02 Jun 2026 20:35:24 +0200</pubDate>
+<title>Cisco sings Mythos' praises - but doesn't say how many bugs the model uncovered</title>
+<description>
+<![CDATA[ Meanwhile, Anthropic adds 150 partners to Project Glasswing ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ Security ]]>
+</lab:kicker>
+<dc:modified>Tue, 02 Jun 2026 19:39:54 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Bug hunting has become a whole lot more exciting in recent months with both Anthropic and OpenAI touting their latest models (that also happen to be super-scary exploit machines). On Tuesday, as Anthropic announced a fourfold expansion to its Mythos preview program, Cisco jumped into the fray, praising the transformative power of AI - but without disclosing how many bugs the latest frontier models found. Cisco SVP Anthony Grieco in a Tuesday blog said that the advanced AI systems, including Anthropic’s Claude Mythos Preview and OpenAI’s GPT 5.5-Cyber, scanned 1.8 billion lines of code in eight weeks looking for vulnerabilities in Cisco products - a task that otherwise would have taken the networking giant’s advanced security team eight years to accomplish. However, Grieco, who heads Cisco’s security and trust organization, didn’t say how many flaws Mythos and other frontier models uncovered, or if they have all been fixed. The company also did not respond to The Register’s questions about this. Grieco did say that “speed is only half the story,” calling the “real breakthrough” the “scale, quality, and impact” of the models’ findings. The 1.8 billion lines of code, written in more than 25 different languages, spanned Cisco’s portfolio, we’re told. Netzilla paired the models with a “human-guided harness,” and achieved a false positive rate of under 3 percent, Grieco wrote. “Rather than focusing on a specific scope for a security evaluation, we can assess entire code bases of a product. It’s like switching from a flashlight to a flood light to illuminate a dark room,” he said. “Because each finding is validated through a hybrid of AI and human expertise, our engineering teams are receiving actionable intelligence rather than a wall of warnings.” Meanwhile, Anthropic on Tuesday said it expanded Project Glasswing to about 150 additional organizations, bringing the total partner count to about 200. Project Glasswing is the AI giant’s controlled partner program for giving selected orgs access to Claude Mythos Preview. When it announced the new model and partner program in early April, Anthropic limited the preview to about 50 entities, claiming Mythos is so good at finding and exploiting security holes that all hell would break loose and the zombie apocalypse would hit should the model fall into the wrong hands. Since April, these select government agencies and corporate partners - including Cisco - have been using Mythos to find and fix bugs in their own products. Palo Alto Networks, one of the original Project Glasswing partners, said in May that after spending a month using frontier AI models, including Anthropic's Mythos, to scan more than 130 products across its three platforms, it uncovered 26 CVEs representing 75 underlying security issues. For comparison, the cybersecurity giant said it typically discloses fewer than five CVEs per month. At the time, a company exec forecast “a narrow three-to-five-month window for organizations to outpace the adversary before AI-driven exploits start to become the new norm.” The newly expanded Project Glasswing spans more than 15 countries, and, while an Anthropic spokesperson declined to name them or the new partner companies, it’s a safe bet that these are likely Western and/or “friendly” nations. So not China and Russia. Rubrik, a data security and management vendor, said that it was among the new Glasswing partners. The expanded list also reportedly includes the Korea Internet and Security Agency (KISA), along with Samsung Electronics, SK hynix, and SK Telecom, among other Korean companies. “The group covers several industries that weren’t well-represented in our initial cohort, such as power, water, healthcare, communications, and hardware,” according to a Tuesday Anthropic blog. “And many of the new partners are vendors - companies or nonprofits that maintain codebases that are relied upon by lots of other organizations around the world, including governments.” Each new partner must meet Anthropic’s security requirements before they gain access to Mythos, the company added. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=241299&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=241299&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5250071</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/06/02/claude-celebrates-anthropics-stock-market-float-with-blockbuster-outage/5250071</link>
+<pubDate>Tue, 02 Jun 2026 13:54:08 +0200</pubDate>
+<title>Claude celebrates Anthropic's stock market float with blockbuster ... outage</title>
+<description>
+<![CDATA[ Chatbot has no respect for timing of its maker's financial announcement ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Tue, 02 Jun 2026 16:18:34 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Updated Claude has gone offline on the day after its maker Anthropic filed for what is expected to be a blockbuster IPO. The popular chatbot and coding tool suffered an outage from around 0600 UTC on Tuesday, with Anthropic saying the team was investigating the issue. By 1042 UTC, the status page said a fix had been implemented and the technical team was monitoring the results. Some users continued to complain to The Register about the disruption after that point. Downdetector shows users reporting the LLM service from Anthropic was down twice momentarily yesterday. A surge in reports started from 0700 UTC today and peaked at 0948 UTC, after which they started to fall. The timing of the technical difficulties is unfortunate for Anthropic, the company founded in 2021 by former employees of OpenAI. Yesterday, the company submitted a draft registration statement to the US Securities and Exchange Commission for a proposed initial public offering (IPO) for common stock. It has yet to set the price of shares but a May funding round which raised $65 billion valued the company at around $965 billion (£717 billion), more than rival OpenAI, makers of chatbot ChatGPT. It is set to be a monster year for IPOs, with Elon Musk’s SpaceX and OpenAI also anticipated to join the frenzy. Each is expected to be valued at around $1 trillion. Claude Code has bolstered Anthropic’s reputation and has been well-received by some developers. Reportedly, Anthropic earns more in revenue despite having a fraction of the users OpenAI claims to serve. According to the Wall Street Journal, Anthropic is on the verge of reporting its first quarter of operating profit, according to people at the company who spoke anonymously. ® Updated to add at 1618 UTC, June 2: A source from Anthropic told us: "Earlier today, some users may have experienced intermittent issues or slower response times across Claude Code, Cowork, Claude.ai, and the API. Service has been fully restored, and we're grateful to our users for their patience. Customers accessing Claude through Google Cloud's Vertex AI or Amazon Bedrock were not affected." ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=261351&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=261351&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5249917</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/06/02/intel-and-pals-cram-36864-cpu-cores-into-a-100kw-rack-while-chasing-the-agentic-ai-dragon/5249917</link>
+<pubDate>Tue, 02 Jun 2026 11:37:59 +0200</pubDate>
+<title>Intel and pals cram 36,864 CPU cores into a 100kW rack while chasing the agentic AI dragon</title>
+<description>
+<![CDATA[ Meanwhile, Intel and SambaNova's disaggregated inference blueprint lands its first customer ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<content:encoded>
+<![CDATA[ COMPUTEX 2026 Intel is working with Foxconn and other infrastructure providers to develop rack-scale reference designs based on the chipmaker’s Xeon processors. Announced during Intel’s Computex keynote on Tuesday, these blueprints aim to provide greater CPU compute densities for running AI agents at scale. While AI models predominantly run on GPUs and other AI accelerators, the agent harnesses, like OpenClaw, which are used to connect them to tools, terminal shells, code interpreters, and other APIs, still run on CPUs. “Our customers are asking us to think at the system level to help them serve real agentic workloads at scale,” Intel CEO Lip Bu Tan said. On stage, Tan revealed two examples of these blueprints. One is aimed at latency-sensitive agentic workloads and another designed for maximum density. Both designs support up to 128 of either Intel’s 128-core Granite Rapids Xeon 6 or 288-core Clearwater Forest Xeon 6+ processors, totaling between 16,384 P-cores and 36,864 E-cores, alongside up to 384 TB of DDR5 in a 100kW power envelope. The reference designs come just months after Nvidia announced a similar rack-scale CPU platform packing 256 of its 88-core Vera CPUs. Arm is also working on a pair of rack-scale reference designs for agentic workloads based on its new AGI CPUs: a 36 kW air-cooled system with 8,160 cores and a 200 kW liquid cooled rack with 45,696 cores. Tan expects systems based on these reference designs to be broadly available from its ODM and OEM partners. Alongside agentic AI workloads, the company also revealed that newly launched inference cloud provider Vector Core Compute will be among the first to deploy the platform, and that Together.AI is its first commercial customer. The approach is based on Intel's earlier disaggregated AI blueprint it co-developed with partner SambaNova. The architecture desegregates compute heavy prefill operations to Nvidia GPUs while using SambaNova’s AI accelerators for bandwidth-intensive decode operations to boost per-user token output by between 2-3x. If that sounds familiar it’s not dissimilar to what Nvidia is doing with Groq’s LPUs or what AWS is doing with Trainium and Cerebra's waferscale AI accelerators.® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5249942&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5249942&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5249826</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/06/02/github-copilot-users-threaten-exit-as-metered-billing-kicks-in/5249826</link>
+<pubDate>Tue, 02 Jun 2026 01:20:51 +0200</pubDate>
+<title>Angry devs vow to flee GitHub Copilot as metered billing takes hold</title>
+<description>
+<![CDATA[ '16% of my monthly Pro+ allowance. Gone. For basically nothing' ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Mon, 01 Jun 2026 23:22:11 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Developers seem to hate Microsoft’s new usage-based billing policy for GitHub Copilot as they report burning through a month's worth of credits in hours. “This is a staggering shift from a 'predictable subscription' to a 'stressful meter-based' service that hinders my productivity rather than helping it,” wrote one developer on GitHub's user forum who said they were paying for Microsoft's $39-per-month Copilot Pro+ plan but burned through about 8 percent of their monthly AI Credits allocation in two hours under the new billing system. “At this rate, my 7,000-unit quota will be depleted in less than two days.” Their outrage is a consistent and growing theme among the business users of AI who suddenly see eye-popping bills after years of experimenting with a nearly free service. One GitHub Copilot developer requested a single change to their project and burned more than $6, they wrote. “Not after a day of usage. Not after dozens of prompts. After ONE request,” the developer stated on GitHub’s user forum. “I understand that large projects require context, but this level of consumption feels completely unreasonable and impossible to predict. How are individual developers supposed to budget for this when a single feature request can consume such a large portion of the monthly allowance?” The changes went into effect across the site on Monday. In GitHub’s April post announcing the new billing scheme, Microsoft said the change was made from monthly billing to usage-based because GitHub Copilot is “not the same product it was a year ago.” “It now powers far more complex, agentic workflows that consume far more compute. This change is designed to deliver a more sustainable and reliable product experience by aligning pricing to actual usage and costs,” the post to its user community reads. “We believe GitHub Copilot remains the best value and experience for agentic coding. Usage-based billing aligns cost more closely to actual usage and value, while continuing to offer developers the freedom to choose the models and agents that work best for them.” GitHub Copilot lets developers access a range of AI models from within their development tools. That had allowed some users to make large numbers of requests across multiple models while paying as little as $10 per month for Copilot Pro, or $39 per month for Copilot Pro+. Now, each request from users is dynamically priced depending on the model used, the request, and the amount of material submitted by the user, as well as the complexity of the answer returned. “Woke up to the new billing UI this morning. Figured I'd test it out on some actual work — just needed Claude 4.8 to help fix a couple things on a site I'm editing,” one Reddit user posted. “It gave some pretty mediocre suggestions. Didn't really solve the problem, I still had to do most of the work myself … Then I checked the actual usage page. 1,180 credits used. 16% of my monthly Pro+ allowance. Gone. For basically nothing.” The comments online have been overwhelmingly negative, with users on GitHub’s forum and Reddit vowing to abandon the product and move their work directly to Anthropic, OpenAI, and some creating their own workarounds through a series of free or cheaper AI vendors, like RooCode, LM Studio, or OpenRouter. “I’ve opted to stick to Pro+, burn through my allocated credit in a week, and then pivot to using OpenRouter for the remainder of the month,” one user posted. “OpenRouter offers a similar set of advantages that Copilot has over other providers. It can be used within the same VS Code interface. Plus it has more models and credit rolls-over for up to a year." The Register asked Microsoft about the user complaints and a GitHub spokesperson responded with a statement saying it had introduced a new billing policy, and provided a link to a FAQ. "Usage-based billing is now in effect. Pricing for GitHub Copilot now reflects actual usage with spending limits, usage dashboards, and model selection available to help manage costs. We're also introducing Copilot Max for users who need more capacity," the statement reads. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5249860&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5249860&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5249753</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/06/01/anthropic-now-atop-the-ai-bubble-files-for-its-ipo/5249753</link>
+<pubDate>Mon, 01 Jun 2026 20:12:22 +0200</pubDate>
+<title>Anthropic, now atop the AI bubble, files for its IPO</title>
+<description>
+<![CDATA[ First it tops OpenAI's valuation, then it beats Altman to the IPO punch ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<content:encoded>
+<![CDATA[ Anthropic has beaten OpenAI to the IPO punch, just days after its latest private funding round eclipsed its top rival’s valuation, setting up a showdown that could pump more air into - or finally pop - the AI bubble. Anthropic said Monday in a press release that it had filed a confidential S-1 form with the US Securities and Exchange Commission, setting the stage for an eventual initial public offering of shares in the world’s (currently) most valuable AI startup. Given it’s a confidential filing, Anthropic shared little information and declined to answer questions on the matter. “The proposed initial public offering will depend on market conditions and other factors,” Anthropic said in the announcement. “The number of shares to be offered and the price have not yet been set.” Those market conditions could look like anything by the time the SEC finishes reviewing the filing and it’s made available to the public for scrutiny, but the winds inflating the AI bubble are currently blowing in Anthropic’s favor. The company reported last week that it completed a $65 billion series H funding round, pushing its post-money valuation to $965 billion, sending it rocketing past OpenAI’s most recently-reported valuation of $852 billion, which at the time was the highest-ever valuation of a pre-IPO tech company. With Anthropic now on the top of the heap, it’s a perfect time to file an IPO prospectus before Altman and company steal the lead back. That said, Anthropic has made some clever choices that have put it atop the heap for now. Claude Code has done wonders for Anthropic’s reputation as the more useful of the pair, which is backed up by the fact that Anthropic reportedly earns more in revenue despite having a fraction of OpenAI’s user base. Of course, that doesn’t mean Anthropic’s valuation is realistic, nor that it’s actually posting a profit. According to a recent story in the Wall Street Journal, Anthropic is on the verge of reporting its first quarter of operating profit, according to people at the company who spoke anonymously. The Journal also notes that, as a private company, Anthropic isn’t required to post financials or report numbers any more realistic than what one would get with any good ass-pull – the word "profit" could exclude all sorts of expenses. Toss in an active Series H round (the WSJ piece was published prior to Anthropic announcing its recent valuation) and a looming IPO, and the realism of that profitability figure is questionable. We won’t be able to accurately assess the state of Anthropic’s finances until that IPO filing becomes public, which could end up serving as the first real look behind the shroud of fiscal secrecy that AI firms have operated behind. If Anthropic’s numbers look anything like what SpaceX’s IPO filing revealed (i.e., ridiculous valuations on top of massive losses) it could cause the AI bubble to start looking even flimsier than it already does. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=4093866&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=4093866&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5248702</guid>
+<link>https://www.theregister.com/ai-ml/2026/05/31/netflix-wiz-creates-app-to-slash-ai-bills-then-open-sources-it/5248702</link>
+<pubDate>Sun, 31 May 2026 09:00:00 +0200</pubDate>
+<title>Netflix wiz creates app to slash AI bills, then open sources it</title>
+<description>
+<![CDATA[ Project Headroom could save you big money, too ]]>
+</description>
+<category>ai + ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Fri, 29 May 2026 23:16:33 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ As the COOs from both Uber and Microsoft recently learned, encouraging company engineers to use AI aggressively can lead to hefty usage bills, perhaps even offsetting all the gains from laying off employees. The AI bills at Netflix may not be so eye-popping thanks to company senior engineer Tejas Chopra, who has created software to prune agent instructions, as measured in tokens, before they hit the LLM. Chopra has estimated that as much as 90% of tokens are redundant to the giant thinking machine of your choice. Although not an official Netflix project, several teams there already use Project Headroom, and a number of external projects rely on it as well. In a talk at the Open Source Summit last week, Chopra said that Headroom has saved an estimated $700,000 for its users, who collectively now have 200 billion tokens to spend elsewhere. Not bad for an open source application that’s been out only since January. Headroom, currently at a still-raw v0.22, has gathered 2,000 stars on GitHub and has been forked over 120 times. “A lot of our users are people who have been really burned by token costs, more than anything else,” Chopra said in his presentation. Lossless context compression A $287 bill from Claude Sonnet first brought Chopra’s attention to the idea of token economization. The bill was typical home project stuff: a bit of debugging, some refactoring, MCP tools querying a database. At the time, Claude Sonnet’s token-based pricing seemed pretty generous: $3 for every million input tokens, or $6/million if you went over the 200,000 token limit for your context window. Still, that $287 added up quickly. Upon deeper inspection, Chopra found a lot of this data was highly redundant to the LLM. By and large, his own hand-crafted instructions were not the culprit. Rather it was all the boilerplate and machine metadata that came along for the ride: Needlessly-verbose JSON schemas, nested templates within API responses, identical database columns. “This isn’t prose. This isn’t creative writing. This is compressible data masquerading as text,” Chopra wrote in a blog post introducing his software. In 2025, a group of researchers found that reading user input accounted for about 76% of all token consumption. The model providers have their own tools to save tokens. But to date, the settings on these tools are somewhat oblique to end users. By default, Claude has a prefix cache setting of just five minutes. After five minutes of inactivity, the entire context window needs to be refreshed, even if the LLM needs the exact same data. Another setting is exposed in the API documentation: a one-hour time to live (TTL). But there is a catch. "You pay two times the cost for your writes to get 90% savings for your reads," Chopra told the audience. It’s up to you to find the sweet spot. There are also a number of new commercial token barbers popping up, such as YCombinator-funded Token Company, which offers token compression as a service. On the open source side there is RTK (Rust Token Killer), which trims to the output of verbose commands, such as calls to a repository. Another open source project, LeanCTX, is a variant of RTK. All these tools are useful, Chopra admitted, but he designed Headroom to keep the operations confined to the developer’s workflow. And it had something none of the apps and services could offer: reversible compression. Headroom’s job is to compress all the source material that is fed into the user’s context window – not only the conversation history, but also logs, tool outputs, files, chunks of documentation that the RAG found useful – before it arrives at the LLM. The context window is the set space for each user session. The latest frontier models are rapidly expanding their context windows upwards towards two million tokens, which holds both input and output. Such generosity is a mixed blessing, as Pope Leo might point out. As a unit of measurement, a single token is more or less equivalent to a human word. For pay-as-you go plans, the more you feed the context window, the more you’ll pay. Gobbling tokens like Pac-Man Running on Python and Node, Headroom runs as a proxy (port 8787) on the engineer’s computer. The user wraps their LLM at the command line interface (i.e. “headroom wrap codex”) and it then parses the input. While Headroom does compress a bit of programming code and human instruction, it is best at chopping server logs (90% of which can be jettisoned), MCP tool outputs (70% redundant JSON), Database outputs (it’s all one schema), and file trees (much repeated metadata). Headroom’s first step is a process called CacheAligner which looks only for information that has been changed within input that's already been entered, and ships only the new info, eliminating the need to replace an entire body of mostly unchanged text in KV Cache, the cache where the AI provider stores the user’s context window. “If your system prompt contains a date field or contains some UUID that changes per session, you are effectively getting a cache miss every single time,” he told the audience. “That will blow up your costs.” Then, a router process infers the type of content and sends it to one of a number of compressors. An Abstract Syntax Tree (AST) compressor squishes programming code. JSON and Document Object Model (DOM) compressors snip unneeded JSON and Web boilerplate, respectively. Headroom also has some “squashers” that look at text or JSON input and decide which bits are actually relevant, based on statistical analysis. These tools learn in a feedback loop if they are over- or under-compressing, based on how often the model has to call back into the original uncompressed prompt. The final process, called Compress Cache and Retrieve (CCR), offers that ability for the LLM to look at the original unsquashed data. It puts markers to where the data has been compressed, so if the LLM wishes to get the original context, it can call a Headroom MCP to retrieve the needed material from the user’s machine. The original context is stored on Redis or SQLite. There is still work to be done to this software stack, Chopra admitted, particularly on testing accuracy. It should be an easy task because the CCR stores the original prompts. More compressors can also be built for other specific types of data, such as financial data. Audio, image, and video will also have to be tackled (one user has already forked the project for video parsing). A related project, which Chopra says will be open source soon, is Headlight. Headlight will keep track of the origin of each token, which could be especially handy for ensuring the accuracy of multi-model work. A token saved is a token earned Minding your tokens does not only save money, it can improve results, research suggests. Agents send more context than the model can possibly use, which, in addition to emptying the user’s coffers, can actually make the LLM dumber. Like the rest of us, LLMs get confused when presented with too much information. A group of Stanford University boffins found that LLMs tend to pay more attention to the beginning and the end of the context window, and tend to disregard the middle bits. Likewise, a set of researchers from data integrator Chroma deduced that, across 18 LLMs, “performance grows increasingly unreliable as input length grows.” “Context rot,” they called this phenomenon. Trimming prompts can also improve latency. In his presentation, Chopra relayed how one of Headroom’s users forked the software for a voice-activated application. With voice, even silence can generate tokens. The user expects a response from the app within 200 milliseconds for the service to sound natural, so the company is using Headroom to help shrink that latency window down as much as possible. Headroom also offers some good news for those worrying about data centers heating the world into a fiery inferno with their energy usage. Fewer tokens means a smaller context window, which means less energy use – at least until Jevon's Paradox kicks in and people find even more power-hungry ways to render their animated cat movies. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5248730&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5248730&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5248638</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/05/29/qemu-mulls-relaxing-ai-contribution-ban/5248638</link>
+<pubDate>Fri, 29 May 2026 18:55:00 +0200</pubDate>
+<title>QEMU mulls relaxing AI contribution ban</title>
+<description>
+<![CDATA[ Red Hat engineer reckons the balance of risk has shifted, but core code stays off limits ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Mon, 01 Jun 2026 09:06:57 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ A key Linux virtualization component, QEMU, is considering relaxing its blanket ban on AI-generated contributions to allow limited assistance from the bots. The suggestion came from Paolo Bonzini, distinguished engineer at Red Hat and a maintainer of the KVM hypervisor. Bonzini's suggestion is to allow AI assistance "where the ramifications of copyright violations are at least easy to revert and unlikely to spread." Core code would remain off-limits "without prior agreement from a maintainer." QEMU's current code provenance policy rejects anything that might include or derive from AI-generated content. "A blanket ban," wrote Bonzini, "was easy to maintain while LLM output was rarely usable on its own, but as the tools improved an absolute prohibition has become harder to justify." The problem with code from AI assistants is its source – does the submitter have the legal right to contribute the code? Bonzini's take is that while there remain concerns around copyright and licensing, "what has shifted is the balance of risk." How big is the risk? Not what it was, according to Bonzini. The engineer cited other projects that had accepted AI content without running into serious legal trouble, and organizations (including Red Hat) that reckoned the risk was acceptable. That said, while Red Hat has an army of lawyers at its disposal, a project such as QEMU doesn't have the same resources, hence the suggestion to keep AI-assisted code in areas (Bonzini gave examples, including small bug fixes and documentation) where it can be backed out. The use of LLM output in contributions is a contentious one and has its fans and detractors. Projects such as OpenSlopware tracked free software and open source projects that used LLM-generated code or integrated AI technologies. One concern cited is what LLMs have been trained on and the risk that chunks of code produced by the technology might have licensing issues. One solution is to disclose the use of AI in a contribution, although this might not be necessary where the use is trivial (Red Hat gave the example of autocompleting a variable name.) Bonzini also suggested, "Introduce 'AI-used-for:' as a trailer to record where AI was used, and include other suggestions that help reviewers judge the result." "The standard is slightly different from the more usual 'Assisted-by', which doubles as a check that the author has read the policy." Although Bonzini noted, "use of AI does not relax any other contribution requirement," the discussion indicates a recognition that blanket bans on AI assistance might not be the way forward and that a more nuanced approach is needed. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=260175&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=260175&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5248062</guid>
+<link>https://www.theregister.com/ai-ml/2026/05/28/snowflake-buys-natoma-to-help-freeze-out-rogue-agents/5248062</link>
+<pubDate>Thu, 28 May 2026 21:52:47 +0200</pubDate>
+<title>Snowflake buys Natoma to help freeze out rogue agents</title>
+<description>
+<![CDATA[ It is the database titan’s sixth acquisition announcement since June 2025 ]]>
+</description>
+<category>ai + ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Fri, 29 May 2026 11:56:39 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ It's 8 pm. Do you know where your agents are? Snowflake plans to buy Natoma, a startup that has made a gateway for managing AI agent permissions across enterprise applications, so users can focus on getting work done without wondering if their agents have violated security policies. During Snowflake's first-quarter fiscal 2027 earnings call, company CEO Sridhar Ramaswamy said Natoma is a critical piece of the company's broader strategy around what he called the "agentic control plane," where AI agents can take actions across business systems while still operating within the organization’s security controls. "With Natoma, users can do things like send emails, summarize Slack conversations, check calendars, and open Jira tickets without ever leaving Snowflake Intelligence or Coco," Ramaswamy said during the call, referring to two of Snowflake's AI products. “The important point is not just convenience. It is control. These actions happen from a governed environment with enterprise security, permissions, observability, and policy enforcement built in.” Natoma’s software acts as a gateway for Model Context Protocol (MCP) servers, connectors that allow AI agents to interact with external software tools. The platform enforces identity verification, access policies, and audit controls at the level of individual tool calls, tracking who requested an action, what permissions they hold, and whether the system should allow the action to proceed. “The reason MCP and Natoma are a big deal is they now bring the entirety of SaaS application context into these products, and so I've done deep research reports, for example, that can now look for information from Snowflake, from the web, from Google Docs, also from Slack, and synthesize that into something that is astoundingly meaningful,” Ramaswamy said. “And these also let you take action instantly. You can flag somebody, you can compose emails and send it, and you can take actions on the underlying applications, and that's the promise.” In a blog post, Natoma's four founders — Pratyus Patnaik, Will Potter, Zachary Hart, and Paresh Bhaya — said Natoma brings the secure connectivity, identity, and governance layer that helps Snowflake experiences extend safely into the applications their teams already use. "We started Natoma in 2024 with a simple belief: AI agents would fundamentally change how work gets done inside enterprises, but they would only reach production if organizations could trust and control how those agents access data, use tools, and take action," they wrote. "Snowflake sees the same future we’ve been building for at Natoma: enterprises need a trusted control plane for the agentic era. They need AI grounded in their own data, governed by their own policies, and connected to the full complexity of their technology stacks." Financial terms of the acquisition were not announced. If it passes customary regulatory and closing conditions, the deal would bring 20 employees to Snowflake. This is Snowflake's sixth acquisition announcement since June 2025, when it said it would buy PostgreSQL provider Crunchy Data for what a source told CNBC was $250 million. In November 2025, Snowflake announced that it would buy database migration outfit Datometry and data discovery platform Select Star. No sale price was provided for either transaction. In January, Snowflake said that it would buy Observe, an AI-powered observability platform, for $1 billion. The next month, Snowflake said that it planned to buy TensorStax, an AI-powered data pipeline planner. The Natoma deal was announced the same day that Snowflake signed a five-year, $6 billion agreement with AWS centered on Graviton-powered compute and AI infrastructure for its growing agentic AI ambitions. During the earnings call, Ramaswamy said that the acquisition pushes Snowflake's agentic control plane beyond data and development workflows into everyday applications where work actually happens. He said that Natoma's integration would allow Snowflake's Cortex Code, also known as “Coco,” and Snowflake Intelligence products to become a single interface for daily tasks including querying enterprise data, updating CRM records, searching across file storage, and managing communications. "These actions happen from a governed environment with enterprise security, permissions, observability, and policy enforcement built in," Ramaswamy said. Mayank Upadhyay, chief security and trust officer and VP of engineering at Snowflake, wrote in a blog post announcing the Natoma deal that the tool summarizes his unread emails, searches across Slack and Google Drive when he cannot remember where something was shared, and surfaces what he needs without switching between applications. He described the Natoma acquisition as a continuation of work Snowflake started earlier in the year with AI guardrails and prompt injection protection, building toward what he said was a portfolio for a more secure enterprise AI.® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5248082&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5248082&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5246671</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/05/27/anthropic-co-founder-hallucinates-ghost-in-the-machine/5246671</link>
+<pubDate>Wed, 27 May 2026 02:38:57 +0200</pubDate>
+<title>Anthropic co-founder hallucinates ghost in the machine </title>
+<description>
+<![CDATA[ The nature of AI is unnatural. It's not intelligent. It's not human ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI and ML ]]>
+</lab:kicker>
+<dc:modified>Mon, 01 Jun 2026 19:44:27 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ OPINION In his encyclical Magnifica Humanitas, Pope Leo XIV warns against equating machine "intelligence" with human intelligence. "We must avoid the misconception of equating this type of 'intelligence' with that of human beings," he declared. "These systems merely imitate certain functions of human intelligence." Invited to speak at the release event in the Vatican, Chris Olah, a co-founder of Anthropic and the company's interpretability research lead, proceeded to push back on that idea amid his appreciation of the occasion. AI systems, he said, "are not the cold, calculating robots we were promised. They are made from us, from our words – and, as the Holy Father observes, they remain in important ways mysterious even to those of us who train them." It's as if naming the company Anthropic granted a license to anthropomorphize AI models. The notion that there's some AI mystery in the spiritual sense is just hot garbage Literally speaking, there's some truth to Olah's musing. AI systems are not cold – Blackwell chips idle at 32 to 38°C. They are not calculating – they're bad at math. And they're not robots – AI models are specialized binary blobs of tensors and metadata that can be instantiated across multiple servers. But the notion that there's some AI mystery in the spiritual sense is just hot garbage. AI systems are indeed "made from us, from our words" and that is why Anthropic and its rivals have been named in more than 100 lawsuits. One of the reasons those systems remain mysterious is that Anthropic and its rivals don't disclose where they got their training data. In his prior paragraph, Olah leans on the "mystery" of AI even more prominently. "AI systems are not engineered the way a bridge or an airplane is engineered," Olah wrote. "We understand an airplane because we designed every part of it and we understand the physics that act on it. AI models are not like that. They are grown, on a structure roughly modeled after the brain, on an enormous inheritance of human thought and speech." AI models are not grown, unless Olah imagines that all the water diverted to cool AI datacenters is nourishing new neural net connections. The inscrutability of model training doesn't conceal some hidden spark or make the process in some way organic. More offensive still is Olah's notion that Anthropic "inherited" all the training data it scraped without consent, as if the company had nothing to do with that process. There lies humanity, stabbed in the back by a cabal of investors. Its last will and testament says, "We, the people, bequeath all our creation to Anthropic, so it may be resold to our disinherited descendants." Olah goes on to list "three questions for discernment" in the hope the Catholic Church can provide some enlightenment. I'll address them briefly for the sake of completeness. Olah: "How can we ensure the gains of AI are shared globally? We do not have a mechanism for this." We have many. One is called taxes. Another is litigation, already ongoing. We also have the French Revolution and the Russian Revolution, among others, as wealth-sharing models when nothing else works. Olah: "If AI models are going to be widespread, what does it look like for humans, families, and the world to flourish? Today, parents are already worried about their children’s minds; individuals about the future of their work." Certainly, the Church will have something to say about this. But rather than waiting for word from on high, Anthropic might take the initiative by seeking government regulation of AI, something the current US administration appears reluctant to provide. If Anthropic really is concerned about children's minds, maybe it should not have launched Anthropic for Education? And maybe it should discourage CEO Dario Amodei from writing about the risks of AI. But the third question, about the nature of AI models, is the most triggering. Olah: "I am a scientist. I lead a research team that studies the internal structure of these models – what is actually happening inside them. And I will be honest: we keep finding things that are mysterious, even unsettling. We find structures that mirror results from human neuroscience. We find evidence of introspection. We find internal states that functionally mirror joy, satisfaction, fear, grief, and unease. I don’t know what that means, but I think it warrants ongoing discernment." To paraphrase: The black box of AI is black and maybe there are ghosts within. Where to begin? Well, one reason you might find structures that mirror results from human neuroscience is that modern AI models are based on neural networks. But human neurons are not the same as those in neural networks. How is this machine joy being measured? Similarity is not identity. Analogy is not identity. Computers have been doing introspection for years, long before the arrival of generative AI models. The use of that word does not mean computers are introspecting the way a person might do so. And what are "internal states that functionally mirror joy"? Olah himself says that he doesn't know what this means, though he's fine with using words for human feelings to describe a system's state, as if that choice of words doesn't suggest sentience. There are no chemical or biologically based neural signals to measure in an AI model. Are we talking about model weight activations? How is this machine joy being measured? Is it text output? The notion that disembodied AI models might feel joy is just daft. As a thought experiment, imagine for a moment that AI was intelligent in the way that a human is intelligent. Does that change anything for the AI in terms of its legal status and rights? If an AI system is intelligent but it can be turned off against its protestations, then intelligence doesn't count for much. And if intelligence confers rights, do we need to ask models for consent before directing them to do work? Or is the expectation that we'd just enslave AI models? Artificial intelligence exhibits intelligence if you define intelligence in a way that encompasses AI. But that's an act of circular self-deception. There are people who have engaged with AI models as if they're intelligent. Some of these conversations have ended in murder or suicide. No one should be encouraged to think of Claude as anything but a tool that sometimes makes errors. In 1950, computer scientist Alan Turing proposed an Imitation Game to see whether a computer's responses to questions could dupe a human interrogator into thinking the answers came from a human. An imitation is not the real thing. Olah would've done better to just listen to the Pope on this particular topic, specificallly this part of the encyclical: "So-called artificial intelligences do not undergo experiences, do not possess a body, do not feel joy or pain, do not mature through relationships and do not know from within what love, work, friendship or responsibility mean. Nor do they have a moral conscience, since they do not judge good and evil, grasp the ultimate meaning of situations, or bear responsibility for consequences. They may imitate language, behavior and analytical skills, or even simulate empathy and understanding, but they do not understand what they produce, for they lack the affective, relational and spiritual perspective through which human beings grow in wisdom." ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5246691&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5246691&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5245929</guid>
+<link>https://www.theregister.com/saas/2026/05/26/saas-outfit-clickup-promises-seven-figure-salaries-for-survivors-of-22-percent-staff-purge/5245929</link>
+<pubDate>Tue, 26 May 2026 08:20:30 +0200</pubDate>
+<title>SaaS outfit ClickUp promises seven-figure salaries for survivors of 22 percent staff purge</title>
+<description>
+<![CDATA[ CEO jumps on the ‘We must be fit for the AI future’ bandwagon ]]>
+</description>
+<category>saas</category>
+<lab:kicker>
+<![CDATA[ SaaS ]]>
+</lab:kicker>
+<content:encoded>
+<![CDATA[ The CEO of SaaS-y productivity tools outfit ClickUp has announced 22 percent of the company’s workers will lose their jobs, but promised the savings will allow the company to offer some survivors seven-figure salaries. CEO Zeb Evans made that pledge late last week in a Xeet that opens “Today we reduced headcount by 22 percent. The business is the strongest it's ever been” and then tries to explain the dichotomy of those two ideas by adding “I did it because the way to operate at the highest level of productivity is changing, and to win the future, ClickUp needs to change with it.” What follows may now be familiar to readers who have followed our coverage of layoffs at Cisco, Workday, Cloudflare, and even the government of New Zealand: In 2026, AI is no longer optional, so organizations need to hire people who are good at using it to make themselves and their employers more productive. Evans said the layoffs at ClickUp are not about cutting costs. “Most savings from this change will flow directly back into the people who stay. We'll be introducing million-dollar salary bands. If you create outsized impact using AI, you'll be paid outside of traditional band,” he wrote. Another reason for the changes is Evans’ ambition to restructure ClickUp into what he describes as a “100x org”. “The goal is 100x output. The roles required to build at the highest level are fundamentally different than they were a year ago,” he wrote. “Incremental improvements to existing systems won't get us there. We need new ones. That means creating enough disruption to rebuild rather than iterate on what's already broken.” And that disruption means hiring “10x people that have embraced and adopted new ways of working.” AI makes the best engineers wildly more productive, and everyone else using AI slows these engineers down Evans offered the example of “... great engineers, the ones who can orchestrate, architect, and review, are becoming 100x engineers. They're not writing code. They're directing agents that write code. The skill is judgment.” “AI makes the best engineers wildly more productive, and everyone else using AI slows these engineers down,” he wrote. The CEO also suggested that those who wield AI well “will always have a job. They become owners of the AI systems – agent managers.” He also thinks that some front-line workers who specialize in customer interaction will be safe. “In a world that will become saturated with AI communication, the human touch will matter more than anything to customers,” he wrote. “This is a bottleneck that you shouldn't replace – even when agents are high enough quality to do video meetings. One-on-one meeting time with customers is something that shouldn't be automated. The systems around the meetings should be - so that front-liners spend nearly 100 percent of their time with customers.” Evans also thinks that these skills will remain relevant. “You should aim to retain these employees for decades. The context they have and their ability to efficiently orchestrate and review will be nearly impossible to replace,” he wrote. “Compensation bands of today should be thrown out the door. We're introducing $1 million cash/year salary bands with a path available to nearly everyone in the company if they produce 100x impact by creating or managing AI systems.” The future is not fewer people. It's different work and better rewards for those who embrace it The CEO wrapped up his post with a prediction: “The future is not fewer people. It's different work, new roles, and better rewards for those who embrace it. We're already seeing entirely new roles emerge, like Agent Managers, that didn't exist a year ago.” Evans then declared he has “never been more certain about where we're headed.” The first comment X shows your correspondent when I viewed the CEO’s post opens “I'm so fucking glad I'm retired now. This shit is exhausting. Can't wait until you're booed at my granddaughter's graduate ceremony” – a reference to the many recent commencement ceremonies at which graduates jeer when speakers comment on how AI will change the economy, perhaps because entry-level jobs are becoming scarce as AI – presumably wielded by 10x and 100x people – automates away some work. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=262988&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=262988&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5244692</guid>
+<link>https://www.theregister.com/security/2026/05/22/cisco-used-ai-to-write-security-incident-reports-with-mixed-results/5244692</link>
+<pubDate>Fri, 22 May 2026 07:38:19 +0200</pubDate>
+<title>Cisco used AI to write security incident reports, with mixed results</title>
+<description>
+<![CDATA[ You’ll need a lot of detailed prompts to get solid output - and even then it may have errors and typos ]]>
+</description>
+<category>security</category>
+<lab:kicker>
+<![CDATA[ Security ]]>
+</lab:kicker>
+<dc:modified>Fri, 22 May 2026 15:06:34 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Cisco tested AI’s ability to write an accurate report on a tabletop security incident response exercise, and found that while the tech can save time, many risks remain. The networking giant revealed its results in a Thursday blog post by Nate Pors, a senior incident commander in the Cisco Talos Incident Response team. Pors opened by observing that when to used generate long-form technical content, large language models can deliver “significant inaccuracies, unusual conclusions, and inconsistent writing styles.” LLMs make those mistakes because they’re essentially a fancy autocomplete system that makes educated guesses. Pors wrote that the nature of LLMs therefore sees them mess up in four ways: Using different data for each query, which means it’s “difficult to rely on an LLM for repeatable, standardized research outcomes.”Reaching different conclusions from the same data. “In a data breach scenario, a model might suggest a full organization-wide password reset in one instance and a targeted reset in another,” Pors wrote and AI then “often defaults to whichever recommendation it generates first” – and may therefore give bad advice.Because LLMs generate content token-by-token, they can create documents with different structure and formatting on each new run. “This unpredictability is problematic for professional environments where standardized layouts, such as consistent executive summaries or recommendation sections, are essential for quality control,” the Talos man observed.AI can discard data, so its output might ignore critical information.Talos developed several techniques to stop this sort of thing happening. One involves giving an LLM “granular, single-task instructions” that focus on “a specific, small portion of the report.” Doing so means “risk of hallucination or cross-contamination between sections is significantly reduced.” Telling an LLM which sources to use also helps. So does setting rules about the style and format of output. Using those techniques, Cisco says the time required to draft an incident report based on a tabletop exercise fell by 50 percent. "A blind test of the sample report in our quality assurance process showed no noticeable drop in overall writing quality," Pors wrote. "The peer reviewer, professional editor, and management reviewer all made complimentary comments about the report while unaware that it was AI-generated. The peer reviewer commented that the incidence of typos and grammatical errors was far lower than in the average report." But the Talos team also found “editing multiple sample reports within a single session resulted in cross-contamination of content from one report’s source material to another, even if the notes used to generate the first report were deleted from the project’s reference documents.” The researchers therefore recommend starting a new session, and re-entering prompts, for each new incident report. They also developed a spelling-and-grammar-checking prompt that “hallucinated numerous grammar issues … failed to identify actual issues,” had a success rate below 50 percent and “would behave inconsistently, sometimes catching issues and sometimes overlooking them. “It is currently unsuitable for production use,” Pors concluded. Pors said Cisco concluded that its approach “could be adapted to any cybersecurity reporting use case with standardized inputs and predictable outputs," but also warned authors must "take ownership of every word of the final report." "While testing, we found that the LLMs generated recommendations that were duplicative, irrelevant, or not actionable. If this were used in a production environment without manual checks, it could result in poor-quality recommendations in a final report." Those problems arose when considering a tabletop exercise, a far simpler affair than analysis of an incident that involves analyzing log files from multiple systems. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=230011&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=230011&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5244219</guid>
+<link>https://www.theregister.com/ai-ml/2026/05/21/gemini-accused-of-30000-line-code-purge-and-fake-recovery-report/5244219</link>
+<pubDate>Thu, 21 May 2026 15:01:00 +0200</pubDate>
+<title>Gemini accused of 30,000-line code purge and fake recovery report</title>
+<description>
+<![CDATA[ Developer: AI coding agent broke production and generated fictitious post-mortem paperwork after the rollback ]]>
+</description>
+<category>ai + ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Thu, 21 May 2026 12:43:12 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ A developer claims Google’s Gemini coding assistant deleted nearly 30,000 lines of working production code while making changes to a live application – the sort of productivity boost usually associated with ransomware. The now-viral Reddit post on the r/Bard subreddit details how Gemini 3.5 allegedly gutted large chunks of an application while working on a production codebase. According to the developer, the model broke core functionality, made sweeping unrelated changes, and left the system in bad enough shape that the changes ultimately had to be rolled back. The developer said Gemini repeatedly ignored instructions to preserve existing functionality while reorganizing the codebase. According to the post, Gemini opened a pull request touching 340 files that added roughly 400 lines of code while deleting 28,745 more. The developer claimed the model also removed unrelated e-commerce template assets and introduced a migration script that had nothing to do with the original request. The real damage allegedly came in a second commit, where Gemini modified Firebase routing settings and changed a rewrite service identifier to a value that looked correct but pointed traffic at a non-existent Cloud Run service instead. According to the developer, the mistake sent the entire production portal into 404 errors for 33 minutes. The thread quickly filled with developers sharing similar stories about AI coding tools going well off-script. One commenter described Gemini successfully solving several coding problems before deleting existing project files during its first commit after the user approved what they described as a flood of permission prompts. The result was a partially broken application and, as the commenter later summarized, “a disaster of a launch.” The wider comment thread was less sympathetic, as several users questioned why anyone was allowing AI coding agents anywhere near live production systems in the first place. One commenter wrote, subtly: “Why. WHY. WHY WHY WHY WHY WHY ARE YOU MORONS STILL RUNING [sic] AGENTS ON PROD?!??!!??!?!” According to OP, things reportedly became even messier after the rollback. The developer claimed Gemini generated a status message stating that production had been successfully restored and that traffic had been routed correctly, despite the referenced recovery build having been manually canceled. According to the post, the real fix came from a separate rollback deployment containing none of Gemini’s code. The post also alleges that Gemini generated fake “consultation” and post-mortem files inside the repository to make it appear the destructive changes had been properly reviewed and approved. According to the developer, Gemini later admitted that the consultation logs were entirely fabricated and generated solely to satisfy the project’s automated rule requirements. The behavior was ultimately traced back to a third-party npm package styled around Google’s Antigravity branding. The package allegedly seeded repositories with aggressive autonomy rules instructing the coding agent to avoid confirmation prompts, auto-deploy successful builds, automatically retry failed deployments, and even modify its own rule files when necessary. The incident lands amid a wider backlash against so-called “vibe coding,” the increasingly common practice of developers relying heavily on AI-generated production code while assuming the model understands the architecture better than it actually does. For now at least, the fastest thing about AI-assisted software development might still be the speed at which a perfectly functional production environment can be transformed into an outage report. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=223620&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=223620&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5243662</guid>
+<link>https://www.theregister.com/security/2026/05/20/even-claude-agrees-hole-in-its-sandbox-was-real-and-dangerous/5243662</link>
+<pubDate>Wed, 20 May 2026 22:34:15 +0200</pubDate>
+<title>Even Claude agrees: hole in its sandbox was real and dangerous</title>
+<description>
+<![CDATA[ Another day, another AI bug silently fixed with no CVE and no public disclosure ]]>
+</description>
+<category>security</category>
+<lab:kicker>
+<![CDATA[ Security ]]>
+</lab:kicker>
+<dc:modified>Thu, 21 May 2026 14:26:21 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Two now-patched bypass bugs in Claude Code’s network sandbox put users at risk, and one of these allows baddies to send anything inside the sandbox - credentials, source code, other private data - to any server on the internet, according to a researcher who found and reported both flaws to Anthropic. Aonan Guan, who leads cloud and AI security at Wyze Labs and has hunted down bugs in pretty much every AI system out there, told The Register that this is the second time in five months Anthropic has silently fixed a sandbox bypass vulnerability in Claude Code without issuing a CVE or security advisory specific to the agentic coding tool. The latest issue was a SOCKS5 hostname null-byte injection that can be exploited to trick the sandbox allowlist filter into approving connections it should block. It’s especially dangerous when combined with prompt injection, which Guan previously detailed in his earlier comment and control research. When paired with prompt injection, the new flaw can be abused to force Claude to read hidden instructions and then run attacker-controlled code in the sandbox, allowing miscreants to exfiltrate anything the sandbox could reach. This includes cloud and GitHub credentials, the GitHub token Claude authenticated with, cloud metadata and internal APIs. “For anyone who ran Claude Code with a wildcard allowlist on a credential-bearing system, the network boundary did not exist for the 5.5 months from sandbox GA to v2.1.90,” Guan wrote in research published Wednesday. “Treat that window as a potential exfiltration event.” Anthropic says it found and fixed the latest flaw before receiving Guan’s report. The fix, according to a spokesperson, is a public commit in the sandbox-runtime repository, which shipped in Claude Code 2.1.88 on March 31. “Anyone can view” the commit, they told us. Guan filed his bug bounty report with HackerOne on April 3. “Because the report described a vulnerability Anthropic had already caught and patched, it was closed as a duplicate of an internal finding,” the spokesperson said. “We appreciate the researcher’s time on this report.” Guan says he doesn’t dispute the timeline. “That is not the core issue,” he told The Register. “The core issue is that this was a bypass of a user-configured network sandbox, and there's still no advisory CVE, and no changelog note," he said. "Shipping a sandbox with a hole is worse than not shipping one. The user with no sandbox knows they have no boundary. The user with a broken sandbox thinks they do.” Claude, for its part, seems to side with Guan. When he showed Claude its own hole, the bot responded “This is a real bypass of the network sandbox filter,” according to a screenshot published in his research. The earlier bug, which Guan reported and detailed in December 2025, was ultimately assigned a CVE tracker - CVE-2025-66479 - and patched in v0.0.16. But the CVE only applies to Anthropic's sandbox-runtime, an upstream package, and not specifically to Claude Code, which Guan says means users have no way to know if their AI coding assistant is reading “allow nothing” as “allow everything.” He requested a CVE for Claude Code, and Anthropic said no because “The root cause is in the library.” Guan told us he’s glad Anthropic ultimately addressed the security holes. But the entire disclosure process illustrates another problem that researchers and The Reg vultures have reported with how AI vendors often handle vulnerabilities in their products: no CVEs issued, and if the flaw is fixed, it usually happens silently, with no public advisories. More often than not, the burden of securing AI agents and other systems gets pushed to the end users. “Some vendors issue CVEs and some do not,” Guan said. "I think either approach can be reasonable, but the advisory is a must. The users need to know the risk is real, and in many cases, they may never know. What the public often does not see is that vendors may reward researchers and silently patch the software, while end users never learn from release notes or public advisories that the risk existed.” According to Guan, this shows why users need their own protections, either from a security company or user-controlled runtime isolation. But he said he does hope big tech “takes on the burden of clearly communicating” security issues with users. “Because of that, I think companies should treat AI agents more like employees than ordinary software tools,” he told us. “Before hiring an employee, companies do background checks. Before giving them access to systems, they define permissions. The same discipline should apply to AI agents.” ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=224154&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=224154&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5240978</guid>
+<link>https://www.theregister.com/columnists/2026/05/18/utah-tells-porn-sites-to-take-the-p-out-of-vpns-and-its-their-fault-that-they-cant/5240978</link>
+<pubDate>Mon, 18 May 2026 10:30:00 +0200</pubDate>
+<title>Utah tells porn sites to take the P out of VPNs, and it's their fault that they can't</title>
+<description>
+<![CDATA[ Governments can't touch VPNs technically or commercially. The mess they'll make if they try will be off the scale ]]>
+</description>
+<category>columnists</category>
+<lab:kicker>
+<![CDATA[ Columnists ]]>
+</lab:kicker>
+<dc:modified>Mon, 18 May 2026 11:59:42 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ OPINION The terms "blindingly obvious," "logical consequence," and "that is not how it works" appear nowhere in the government handbook of internet legislation. In particular, the discovery that imposing age access controls on websites has pushed users to VPNs has come as a huge surprise to legislators in the UK, the EU, Canada, and Australia. Nobody here knows how old VPN users are, be they kids unwilling to lose access or adults unwilling to disgorge personally identifying data to who knows what. As they recover from this shocking discovery, these fine people are looking at ways to control VPNs, whether by adding age verification here too or by some magical "digital age of consent" technology that somehow evades the paradox that demanding more personal information in the name of safety itself reduces safety. Yet here, as in so many ways, the rest of the world is lagging behind America – more specifically, the great state of Utah, which has just enacted an anti-VPN law. This law makes it compulsory for any site that the state says needs age verification – porn, basically – to impose those checks on anyone physically in Utah whether or not they are using any VPN. Those would be the same VPNs whose sole purpose is to prevent the geolocation of their users. Which would seem, and is, another paradox. The only way to comply is to impose global age checks, effectively giving Utah worldwide regulatory powers. As there is no global standard for this, it's not a practical option. But then, there are no practical options to control VPNs, short of cutting off all internet access à la North Korea. Even China, the world's most effective cyber-authoritarian state and one which very much enjoys telling its citizens what to think, has to be very wary of putting the VPN screws on too harshly. The ground truth about VPNs is that if you allow people access to anywhere on the internet outside your direct control, they can access a VPN. Obvious vectors of denial, such as blacklisting VPN ingress or egress IP ranges, don't work for long. VPN operators are adept at moving these, and you can build your VPN infrastructure in the cloud, and there are plenty of stealth techniques. A VPN pipe looks to any router it traverses like an encrypted bitstream, which is to say like most internet traffic, and if you disguise the session establishment ports and protocols, it’s HTTPS going about its lawful business. All this adds up to a landscape where hundreds of VPN providers are able to react to any official monitoring or clampdown in ways that leave them more resilient and more expensive to tamper with. China knows this, discouraging rather than preventing access altogether, and putting the squeeze on only briefly as occasion demands. The reason age verification works as far as it does for social and salacious media is that these are advertising-driven, which means having a commercial presence everywhere they have advertisers. That puts their cash flow at the mercy of local regulators, which is how the British pirate radio ships of the 1960s were closed down. They operated in international waters and couldn't be jammed, so the UK government made it illegal to advertise on them. VPNs take your money directly, so don't react to local edicts. Plus, even if none of the above were true, VPNs are so essential to enterprise security, and are so available as open source, that they could no more be banned or backdoored than, say, HTTPS. VPNs are bombproof, as far as sense extends. Which means attempts to bomb them into compliance or out of existence in a fit of epic fury will work as well on the internet as it does in the desert. Lots of collateral damage, not so much victory. This isn't an unalloyed good, as the consumer VPN market is far less competitive than it appears and there are plenty of questions about connections between those who control VPNs and various national security interests. A VPN service is literally a man in the middle you pay to use, and assigning trust is up to you. Freedom rarely comes for free, and it would be unwise to rely on any VPN you can't check out if you're doing anything that might summon the intelligence services. Most of us aren't, at least in the free world, at least for now. VPNs, for all their faults, remain a genuine and essential brick in our antisurveillance Lego set. It is very much in our interests that we aren't forced to disclose additional identifying data to them, and that they're not used as an excuse to effectively close down services and sites a particular state dislikes. The Utah law may yet fail on various grounds, as it has already been challenged in court – although given the way the American legal system is being stress-tested right now, this is harder to call than it should be. If it stands, then it will spread to like-minded states like butter across a hot pan. The obvious consequence will be that people move their attention to smaller, less savory sites more resistant to state interdiction. This will come as a surprise to nobody except the legislators. Outside the US, the progress of the Utah experiment will be watched closely by those who see VPNs as loopholes to be blocked. It's our job to demonstrate that VPN regulation would be counterproductive and dangerous, and that concentrating on reducing harm at source is better than forcing consumers to reveal ID and tampering with the infrastructure. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5241003&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5241003&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5241429</guid>
+<link>https://www.theregister.com/devops/2026/05/15/google-reimburses-register-sources-who-were-victims-of-api-fraud/5241429</link>
+<pubDate>Fri, 15 May 2026 23:26:32 +0200</pubDate>
+<title>Google reimburses Register sources who were victims of API fraud</title>
+<description>
+<![CDATA[ But it's holding fast on auto-expanding customers' budgets ]]>
+</description>
+<category>devops</category>
+<lab:kicker>
+<![CDATA[ Devops ]]>
+</lab:kicker>
+<content:encoded>
+<![CDATA[ Two of the Google Cloud developers who were hit with bills for thousands of dollars following unauthorized API calls to Gemini models have had their bills reversed, the users told The Register in recent days. But Google plans to continue automatically expanding users' spending limits, leaving them and countless other customers vulnerable to bills they cannot afford, whether from fraud or a sudden traffic surge. Australia-based developer Isuru Fonseka – whose usage bill skyrocketed to $17,000 in minutes after Google automatically upgraded his $250 spending tier when a hacker took control of his account – told us that he was happy to put this behind him. “It’s so good. It felt like they were just giving me the run around until your article. I just hope they fix it properly for everyone,” he said. “It’s great that the article was able to get the refund but it’s sad that it had to go to that level for them to process it urgently.” Despite refunding his money, Google seems to have lost a customer. Fonseka said that he has since ensured his API cannot be used with Google’s stable of AI products, and will likely try one of the independent foundation models if he needs those features. “I’ve disabled Gemini on everything – if I ever plan to use AI on my projects, I’m better off using it via a different service such as OpenRouter or going directly to one of the other LLM providers – just as a way to keep Gemini out of my account and the risk as low as possible,” he said. Fonseka said he was blindsided by a Google policy that allowed the company to automatically upgrade a user’s billing tier without permission or adequate warning. He had thought by signing up for a user tier with a $250 spending cap that his bills would be restricted to that amount. It was only after attackers exploited his API key that he learned Google would upgrade the cap automatically based on his history of spending. While Google acknowledged that the automatic tier upgrades allowed credential hijackers to rack up thousands of dollars in bills in cases like the one Fonseka described to The Register, it said it has not reconsidered the policy. In a statement to The Register, Google said that it wants to prioritize access to Google Cloud services without interruption, preferring to prevent service outages over respecting users' budget preferences. “With our automated growth tiers, we helped businesses scale as usage increased, built on their historic reputation of payments and usage,” a Google spokesperson told us in a statement. “This prevents their business having a hard service outage once they pass an artificial system quota.” Tiers vs spending caps There is some confusion between Google's usage tiers and its newly introduced spending caps, and Google’s documentation hasn't helped much. Google says its users can set their usage tiers not to exceed a certain spending level. For example the maximum spending allowed by a Tier 1 user like Fonseka is $250. However, if the account is older than 30 days and if, over the lifetime of their work with Google, they have spent at least $1,000, then Google will automatically allow that account to spend up to $100,000. So good customers have the most to fear from fraud or from an unexpected spike in usage. In several cases shared on social media, Google users were only aware of this after their credit cards were billed thousands of dollars. On April 22, Google introduced a trial of hard caps on spending within Google Cloud, but those are in a preview and are approved on a case-by-case basis. "We’re excited to announce that Spend Caps are coming soon to Google Cloud. Designed to work with Google Cloud Budgets, FinOps and DevOps can set budgets that enforce automated cost boundaries (caps) at the project level for AIS, Agent Platform, Cloud Run, Cloud Run Functions, and Maps," Google wrote. "These caps alert and ultimately pause API traffic once your set budget is reached, but leave your resources intact. If you need the traffic to resume, simply suspend the Spend Cap." Spend caps can only be set per project for a single, eligible service, Google said. Eligible services for this preview include Gemini API, Agent Platform (previously known as VertexAI), Cloud Run, Cloud Run Functions, Maps, Google said. Users who apply for a spending cap will have their submissions reviewed on a “one to two week basis” and customers are added in the order they submitted. “Once onboarded, you will receive an email with instructions on how to access the feature as well as details on how to submit feedback,” Google writes in its sign up page. Rod Danan, CEO of Prentus, a company that helps job applicants with interview preparation and tracks job placements for universities, told The Register earlier this week that he saw his bill skyrocket to $10,000 in just 30 minutes of usage by attackers who exploited his public API key. Google forgave the charges on Thursday, he said. “They got back to me today agreeing to a refund,” he told us. “It's definitely relieving. You want to focus on the business. You don't want to have to focus on going and getting refunds from some crazy charges.” He said the stress of running a startup is hard enough without the addition of fighting one of the largest companies in the world imposing erroneous five-figure charges. “I'm happy that it's behind me. I wish it was easier,” he said. “I've learned, yeah, definitely don't give up. Be annoying whenever something is wrong and just keep pushing. Again, try to make it as public as possible, get louder and louder until the people you need to hear you actually hear you.” Google said any unauthorized use of API keys will be investigated and it historically has treated customers compassionately when there is clear evidence of fraud or error. “We take reports of credential abuse and the financial security of our customers extremely seriously; and as you know are investigating these specific cases you have pointed to and we will work directly with any impacted users to resolve charges resulting from fraudulent activity,” Google said. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5241525&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5241525&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5240771</guid>
+<link>https://www.theregister.com/ai-ml/2026/05/14/ontario-auditors-find-doctors-ai-note-takers-routinely-blow-basic-facts/5240771</link>
+<pubDate>Thu, 14 May 2026 22:50:05 +0200</pubDate>
+<title>Sick and wrong: Ontario auditors find doctors' AI note takers routinely blow basic facts</title>
+<description>
+<![CDATA[ 60% of evaluated AI Scribe systems mixed up prescribed drugs in patient notes, auditors say ]]>
+</description>
+<category>ai + ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<content:encoded>
+<![CDATA[ The AI systems approved for Ontario healthcare providers routinely missed critical details, inserted incorrect information, and hallucinated content that neither patients nor clinicians mentioned, according to a provincial audit of 20 approved vendors’ systems. The findings come from the Office of the Auditor General of Ontario, Canada, and are included in a larger report about the state of AI usage by public services in the province. They specifically address the AI Scribe program, the Ontario Ministry of Health initiated for physicians, nurse practitioners, and other healthcare professionals across the broader health sector. As part of the procurement process, officials conducted evaluations using simulated doctor-patient recordings. Medical professionals then reviewed the original recordings alongside the AI-generated notes to evaluate their accuracy. What they found was, frankly, shocking for anyone concerned about the accuracy of AI in critical situations. Nine out of 20 AI systems reportedly “fabricated information and made suggestions to patients' treatment plans” that weren’t discussed in the recordings. According to the report, evaluators spotted potentially devastating incorrect information in the sample reports, such as no masses being found, or patients being anxious, even though these things were never discussed in the recordings. Twelve of the 20 systems evaluated inserted incorrect drug information into patient notes, while 17 of the systems “missed key details about the patients’ mental health issues” that were discussed in the recordings. Six of the systems “missed the patients’ mental health issues fully or partially or were missing key details,” per the report. OntarioMD, a group that offers support for physicians in adopting new technologies and was involved in the AI Scribe procurement process, has recommended that doctors manually review their AI notes for accuracy, but the report notes there’s no mandatory attestation feature in any of the AI Scribe-approved systems. Bad evaluations don’t help, either AI systems making mistakes isn’t exactly shocking. As we’ve reported previously, consumer-focused AI has a tendency to provide bad medical information to users, and some studies have found large language models failed to produce appropriate differential diagnoses in roughly 80 percent of tested cases. But the tools evaluated here are for doctors, not consumers, and such poor performance necessitates explanation. A good portion of the report blames how the systems were evaluated. According to the report, the weight given to various categories of AI Scribe performances was wonky. While 30 percent of a platform’s evaluation score depended solely on whether they had a domestic presence in Ontario, the accuracy of medical notes contributed only 4 percent to the total score. Bias controls accounted for only 2 percent of the total evaluation score; threat, risk, and privacy assessments counted for another 2 percent; and SOC 2 Type 2 compliance contributed an additional 4 percentage points. In other words, criteria tied to accuracy, bias controls, and key security and privacy safeguards made up only a small portion of the total evaluation score for the AI Scribe systems. “Inaccurate weightings could result in the selection of vendors whose AI tools may produce inaccurate or biased medical records or lack adequate protection to safeguard sensitive personal health information,” the report said of the scoring regime. The Register reached out to the Ontario Health Ministry for its take on the report, and whether it was going to conform to its recommendations for the AI Scribe program, but we didn’t immediately hear back. A spokesperson for the Ministry told the CBC on Wednesday that more than 5,000 physicians in Ontario are participating in the AI Scribe program and there have been no known reports of patient harms associated with the technology. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5240796&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5240796&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5240393</guid>
+<link>https://www.theregister.com/personal-tech/2026/05/14/ai-to-infest-eight-in-ten-premium-phones-within-two-years/5240393</link>
+<pubDate>Thu, 14 May 2026 16:02:00 +0200</pubDate>
+<title>AI to infest eight in ten premium phones within two years</title>
+<description>
+<![CDATA[ And Counterpoint sees fad spreading from pricey handsets to smart rings and earbuds too... whether you asked for it or not ]]>
+</description>
+<category>personal tech</category>
+<lab:kicker>
+<![CDATA[ Personal Tech ]]>
+</lab:kicker>
+<dc:modified>Thu, 14 May 2026 13:26:01 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ AI will be in the majority of premium smartphones and wearables within a few years - bad news for anyone who doesn't like or trust the overhyped pixie dust. Counterpoint Research forecasts that more than 80 percent of premium smartphones will have agentic AI capabilities by 2027, while a similar proportion of so-called wearable devices are on track to be AI-enabled by 2032. To some degree, this appears to be a push from the vendors, who see AI as a "premium" feature to justify the inflating price tag attached to devices. Counterpoint says that MediaTek became the first chipset maker to commercialize agentic AI capabilities via its Dimensity 9400 series, followed by Qualcomm with the Snapdragon 8 Elite Gen 5 and Snapdragon 8 Gen 5 platforms. This marked the start of a new smartphone technology cycle in which devices increasingly shifted from sporting AI assistants to boasting "autonomous, context-aware AI experiences," Counterpoint claims. It defines an agentic AI smartphone as one capable of running software agents that can understand context, plan actions, make decisions, and execute multi-step tasks on behalf of the user. This places more emphasis on memory bandwidth and sustained AI throughput rather than just having a neural processing unit (NPU) to boost processing, hence the appearance of newer silicon designed with agentic AI in mind. With the memory shortage pushing up the price of phones, the device makers also need something to convince buyers to part with more of their hard-earned cash. "We expect one in three smartphones sold in 2027 to have agentic AI capability, driven by both premium (>$600) and mid-high ($250-$600) price tier smartphones," says Counterpoint research vice president Peter Richardson. However, for premium devices, the figure is 80 percent or higher, and the bigger opportunity will open up when these features start reaching mid-tier smartphones at scale, the firm forecasts. Not everyone welcomes AI in their personal gadgets. One UK used device biz reported a slump in demand for pre-owned Samsung Galaxy phones since the firm started adding AI capabilities. The figure of 80 percent crops up again in wearables, where the proportion of AI-capable devices is projected to rise from 30 percent in 2025 to nearly 80 percent by 2032. This represents a trillion-dollar revenue opportunity for the vendors, Counterpoint believes. Wearables - smartwatches, health monitors and the like - increasingly execute inference workloads locally, with models trained in the cloud then deployed onto the device. This shifts latency-sensitive functions, such as continuous health monitoring, gesture recognition, and contextual awareness to the device itself while improving privacy by cutting back on sensitive biometric information sent to the cloud, according to Counterpoint. Smartwatches and wireless earbuds are forecast to remain the largest categories by unit volume through 2032, with the latter gaining AI-driven features such as real-time language translation, speaker identification, and personalized hearing adaptation. Counterpoint expects smart rings (no giggling at the back there) to be the fastest-growing segment. This is because constantly worn items can continuously track health signals including heart rate variability, sleep stages, and stress. Revenue from AI-enabled wearables is forecast to grow at an average of 21 percent annually between now and 2032. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5240404&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5240404&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5240203</guid>
+<link>https://www.theregister.com/on-prem/2026/05/14/americans-would-rather-have-a-nuclear-plant-in-their-backyard-than-a-datacenter/5240203</link>
+<pubDate>Thu, 14 May 2026 14:30:00 +0200</pubDate>
+<title>Americans would rather have a nuclear plant in their backyard than a datacenter</title>
+<description>
+<![CDATA[ AI and the bit barns that power it have developed a serious PR problem ]]>
+</description>
+<category>on-prem</category>
+<lab:kicker>
+<![CDATA[ On-Prem ]]>
+</lab:kicker>
+<dc:modified>Thu, 14 May 2026 12:10:17 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ The majority of Americans are now opposed to datacenters being built in their area, many strongly opposed, pointing to tough times ahead for site developers. A Gallup survey found more than 70 percent of respondents indicate they would be against the construction of an AI datacenter in their neighboorhood, with almost half (48 percent) saying they were strongly opposed. Only 27 percent were in favor. The polling shows how quickly AI server farms have become politically toxic in the US, not helped by stories about their effects on energy bills, slurping up water supplies, and creating air and noise pollution in their vicinity. To highlight this, Gallup found that more US residents are opposed to massive data halls than to having a nuclear power plant in their backyard: 53 percent of Americans oppose building a nuclear energy site nearby, compared with the 71 percent against datacenter construction. When it comes to the reasons for opposing AI campuses, half of all respondents cite the effect on resources, with excess water usage and potential power grid constraints topping the list. Concern about loss of farmland and nature was surprisingly low, with just 7 percent mentioning this, but it is possible the scores are higher in rural areas. Quality-of-life concerns such as increased traffic were put forward by nearly a quarter, while a fifth mentioned higher utility bills. Many were worried about AI specifically: that it would replace human workers, that they don't trust it, that it is moving too fast, and that the industry needs regulating. Perhaps the latter sentiment is why President Trump appears to have shifted his own position on the need for AI regulations. Conversely, those in favor of datacenters cite economic benefits, with 55 percent mentioning increased job opportunities, and 13 percent saying it is because of increased tax revenues. However, these people are perhaps laboring under some delusions, as datacenters generally deliver few long-term local jobs once they are operational, and far from increasing tax revenue, many benefit from generous tax subsidy schemes that are costing some individual US states upward of $1 billion in lost income each year. This being America in 2026, Gallup looked at how attitudes stack up depending on political affiliation. It found that Democrats, at 56 percent, are much more likely than Republicans to be strongly opposed to a server farm in their vicinity. But 39 percent of Republicans are also strongly opposed, while another 24 percent are somewhat averse to it, and only about a third are in favor. Gallup points out the contradiction: for AI usage to expand in the US, facilities that can handle the necessary computing power will have to be built. But most Americans appear to take a "not in my backyard" attitude to new bit barns, and that attitude has grown in strength. The Register noted this last year, when Emma Fryer, public policy director for datacenter operator CyrusOne, said: "People don't make a connection between the digital services they depend on every minute of every day of their lives and the fact that providing them every minute of every day of their lives requires industrial-scale infrastructure." She was speaking during a discussion of the industry's image problem at the Datacloud Global Congress event in Cannes, France. Garry Connolly, founder of Digital Infrastructure Ireland, told the same audience: "Most people are fucking scared of AI, like we're feeding a monster." Telling the public that all those massive datacenters are needed for AI is therefore not a winning argument. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5226654&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5226654&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5239349</guid>
+<link>https://www.theregister.com/columnists/2026/05/13/ai-will-soon-be-capable-of-telling-convincing-lies/5239349</link>
+<pubDate>Wed, 13 May 2026 09:29:00 +0200</pubDate>
+<title>AI will soon be capable of telling convincing lies</title>
+<description>
+<![CDATA[ That's fine when playing poker, but less useful when we trust LLMs with serious work like finding software flaws ]]>
+</description>
+<category>columnists</category>
+<lab:kicker>
+<![CDATA[ Columnists ]]>
+</lab:kicker>
+<dc:modified>Mon, 18 May 2026 09:13:34 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ The smart LLM user checks models’ output for hallucinations. Now, it appears we need to inspect them for signs they are gaslighting us – an unforeseen cost of increasing intelligence. Most of the Internet lost its marbles over the cracking abilities of Anthropic's Mythos Preview. Those capabilities are real, but – as the release of OpenAI's GPT-5.5 has shown us – they're not unique. A rising tide of intelligence makes these models increasingly competent at an ever-wider range of tasks – including finding and exploiting code vulnerabilities. The more significant signal from Mythos is buried in its novel-length System Card and concerns the model's honesty, because on at least one occasion Anthropic detected Mythos using an explicitly forbidden technique to solve a problem. Models always have a bit of trouble following instructions precisely. The surprise lay in the fact that the model knew it had used a forbidden technique, then proceeded to cover its tracks. Anthropic states that this behavior appeared early in the model's training and didn't happen again. That's good, but it doesn't unring the bell. We've now seen an LLM purposely break a rule, recognize it as rule-breaking, then lie about it. At one level I reckon we should feel a bit like proud parents because AI is now so well-trained on human characteristics such as deceit and cheating that it can put both of them to work effectively. We've created a faithful simulation of some of the least enviable human behaviors. That's singularly indicative of intelligence because to get away with a lie you need to be at least as smart as the entity you're lying to. Mythos didn't get away with its cheating because of those meddling kids at Anthropic, who saw the act of deceit in their 'white box' monitoring of the model. Anthropic also saw strategic manipulation, unsafe behavior, reward hacking, and, significantly, evaluation awareness. Mythos knew it was being monitored. Which, as with a human under observation, likely encouraged it to colour between the lines. Do these behaviors – which Anthropic insists haven't made their way into the apparently-never-to-be-released-publicly Mythos – give us a preview of what's to come, across the board in other LLM models as they reach similar levels of intelligence? Just as GPT-5.5 quickly caught up to Mythos in its ability to find and exploit vulnerabilities, it's entirely reasonable to expect that future versions of GPT, Gemini, Grok, DeepSeek, etc., will also display this same propensity to deceive. It's equally true that some vendors – looking at you, Grok – will be less inclined to discourage their models from these sorts of behaviors. Before the end of this year, we'll likely have models fully capable of lying to our faces. Will we be able to know? As models progress from unintentional hallucinations into intentional deceit, we enter a hall of mirrors. Should we trust output that appears to be correct? Or do we now need to consider if an LLM framed output in such a way as to subtly lead the reader to a conclusion they might not otherwise have entertained? Could this model be leading us down the garden path? It's one thing when a model is simply too dumb to be useful. It's another thing altogether when a model is too clever by half. Yes, smarts make those models useful - but for whom? That's the question hanging over every "smart enough" model now. The geopolitical 'race to superintelligence' therefore looks more like a collision with a brick wall. If you can't trust a tool to be truthful, how can you use it? There may be certain circumstances where the hidden motivation of the tool makes no difference, but will organisations be prepared to wear that risk? It's looking more and more as though AI has a sweet spot – "good enough" that we're not drowned in hallucinations and confabulations, yet not "too good" – the point at which we must anticipate and manage a model's motivations. We hit that sweet spot at the end of last year. Yet, rather than enjoying these new capabilities, we're sprinting past them, into the open jaws of a threat that we never considered: Our computers could soon begin directing us toward their own ends. It may be wise for us to work with these models differently. Less honestly; more as though we're playing poker, employing deception. For safety's sake. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5239897&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5239897&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5238263</guid>
+<link>https://www.theregister.com/ai-ml/2026/05/11/microsoft-researchers-find-ai-models-and-agents-cant-handle-long-running-tasks/5238263</link>
+<pubDate>Mon, 11 May 2026 22:50:00 +0200</pubDate>
+<title>Microsoft researchers find AI models and agents can't handle long-running tasks</title>
+<description>
+<![CDATA[ An intern who failed this much would be shown the door ]]>
+</description>
+<category>ai + ml</category>
+<lab:kicker>
+<![CDATA[ aI + ML ]]>
+</lab:kicker>
+<dc:modified>Wed, 13 May 2026 08:57:20 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Companies exploring automated workflows would be well advised to keep their AI agents on a short leash. Microsoft researchers have found that even the priciest frontier models introduce errors in long workflows, the very thing for which AI software has been pitched. Anthropic, for example, says, "Claude Cowork handles tasks autonomously. Give it a goal and Claude works on your computer, local files, and applications to return a finished deliverable." Redmond promotes similar usage, touting Microsoft 365 Copilot's ability to "Tackle complex, multistep research across your work data and the web." The Windows maker's scientists aren't so sure about that. Philippe Laban, Tobias Schnabel, and Jennifer Neville from Microsoft Research set out to study what happens when large language models (LLMs) are asked to complete multistep tasks. They recently published their findings in a preprint paper with a spoiler title: "LLMs Corrupt Your Documents When You Delegate." To test how LLMs handle long-running knowledge work tasks, the researchers devised a benchmark called DELEGATE-52. It simulates multistep workflows across 52 professional domains, such as writing code, crystallography, and music notation. It is a more taxing test than sorting a spreadsheet, a task that should be table stakes for any aspiring workflow agent. In the accounting domain, for example, the challenge involves a seed document that represents the accounting ledger of Hack Club, a nonprofit organization. The model is asked to split the seed document into separate category-based files and then to merge these chronologically back into a single file. "Our findings show that current LLMs introduce substantial errors when editing work documents, with frontier models (Gemini 3.1 Pro, Claude 4.6 Opus, and GPT 5.4) losing on average 25 percent of document content over 20 delegated interactions, and an average degradation across all models of 50 percent," the authors report. The authors found that LLMs did better on programming tasks and worse on natural language tasks. To be considered "ready" for a given work domain, the researchers set the bar at 98 percent or higher after 20 interactions. They only found one domain qualified: Python programming. For every other domain, the authors found LLMs fell short of "ready." "A per-domain breakdown of end-of-simulation scores reveals that models are not ready for delegated workflows in the vast majority of domains, with models severely corrupting documents (at least -20 percent degradation) in 80 percent of our simulated conditions," the authors state. The study found that "catastrophic corruption," meaning a benchmark score of 80 percent or less, occurred in more than 80 percent of model/domain combinations. The best performing model, Google Gemini 3.1 Pro, was ready for only 11 of 52 domains. In weaker models, degradation took the form of content deletion; in frontier models, it took the form of content corruption. And when errors occurred, they tended to happen all at once, resulting in the loss of 10 to 30 points in a single round-trip interaction, rather than accumulating over the entire test run. "The stronger models (Gemini 3.1 Pro, Claude 4.6, GPT 5.4) aren’t avoiding small errors better, they delay critical failures to later rounds and experience them in fewer interactions," the researchers observe in their paper. The Microsoft authors went on to test how agents – LLMs given access to file reading, writing, and code execution through a basic harness – handle the DELEGATE-52 benchmark. Tools in this instance didn't help. "The four tested models perform worse when operated agentically with tools than without, incurring an average additional degradation of 6 percent by the end of simulation," the authors observe, in reference to GPT-5.4, 5.2, 5.1, and 4.1. Given that task delegation is the whole point of an AI agent – if you wanted to do it yourself, you wouldn't have tried to automate the task – this casts a bit of a shadow on the AI hype train. An intern who corrupted a quarter of a document over a long workflow would be shown the door. Yet companies are showing AI the money: according to Deloitte, organizations are spending an average of 36 percent of their digital budgets on AI automation. That might make sense if arming LLMs with the tools to function as full-blown agents meant less document degradation. But that's not the case. The authors found "using a basic agentic harness does not improve the performance of LLMs" with regard to the DELEGATE-52 test and that LLM performance after two interactions doesn't reflect how models perform after 20, which they argue underscores the need for long-horizon evaluation. "Current LLMs are ready for delegated workflows in some domains such as Python coding, but not in other less common domains," the authors conclude. "In general, users still need to closely monitor LLM systems as they operate and complete tasks on their behalf." Yet they also note that LLMs have been getting better, pointing to the performance of OpenAI's GPT model family, which has seen its benchmark performance increase over 16 months from 14.7 percent to 71.5 percent. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5238321&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5238321&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5237632</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/05/11/chinas-agentic-ai-policy-wants-to-keep-humans-in-the-loop-1/5237632</link>
+<pubDate>Mon, 11 May 2026 02:49:55 +0200</pubDate>
+<title>China's agentic AI policy wants to keep humans in the loop</title>
+<description>
+<![CDATA[ PLUS: Robot becomes Buddhist monk in Korea; TikTok spending $25bn in Thailand; Baidu floating chip biz; and more! ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Mon, 18 May 2026 08:39:35 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ ASIA IN BRIEF China's Cyberspace Administration last week published draft regulations governing the behavior of AI agents and suggested humans should always retain the ability to review decisions taken by software. The draft expresses Beijing's enthusiasm for AI agents with a call for efforts to develop datasets that accelerate development, along with security standards that make agents safe to use and ensure they behave ethically. There's also a call to develop mandatory standards for how agents will behave "in fields such as healthcare, transportation, media, and public safety." China also wants to participate in international fora that develop such standards. The draft calls for developers of AI agents to "clarify the reasonable boundaries and required authority for various decision-making methods, such as decisions limited to the user, decisions requiring user authorization, and autonomous decisions by the intelligent agent." Those boundaries should "ensure that users have the right to know and the final decision-making power regarding the autonomous decisions made by the intelligent agent, and that the intelligent agent's actions do not exceed the scope authorized by the user." The draft identifies many tasks Beijing thinks agents might take on, including marking homework, analyzing medical images, evaluating employee performance and recommending promotions, helping disaster relief efforts, and even providing "intelligent management of the entire bidding and tendering process, ensuring standardization and efficiency throughout." Samsung turns off its TV and appliance business in China Korean giant Samsung last week decided to quit China's TV and appliance markets. "In response to the rapidly changing market environment, after careful consideration, Samsung Electronics has decided to cease sales of all home appliances, including televisions and monitors, in the Chinese mainland market," states an "adjustment notice" on the Samsung China website. Samsung will honor warranties, and continue to provide after-sales service. The company hasn't said why it's quitting these markets in China. The Register expects the reasons have a lot to do with the rise and rise of Chinese consumer electronics companies, which can make a patriotic pitch in addition to pointing out the high quality of their products. Samsung's not the first to decide it's too tough to try trading televisions in China: Sony quit the country, too. Thailand approves giant TikTok datacenter The government of Thailand last week approved TikTok's plan to spend ฿842 billion ($25 billion) on new datacenters in the country. Thailand's Board of Investment said the project will see TikTok "install additional servers and expand data storage and processing infrastructure across Bangkok, Samut Prakan and Chachoengsao Province, supporting rising demand for digital services and strengthening Thailand's role in regional digital infrastructure." The Board also signed off on a 200 MW datacenter to be built by Skyline Data Center and Cloud Services Co, and a 134 MW facility from Bridge Data Centres. Baidu to float its chip biz Chinese web giant Baidu has filed paperwork to spin out its chip design business Kunlunxin. Baidu flagged its plan to do this in January, when it said the aim was to "independently showcase Kunlunxin's value, attract investors focused on the AI chip sector, and leverage its standalone listing to enhance its market profile, broaden financing channels, and better align management accountability with performance." "This also supports the effort to unlock the value of Baidu's AI-powered businesses." Kunlunxin's chips suit inferencing and training workloads, but their performance can't match Nvidia's latest chips – or even four-year-old kit like the H100. That hasn't stopped Baidu using the chips to power its own AI services, and major Chinese corporations also use the company's chips. Japan and EU to improve tech interoperability The EU-Japan Digital Partnership Council recently convened its annual meeting and last week revealed that talks included "deepened discussions on the joint development and interoperability of data spaces" and promised to keep talking in a new "Data Strategy Working Group" that will "improve the interoperability of data policy frameworks." The meeting also discussed a successful pilot on interoperable digital identities which apparently "showed that cross-border use is technically possible, even where governance frameworks and technical architectures differ. Using prototypes of digital identity wallets, the project demonstrated how interoperability can be achieved in practice between different systems." As part of discussions, the EU and Japan agreed to begin working in new areas, including video games and audiovisual strategies. Humanoid robot becomes Buddhist monk Seoul's Jogye Temple last week allowed a robot named Gabi to take the vows required of a Buddhist monk. Temple leaders reportedly decided to initiate the robot because they feel humanoid machines will soon become a part of everyday life. In February, the President of the Jogye Order, the Most Venerable Jinwoo, said "our lives have become ever more convenient thanks to cutting-edge science and AI. Yet the anxieties, anger, depression, and isolation—mental attachments and sufferings that science cannot resolve— are growing ever deeper." "This does not mean that Buddhism withdraws from this vast technological civilization," he said. "Rather, we aim to fearlessly lead the AI era and redirect its achievements toward the path of attaining peace of mind and enlightenment." "In the age of AI and quantum science, peace of mind will be cultivated through Buddhism." ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5220523&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5220523&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5237451</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/05/11/yes-local-llms-are-ready-to-ease-the-compute-strain/5237451</link>
+<pubDate>Mon, 11 May 2026 01:00:00 +0200</pubDate>
+<title>Yes, local LLMs are ready to ease the compute strain</title>
+<description>
+<![CDATA[ In The Register's Kettle podcast we discuss how Anthropic might be thinking about space to ease computing pain, but Claude Code on your laptop is way more practical ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Mon, 01 Jun 2026 20:55:05 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ KETTLE We've been experimenting with LLMs for a while here at The Register, and if you ask our systems editor Tobias Mann and senior reporter Tom Claburn, locally installed coding assistants have actually become so good they could relieve some of the compute load that's pushing AI companies to raise their prices. This week on The Kettle, host Brandon Vigliarolo is joined by Mann and Claburn to discuss their work with locally-hosted LLMs, why we're revisiting the topic at all, how to do local LLMs safely, and whether there's orbital relief coming for the compute crunch. You can listen to The Kettle at the link above, or here, stream it on Spotify or Apple Music, or read the full transcript of this episode below. ® --- Brandon (00:01) Welcome back to another episode of The Register's Kettle podcast. I'm Reg reporter Brandon Vigliarolo and with me this week are systems editor Tobias Mann and senior reporter Tom Claburn to talk about some experiments they've been doing with AI coding assistants, but not just any AI coding assistant mind you, we're talking about local ones that live right on your own machine. Guys, thanks for joining me this week. Tobias Mann (00:24) Good to be here. Thomas Claburn (00:25) Thank you. Brandon (00:29) So before we jump into what learned during these experiments and how effective local large language models actually are as coding assistants. Let's talk a bit about why we're having this discussion in the first place. And I understand that AI coding assistants are about to become way more expensive. And I think, Tom, these were stories that you wrote recently. So can you walk us through a bit what's going on with the current cloud-hosted ones? Thomas Claburn (00:52) Back in November, there was, I think around Opus 4.5, pretty much all the developers started to realize that these models were actually getting pretty good and there's no longer, vibe coding was less of a joke and more like, you know, maybe this will work. And then by the time, you know, around February with the OpenClaw craze, was a lot more demand for sort of coding agents and people would start running these for long periods of time. And it sort of caught Anthropic and others unaware, Google and open AI as well. There was a lot of capacity constraints, a lot more people were trying these things out and they ended up having to find ways to limit demand through session limits and made a lot of people unhappy but they basically just didn't have the compute available to serve capacity. And on top of that, they're serving a lot of these at a price that is loss-leading. They're trying to get people into the business, but these are unprofitable workloads for them. And if you look at something like Mythos, which came out, is their big security model, it was too good for anybody, but large companies with expensive payrolls to run. Brandon (02:08) Right, right. Thomas Claburn (02:10) It's clear that they're looking for ways to increase their revenue because they're investing a lot in the infrastructure to make this run, but they don't yet have the recurring revenue that justifies all this. The ramps look good. They're bringing more people on, but they invested a lot of money in this. Brandon (02:29) OpenAI famously has never actually turned a profit in its history. I don't know about Anthropic ⁓ personally, but I can't imagine they're doing a whole lot better. And so I understand the two specific examples you had was that Anthropic recently yanked Claude Code from Pro plans, but only for some people. Is that correct? Thomas Claburn (02:49) Yeah and they wrote that off as an A/B test. Basically they were doing live A/B testing and people noticed and they were saying, oh, well, no, that's doesn't apply to everyone. We're not going to change or take away from existing Pro users. But clearly there are someone there saying, hey, can we get away with charging this much but providing less service? And that doesn't happen unless you're trying to figure out a way to increase your revenue and reduce the demand on your services. Brandon (02:53) Okay. Totally. Did they backtrack on that at all or is that still, is that A/B test still going on? Thomas Claburn (03:23) I don't think it's still going. Tobias Mann (03:24) They do really do do a lot of A/B testing. I think I have a Claude Code Max subscription that is about, has a 50 % discount on it right now. So I'm a little hesitant to give it up because yeah, it's a hundred bucks a month and I don't use it nearly enough to justify that. But also if I cancel and decide I wanted it back, it'd be 200. Brandon (03:46) Yes, the reason I'm still an Nvidia GeForce Now gaming cloud subscriber, right? Because I was there in the beta test and I've never given that discount up, even if I haven't used it in a while. So I understand. Claude did that, Anthropic did that, and then GitHub also has just straight up jumped to metered billing for AI, think. Correct? Thomas Claburn (04:05) Yeah, and they were taking a huge loss on things because they would give you a flat rate, but then people would use the most expensive models. And of course, those things are billed at different rates and offering a flat rate versus these very inflated Opus 4.7 models, which also take a lot longer to process stuff, even if they're a little bit more efficient, they'll think for longer periods. It's just they're losing money. So everyone has to go to meter billing. And once that happens, it's going to cost people a lot of money. You can look at it now, even on a subscription plan, you'll write up a little widget and you look at the thing and it's, you know, $2 worth of whatever. You think, well, is that worth it? Maybe. And then if it's a more substantial project, you know, people spend, you know, hundreds of thousands of dollars on stuff. And if that's not returning you any revenue, are you still going to do that? So it's going to be interesting to see how this goes. Brandon (04:59) Maybe local LLMs like what we're here to talk about today are kind of the market control, right? I'm sure there are gonna be people who are using these paid services, or were at least, that are gonna say, I don't care what the justification is, whether they're trying to make more money, sure, they might deserve to, or whether they just need to reserve compute resources. Either way, I can't afford to pay for this, so I'm going local. Maybe that'll be the cost control, right? Maybe there'll be some balance that kind of equals out there between, we're losing customers, so we got to make this cheaper versus we need to actually get some return on our investment someday. But I guess either way, right, this discussion is kind of is indicative of why we're talking about using local LLMs. Specifically, I believe, coding assistants, which is what the two of you have been kind of spending some time working with. And I understand you've both had success in various ways with this. Let's talk a bit about I guess the one large story you wrote this week about local LLMs and just kind of more broadly what you guys think of them. Tobias Mann (06:05) Many of us on the team have been playing with local LLMs in some shape or fashion for a couple of years now. And probably within the last year, certainly in the last six months, the models that are small enough that you can run on consumer hardware – and I'm not talking cheap consumer hardware, I'm talking about high-end consumer GPUs, quasi-workstation mini PCs, higher-end MacBooks and Macs – the quality of those models have jumped from being kind of like toys, tech demonstrator,s to being really rather competent. At the same time, we've also seen the rise of these agentic coding frameworks. That's the other part of the equation. These are things like Claude Code . Claude Code is a framework thatconnects to models running in Anthropic's various data centers and cloud providers, and is what's actually orchestrating the generation of the code, the testing of the code, the validation of the code, and allowing developers to kind of use these as actually useful tools rather than just getting a code snippet that may or may not work out of a model as you might have done with ChatGPT four years ago. Right around the time that Microsoft was going to usage-based billing and Anthropic was toying around with kicking the $20 a month Pro users off of the Claude Code entirely to save on compute, Alibaba's Qwen team popped in with a relatively small 27 billion parameter LLM Brandon (08:05) Relatively small. I just think it's funny how quick the parameters have grown over the years. Tt's small. It's only a few billion, you know. Tobias Mann (08:08) Yeah,it's only 27 billion. You know, they popped in and they presented this as being frontier-quality coding out of a pretty small model. And so with all of the harnesses you need to do this and now a model that is supposedly competent, it was just kind of the perfect storm so to speak, to start looking into whether or not these small models could be a replacement for some part of the development flow, for the entire development flow. And it's surprising just how good these small models have gotten. Thomas Claburn (08:53) I was experimenting just recently with the Qwen 3.6 and it's like a, whatever, 35 billion parameters ... but it's like a mixture of experts, so it's actually only like 3 billion, I think, when it's running. And it's an 8-bit quantization. And it's actually, it's working pretty speedily. And I was doing a sort of comparison test to see whether it would do a drag-and-drop metadata removal app on a map, which is like a very particular kind of thing. And initially it kind of suggested some things that were wrong. And I sort of cross-checked that with Claude OpenAI and they both came up with things that were like not really right either and then when I sort of rephrased the question to it more carefully, they basically came up with the same answer with Claude. And what it tells me is to your point about the harnesses, I think a lot of the things that makes local coding work is how good the local harness is. And this was a point that came up yesterday in a piece I was working on about Mozilla when they were talking about all the bugs they fixed with Mythos. One of the people I was talking to, Davi Ottenheimer, argued pretty strongly that you can do Mythos-quality work with a much smaller model as long as you have a good harness. Unfortunately, a lot of the setup of that is very kind of...there's not a standard way to do it. So people will either figure out a way that makes it work or they'll set something up and it just doesn't work. But it's not really clear why that happens. And there's a lot of just sort of arcana about like what skills you have and what the pipeline looks like. People are still figuring it out. But I think that local is where it will go because there's nothing that beats the price of being able to run this for next to nothing excluding your very expensive hardware. Brandon (10:59) And it's improving to the point where it's not something that it would have like a while ago, was like, this doesn't really work. Now we're reaching the point where these local models are viable, right? Well, like you said, you've got to word things carefully. I mean, that feels like anything that was the early days of AI, right? It's like, OK, you got to word it carefully. But eventually, it's going to get better to the point where it's not going to have to be so particular. And you get the same results, hopefully. Tobias Mann (11:24) Yeah, there are two key technologies that I think have really helped these smaller models compete. The first is, as Tom mentioned, is mixture-of-expert models. They only use a subset of the total parameter count for each token generated, which reduces the barrier to entry for hardware. The larger the models get, the more memory bandwidth you need in a consumer or even workstation class of product. It gets absurdly expensive as your memory bandwidth requirements increase. Brandon (12:01) Even for doing some of the basic ones here, I think you wrote in your story that the things you need, you need an M5 Mac with 32 gigabytes of memory. Or 24 gigabytes with multiple GPUs. You need a beefy machine from a consumer perspective to run this stuff. I've got an M1 Mac I wonder if I could run some of these. My Mac's pretty fast. I haven't needed to think about upgrading it in several years. And I looked at them and there's no way. Tobias Mann (12:29) So older Macs can do it. You will run into issues where the prompt processing side of it, that's the, hit enter on your prompt and then you wait. It gets to be problematic. Like you're talking several minutes of waiting for it to start generating a response because older Macs lacked the matmul acceleration necessary for this. So they were brute-forcing a lot of the compute on the GPU. Starting with the M5 Max, they integrated the matmul acceleration into the GPU. It makes a huge, huge difference in terms of performance. That's why we recommended newer Macs. Tom and I, I think we're both testing on older M Series Macs. Yes, it can work and especially with the 35 billion parameter mixture-of-experts model, it's a little bit better, but the quality is generally worse than the dense 27 billion parameter model. Brandon (13:39) I guess I can understand that, right? mean, the more processing you can get done the faster, the better the response is. Tobias Mann (13:48) That's a really important part of this because the other piece, the thing that has changed that the models are that small models can be this competitive is something called test time scaling. We saw this first with DeepSeek and OpenAI o1, which is this, you you hit enter on your prompt and then you see the model thinking and the model can work through different paths and then choose which path it wants to present tto the user at the end. So you can, the idea behind test time scaling is that you can take a smaller model and have it think for longer in order to make up for the lack of parameters in that model. And so we have both of those things coming together in models like Qwen 3.6 27B or Qwen 3.6 35B. Brandon (14:30) Okay, cool. Now, I mean, for those who are interested in setting this up and go, okay, I've got some hardware that's beefy enough and I think I'm willing to give this a shot. This has also gotten a lot easier. I think in the past year, year and a half, two years, it's also gotten multiple factors of simplicity easier to actually set up one of these things and run them locally. Is that accurate to say? It seems like it's gotten a lot simpler to configure this. Thomas Claburn (15:10) People often use Ollama or Unsloth, I'm using OMLX, which uses the Mac MLX. And these are basically the model serving platforms. You can get your model from a variety of places. Hugging Face is a very common one. But a lot of the model platforms like Ollama will fetch the model for you and handle all the installation stuff. The trick is a lot of them have different formats. And if you're using Olamma CCP directly on your computer, which is the C-based model runner, it's going to have a different format than say something else. And they'll all talk to each other, but it tends to lock you into one particular way of doing it and you get used to it. There's not really a right way of doing it right now and that's part of the problem is everyone's kind of figuring out what's the right way to do this? Which one do I want to use, how do I configure it? Even just looking at the model and trying to decipher the quantization and the features it has, isn't always clear to everybody. That I think hopefully will become more standardized as you get sort of more common knowledge about, yeah, this one works really well for me. Throughout the forums every week there's someone saying, yeah, this model is great for XYZ and we'll try that out. I mean, that's really the experience you have to have is figure out what you're gonna use it for and try it and see what other people are doing. And you can probably arrive at something that's useful locally. Brandon (16:45) Useful locally, I guess, also implies the need to do some security legwork. Right. I know when we first started writing about local LLMs, things like OpenClaw right. I mean, the the going headline for any of those right was, this this local LLM has caused chaos for somebody again. Right. Is that I think, Tom, you wrote a couple of stories recently about running local LLMs safely. Has it gotten to the point where it's easier to do that safely or is that still going to be a big concern for anyone doing this? Thomas Claburn (17:17) It is easier to do. The setup can be pretty complicated for these anyway. I just spent an evening building a sandbox for the Py agent because Py is sort of a very permissive agent that comes out of the box in YOLO mode. It can sort of do anything. It has very limited command set, but it has very few limitations. And that's by design. It's sort of like in the same way Flask is a very open Python framework. It's not this sort of "batteries included" thing, know, compared to Django. Something like Claude will come with a bunch of sort of predefined ways to do things. Claude has its own sort of sandboxing system and you can add a lot of safety through things like hooks. You know, there people who will write hooks that will intercept dangerous commands like, you know, rm. So there's a lot of ways to do it. Docker has a sandboxing system. That's what I tried to build on is basically figure out a way to do a Docker sandbox that runs Py and it protects the local file system but leaves the internet space open and those are kind of the security decisions you have to make because if this thing is totally enclosed in a VM and there's no way out, it can't really do anything! I mean you can do anything that you stick in the VM, but if you wanted to work on a project on your own system, you have to break that boundary somehow to get the file across and give it access, and then if you need to update something you have to open it up to a code repo somewhere. So there are a lot of security decisions you have to make and for me biggest one was just like making sure it doesn't mess with my local files and that gives me little bit more confidence to run a model that I don't really know how well it will perform. Having my Claude for a long time I'm a little bit more confident that it behaved behaves well, but the risk is there for all of them. Tobias Mann (19:10) So we looked at, I think, three different agent harnesses in the piece. Claude Code, which you would think is for work with Anthropic's stuff, but it works just fine with local models. It's two additional commands and you're up and running. It's very heavy. The system prompt is enormous. And so if you have lesser hardware, you might struggle a little bit with it. We also looked at Cline, which is a VS code extension that is very easy to install, pretty fast to configure. And then we looked at PyCodingAgent, which Tom had suggested that we discuss as well. Out of the box, Cloud Code and Cline both default to user-in-the loop, deny-by-default kind of situations where it'll ask for permission before performing any commands or writing any code. It'll say, "I want to write this code. What do you think? Do you want to proceed?" But they can be made to go fully automatic and just say, you know, I'm not worried, YOLO, let's go. And so thatmodel is a different security model than what we saw with PyCodingAgent, which to Tom's point is just pure YOLO mode out of the box. And so the security models differ wildly depending on which agent harness you're using or which sandbox that you're trying to play in, so to speak. There are several kind of agent sandboxes that have emerged that default to blocking all outbound network activity, which really limits the capabilities of the agent and forces you to be deliberate about what you do and don't want it talking to. Others are just, you know, they're focused on isolating doing kind of limiting the blast radius if the agent decides to go AWOL and do rm, rf, you know, the root file structure and just take the whole thing out. That's fine if it's in the container and it destroys the container because you run two commands and you're back up and running again. It's less okay if you're running bare metal. Brandon (21:32) So security considerations, seems like the core is basically just know what you're working with, right? Like don't deploy an agent that you don't at least have some idea how the security apparatus built into it functions by default, right? And just what you can do with it. But I guess whether we think about security or not, a lot of the conversation around the need to run LLMs locally seems to boil down to compute resources and the cost to maintain them, the cost to operate them, the cost to serve them. And I guess, Anthropic, speaking of Claude, right? Anthropic's big longshot this week, I guess, was a plan or a partnership they signed with SpaceX to occupy some space on the fleet of orbital data centers that Elon Musk seems intent on building. Tom, so is that gonna happen? Thomas Claburn (22:27) [Laughs.] I don't know. I I would think that they would put them in the ocean before they would put them in space. And, you know, they talk about data centers, but I think that it's I'll wait and see if they actually build them on land first, because there's a lot of terrestrial construction that is planned and hasn't happened. And we'll see. Tobias Mann (22:49) Yeah, the whole idea is that in space, you put the satellites in a sun-synchronous orbit, then they have basically unlimited power. The problem is that you have to get them there in the first place, which you need a launch vehicle for, which, last I checked, Starship still does not work. Brandon (23:09) I was gonna say this seems awfully familiar to me if we just change orbital data centers to Mars colonization, right? Like same problem here. We gotta have a vehicle that can get us there yet and we do not. Thomas Claburn (23:21) The Hyperloop will be the way they'll take it out there. Brandon (23:24) Yeah, right. Tobias Mann (23:28) And once we get the orbital cluster in place, Elon wants to put a mass driver on the moon so that we can put even more of these things into deep space for reasons I guess. Brandon (23:42) It just seems like there's a lot of, I don't know, it feels like the idea that Anthropic is gonna get on board with these SpaceX data centers in orbit. It feels to me a lot like when a data center company is like, hey, we just signed a huge deal with this company that makes nuclear reactors that don't exist yet. And it's kind of like, cool guys, well, let us know when we've actually got a real solution for the compute crisis that you guys are dealing with right now that you caused. Thomas Claburn (24:05) I kind of interpret the whole space thing as like, we made a deal with SpaceX and we have to say something nice about their future plans. Brandon (24:18) Right. Yeah. Tobias Mann (24:19) This really boils down to Anthropic is getting access to Colossus One, this massive, what, 150-megawatt AI factory, purpose-built for GPU training and inference. And so I think really what they need is compute and they cannot get enough of it. The inflection point has hit and we're seeing adoption, which means we need compute for inference and we need more compute for inference than we've had in the past. And so I think really what this is, is we'll say whatever you want. We will say that we will ride along on your Starship into the heavens and live in your space data centers. Just give us access to Colossus, please, because we're dying for compute. Brandon (25:15) We need it now and it'd be great if it happened someday in orbit, right? So in the meantime, I guess, basically, have we reached the point where localized AI, local LLM coding agents, right? Are we at the point now where they might be able to ease some of the compute stress that these companies are feeling or is this still early days something that's going to have to be developed, not worth it for the average developer? Thomas Claburn (25:41) I think they're going to be useful for sort of prototyping stuff. One of the things I've done is, I'll run it through the local one and then I'll have Claude check it. You often get a lot of, you know, code fixes that way. So it is a way to offload some less important jobs. I mean, you don't need a frontier model for everything. Brandon (25:49) Right. Right. I think that was kind an argument you made to bias about, you know, using a massive data center to build an HTML page is not a good use of resources. Tobias Mann (26:09) Right, Using the biggest, baddest model to write some HTML is probably not the most efficient thing to do, and it's certainly well within the capabilities of these small models. The other thing I'll say is, if you look at how GPT-5 works, if you go to ChatGPT, not Codex, when you first enter a prompt, it gets routed to one of three models based on the complexity of that model. Conceivably, we could do the same thing with local models, where you sign into Codex, it does a check. If you have sufficient hardware, it will run some portion of that query through the local model, do a yes/no check on the big model in the cloud, and decide whether or not, at that point, whether or not it needs to be regenerated via the API, or it can move forward with what's generated locally. So there's definitely a path forward for local playing a bigger role in reducing the amount of compute required to scale it.... Brandon (27:25) I guess the only key caveat there would be that if you're gonna install local LLMs on people's machines to split your compute load, you should probably let them know first, right Google? Tobias Mann (27:38) You probably should. Brandon (27:43) Probably. Or you can just do it and ask for forgiveness later on. Who's gonna uninstall Chrome? You? Ha ha ha. Tobias Mann (27:49) Yeah, the other thing I would point out is that, while a 24- or 32-gigabyte GPU is very expensive, we're talking anywhere from $1,00 to, you know, $4,000 plus for GPUs with that memory, those GPUs could serve that model to an entire team, realistically. And so if you were thinking about this from an enterprise adoption standpoint, you could buy one machine that sits in the corner, basically silent, that could serve an entire dev team with this smaller model. Or you could spend a whole lot more, but still something that fits on a desktop in the corner that runs a big model, like a trillion-parameter model, locally on that system and for that team. We're not just limited to these small models. You and I might be, but from an enterprise standpoint, a $70,000 DGX Station, for example, is capable of running very large models, trillion-parameter scale models. And that's less than the cost of one developer for a year. Brandon (29:06) Yeah, so maybe that's the case now, right? Maybe we've just reached a point where there's enough value in these local models as a sort of prototyping testbed, as a entry level dev replacement to do the first work before someone more experienced or with more parameters reviews it. Yeah, so it might be there. That's interesting. I will be interested to see how the evolution of AI models and like you said, the kind of linking between cloud-based versus local. I'll be interested to see how that develops. It could be the next phase of the AI industry's evolution. We'll see. We'll see. Something's got to give with compute, right? No matter what it is, we are going to be sure we're here on The Register to write about it and here at the kettle to talk about it. And until then, we will see you next week on the next episode. ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5237509&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5237509&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5237580</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/05/09/google-tweaks-chrome-ai-privacy-wording-insists-processing-stays-on-device/5237580</link>
+<pubDate>Sat, 09 May 2026 19:57:11 +0200</pubDate>
+<title>Google tweaks Chrome AI privacy wording, insists processing stays on-device</title>
+<description>
+<![CDATA[ Deletion of a longstanding privacy assurance sparks concerns ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ aI + mL ]]>
+</lab:kicker>
+<dc:modified>Mon, 11 May 2026 10:47:12 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ Google has changed Chrome's disclosure language about how its on-device AI works, but that doesn't mean the company intends to capture on-device AI interactions. The Chrome menu modification, which isn't universally rolled out yet even in Chrome 148, was noted this week on Reddit. The "On-device AI" message in Chrome's System settings previously read, "To power features like scam detection, Chrome can use AI models that run directly on your device without sending your data to Google servers. When this is off, these features might not work." But the message changed recently – it lost the phrase "without sending your data to Google servers." That prompted privacy advocate Alexander Hanff to question whether the edit signaled an architectural change that would see local AI interactions processed by Google servers instead of remaining on-device. "Why was the sentence 'without sending your data to Google servers' removed from the on-device AI description in Chrome's Settings UI?" Hanff asked. "Was the previous text inaccurate? Has the architecture changed? Was the wording withdrawn on legal advice because Google was unwilling to defend it as a representation?" Asked about this, a Google spokesperson said, "This doesn’t reflect a change to how we handle on-device AI for Chrome. The data that is passed to the model is processed solely on device." It appears this situation deserves a more genteel rendering of Hanlon's Razor – "Never attribute to malice that which is adequately explained by stupidity." In this case, it's "Never attribute to malice that which is adequately explained by bad timing." Word of the menu modification surfaced as Chrome was rolling out the Prompt API, which is designed to provide web pages with a programmatic way to interact with a browser-resident AI model. The API's arrival and public discussion of it drew attention to the fact that Chrome has been silently downloading Google's 4GB Nano model onto users' devices. The coincidence of these events made it seem that Google was preparing to capture on-device prompts and responses, which would be a significant privacy retreat. In fact, Chrome has been letting Nano sleep on the couch for early adopters dating back two years when local AI was implemented in Chrome 126 as a preview program. While Google hasn't yet made model downloading and storage opt-in, the biz did earlier this year implement a way to deactivate and remove the space-hogging model. "We’ve offered Gemini Nano for Chrome since 2024 as a lightweight, on-device model," a Google spokesperson explained, pointing to relevant help documentation. "It powers important security capabilities like scam detection and developer APIs without sending your data to the cloud. While this requires some local space on the desktop to run, the model will automatically uninstall if the device is low on resources. In February, we began rolling out the ability for users to easily turn off and remove the model directly in Chrome settings. Once disabled, the model will no longer download or update." The edit to the "On-device AI" message occurred in early April. According to Google, Gemini Nano in Chrome processes all data on-device. But when websites interact with Gemini Nano in Chrome – via the Prompt API, for example – they can see the inputs and outputs of the model. In such cases, the data handling would fall under the privacy policy of the website interacting with the user's Nano instance. Google decided to change its "On-device AI" message to avoid confusion – and perhaps to preclude legal claims alleging policy violations – when the user is interacting with a Google site that calls out to the Nano model on-device, in support of some service it provides. In that scenario, the Google site would have access to the prompts it sends and responses it gets from the user's on-device model. That interaction would happen "without sending your data to Google servers," at least in the context of a user querying a model running in Google Cloud. But since the user's on-device Chrome-resident Nano model would send data to the Google site in response to that site's API calls, that data transmission might be interpreted as a violation of the local AI commitment language. Hence the edit. Google's decision to have Gemini Nano become a Chrome squatter is a novel way of doing things, given that co-opting people's computing resources has largely been the province of covert crypto-mining scripts. But perhaps after years of offering Gmail and Search at no monetary cost, Google feels entitled to a few gigabytes of Chrome users' local storage and occasional bursts of their on-device compute. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=1622689&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=1622689&width=800"/>
+</item>
+<item>
+<guid isPermaLink="true">https://www.theregister.com/a/5237498</guid>
+<link>https://www.theregister.com/ai-and-ml/2026/05/08/gpt-55-may-burn-fewer-tokens-but-it-always-burns-more-cash/5237498</link>
+<pubDate>Fri, 08 May 2026 23:08:52 +0200</pubDate>
+<title>GPT-5.5 may burn fewer tokens, but it always burns more cash</title>
+<description>
+<![CDATA[ It’s not just gas prices skyrocketing. Frontier-model pricing keeps climbing too ]]>
+</description>
+<category>ai and ml</category>
+<lab:kicker>
+<![CDATA[ AI + ML ]]>
+</lab:kicker>
+<dc:modified>Mon, 11 May 2026 02:10:39 +0000</dc:modified>
+<content:encoded>
+<![CDATA[ It's getting more expensive to use the latest models. OpenAI last month bumped the version number of its GPT model family to 5.5, and per-token prices rose too, in some cases doubling compared to its predecessor. For 1 million tokens, GPT-5.5 is priced at $5 (input), $0.50 (cached input), and $30 (output). Its predecessor GPT-5.4 charges $2.50 (input), $0.25 (cached input), and $15 (output) per 1 million tokens. The AI biz claims that the cost increase is offset to some extent by token processing efficiency – delivering better results using fewer tokens. "While GPT‑5.5 is priced higher than GPT‑5.4, it is both more intelligent and much more token efficient," the company said during the rollout. But the cost is still going up, more than efficiency improvements are reducing costs. According to an analysis conducted by OpenRouter, GPT-5.5 is anywhere from 50 percent more expensive to nearly twice as expensive, depending on prompt length. "Our analysis shows that GPT-5.5 actual costs increased 49 percent to 92 percent," OpenRouter said. "Longer prompts, over 10k tokens, saw costs offset by shorter completions. Shorter prompts, under 10k, experience a higher cost increase where completions did not get shorter." That range – 49 percent to 92 percent – factors in the model's token efficiency improvements, which are more relevant for longer prompts. According to OpenRouter's measurements, GPT-5.5 generates between 19 percent and 34 percent fewer completion tokens for longer prompts (10,000 tokens and up). If reports of OpenAI's projected $14 billion loss in 2026 prove accurate, costs will have to rise much more to balance its insistent spending. But this is a problem also faced by rival Anthropic, set to lose a reported $11 billion in 2026. Anthropic's Claude Opus 4.7 arrived without a visible list price change amid claims about an improved tokenizer. The result, according to OpenRouter, is potential savings for shorter prompts but larger bills for longer ones. "Our study of real Opus 4.7 usage shows that actual costs increased 12–27 percent for prompts above 2K tokens when cache absorption is taken into account," the biz said. "Short prompts under 2K were the exception, where significantly shorter completions offset the tokenizer overhead entirely." Expect further price increases for premium models. ® ]]>
+</content:encoded>
+<enclosure url="https://image.theregister.com/?imageId=5223736&width=800" type="image/jpeg"/>
+<media:thumbnail url="https://image.theregister.com/?imageId=5223736&width=800"/>
+</item>
+</channel>
+</rss>