ARC Prize 2026
Get started and receive official contest updates and news.
No spam. You can unsubscribe at any time.
10 interesting stories served every morning and every evening.
ARC Prize 2026
Get started and receive official contest updates and news.
No spam. You can unsubscribe at any time.
Oracle has banned AI-generated code from OpenJDK contributions, citing safety, security, and intellectual property risks. The open-source Java project steward said developers can use LLMs privately for debugging and reviewing code but cannot submit AI-generated material to repositories, pull requests, or other project channels.
The policy contrasts sharply with Oracle’s internal practices. Co-founder Larry Ellison recently declared that AI models now write Oracle’s code, whilst co-CEO Mike Sicilia credited AI tools with enabling smaller engineering teams to deliver faster.
Oracle is investing $70 billion this year in datacentre expansion. The spending spree prompted credit agency S&P to downgrade Oracle’s rating to BBB-, one notch above junk status, citing uncertain returns on investment.
Source: theregister.com
Assembly Hall of Shame
Overview
Instruction latency analysis usually focuses on performance optimization—making code run as fast as possible. The Assembly Hall of Shame takes the opposite approach: searching for the absolute floor of single-instruction performance.
🏆 Current Champions 🏆
x86: fxrstor64
Strategy: Use fxrstor64 to load 512-byte FPU/MMX/XMM state from a high-latency MMIO region in the PCIe fabric, then starve the fabric while the load is in flight — a fleet of hammer cores pounds a different high-latency MMIO register with tight 4-byte reads, saturating the PCIe root complex and endpoint with non-posted transactions, so CPU 0′s 512-byte fxrstor64 must queue behind all that contending traffic.
Contender: AMD Ryzen 7 5800H
; CPU 0 — timed instruction movl $0xfcc68830, %rsi fxrstor64 %rsi
; CPUs 1..N — hammer loop against a different high-latency location movl 0xfcc68858, %eax
🏆 Score: 198,002,498,236 cycles
🏆 Time: 62 seconds
Honorable Mentions
A spec-violating unaligned ymm0 load that forced non-posted dword transactions from stalled GPU registers was used to break the fundamental design of System Management Mode in smiiiiiiiiiiiiiiii.
vmovdqu 0xfcc003b1, %ymm0
Rules
Instructions may use whatever setup is necessary, but only a single instruction is eligible to be scored.
Trapped/emulated/virtualized instructions may only time the trap, not the handler.
Instructions must not be interruptible. rep movs, pause, etc. are disqualified.
Times are normalized based on the CPU base clock frequency.
All platforms must be in their factory stock configurations - no hardware modifications.
x86 Leaderboard
27. nop
Strategy: nop does nothing. It opens the leaderboard accordingly.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
nop
Score: 1 cycles
Time: 0 nanoseconds
26. nop16
Strategy: Regular nop was too short, but how do we make nothing take longer? Try a lonnnnnng nop.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
data16 data16 data16 data16 data16 data16 data16 nopl 0x00000000(%%eax,%%eax,1)
Score: 20 cycles
Time: 7 nanoseconds
25. rdtsc
Strategy: Just a reference instruction to get our bearings.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
rdtsc
Score: 49 cycles
Time: 18 nanoseconds
24. idiv
Strategy: Use 128-bit dividend (rdx:rax=2:0) with small divisor to push the quotient above the ceiling imposed by sign-extension, driving the longest path through the divider microcode.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
xorq %rax, %rax ; rax = 0 (low 64 bits of dividend) movq $2, %rdx ; rdx = 2 (high 64 bits: full dividend = 2^65) movq $5, %rbx ; divisor → quotient = 2^65/5 ≈ 7.4×10^18 idivq %rbx
Score: 77 cycles
Time: 28 nanoseconds
23. enter
Strategy: Use maximum nesting depth (31) to force 30 display-pointer loads and pushes through the microcode display-walk path.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
enter $0, $31 ; 0 bytes allocated, nesting depth 31 (maximum)
Score: 112 cycles
Time: 41 nanoseconds
22. fldl
Strategy: Try a small denormal to trigger an FP microcode assist.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
movabsq $0x0000000000000001, %rax movq %rax, -8(%rsp) fldl -8(%rsp)
Score: 133 cycles
Time: 49 nanoseconds
21. clflush
Strategy: Just ensure the cache line is dirty.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
clflush (%rax) ; rax -> dirty cache line resident in L3
Score: 165 cycles
Time: 60 nanoseconds
20. fsin
Strategy: Use exponent 0x7ff to reach ‘special value’ processing in microcode; positive/negative, NaN/inf doesn’t seem to make a difference, go with QNaN.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
movabsq $0x7fffffffffffffff, %rax movq %rax, -8(%rsp) fldl -8(%rsp) fsin
Score: 257 cycles
Time: 94 nanoseconds
19. mfence
Strategy: Saturate all write-combining line-fill buffers with movnti stores to distinct cache lines, forcing mfence to drain the full LFB write path to the uncore before retiring.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
movnti %r9, 0*64(%rdi) ; ×16 distinct cache lines — saturate the write-combining LFBs ; … movnti %r9, 15*64(%rdi) mfence ; must drain all pending LFB writes before retiring
Score: 326 cycles
Time: 120 nanoseconds
18. mov cr3
Strategy: Nothing for now, just check how long it takes to invalidate the TLB.
Contender: AMD Ryzen 7 5800H with Radeon Graphics (Trigkey S5)
mov %rax, %cr3
Score: 352 cycles
Time: 110 nanoseconds
17. fadd
Strategy: Hit x87 FP microcode assist path by using denormal source operand.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
fldl subnorm ; 1e-310: value < DBL_MIN, biased exponent = 0 faddl subnorm ; source is subnormal → FP microcode assist
Score: 677 cycles
Time: 249 nanoseconds
16. split lock
Strategy: Align lock-prefixed operand to straddle cache-line boundary, forcing CPU to assert the external bus lock rather than using the fast MESI cache-coherence path.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
; split_ptr % 64 == 63 — dword spans bytes 63 (line N) and 64 – 66 (line N+1) lock xaddl %r9d, (%rdi)
Score: 865 cycles
Time: 319 nanoseconds
15. fdiv -
Strategy: Use subnormal divisor, hardware hands control to microcode assist, assist normalizes operand, performs the division, then restores architectural state.
Contender: Intel(R) Core(TM) i7 – 8559U CPU @ 2.70GHz
movabsq $0x3ff0000000000000, %rax ; 1.0 (normal dividend) movq %rax, -8(%rsp) fldl -8(%rsp) ; ST(0) = 1.0
movabsq $0x0000002000000000, %rax ; 6.79e-313 (subnormal divisor) movq %rax, -8(%rsp) fdivl -8(%rsp) ; ST(0) = 1.0 / subnormal → FP assist
Score: 883 cycles
Time: 325 nanoseconds
The Nixpkgs core team has unfortunately decided to disband.
We’re proud to have had the opportunity to lead by example in bottom‐up, consensus‐focused governance for Nixpkgs, and of our achievements over the past 10 months, including reforming the committer delegation process and onboarding 19 new committers, empowering maintainers by extending the merge bot, re‐establishing contact with GitHub and securing the sponsored Enterprise Cloud upgrade, helping triage GHSA-67f2 – 674w-6g63 and track the GitHub security risks exposed by that incident, and establishing an initial automation/AI policy, as well as helping resolve many incidents that were escalated to us.
However, it has sadly not turned out to be the lightweight role compatible with active technical contribution that we had originally hoped it would be, and two weeks ago we reached the conclusion that stepping down is necessary for our health. We believe that it’s unsustainable for the team to continue, as demonstrated in part by our attrition to date. With only one person actively applying in response to our call for new members and mixed response to outreach, recruiting sufficiently to keep things healthy looks untenable. Therefore, especially with a Steering Committee election due imminently, we think the best way forward for Nixpkgs governance is to be honest about the circumstances that have made dissolving the team unavoidable, in the hopes that it may help future efforts.
Our experience is that the Steering Committee as an institution lacks a native instinct for the delegation envisioned by the constitution, while also not being sufficiently engaged and cohesive to handle individual decisions at those levels itself. This manifests as unnecessary micromanagement of teams below them and chronically poor communication, including lack of clarity from SC members about when they’re speaking for themselves or representing a joint position, matters brought to our attention with desired outcomes already attached, taking ownership of issues entirely within delegated areas without involving relevant teams, and insufficient and delayed responses to concerns. The end result has been inadequate coordination on matters like GSoC, grants initiatives, and AI policy, slow and difficult progress on matters relevant to Nixpkgs like moderation and GitHub org owner reform, and general uncertainty about whether we are trusted to autonomously make decisions within our remit.
These issues have persisted despite our repeated attempts to discuss them. This is, of course, a systemic problem rather than one any single SC member could solve; we don’t envy the demands of the role, have been impressed by the efforts of several members, and recognize that every individual naturally has limited time and energy and can only do so much in the context of a representative majoritarian committee. Ultimately, though, it leaves the SC not functioning effectively as either a representative backstop to delegation or a proactive decision‐making body. The resulting environment has acted as a consistent drag on our work, making it difficult for us to fulfil our constitutional mandate of “Project Direction, Decision-Making, Coordination with the NixOS Foundation Board, and Creation and Management of Teams, where they pertain to Nixpkgs”.
We believe our high‐trust consensus decision‐making model has resulted in high‐quality discussions and good results, and is a better fit for a delegated local governance team than the majority votes used at the top level by the SC. It’s not news to anybody that our community has many strong divides and disagreements, but nonetheless we’ve seen many situations where the ability to call on the core team for a resolution has helped calm tensions and led to agreeable outcomes. We consider the strong approval for the initial automation/AI policy from people with highly divergent views to be proof that it’s possible to find paths forward and make significant improvements even on seemingly intractable topics.
It inevitably takes its toll to step in under such circumstances, though. Given our own experiences and the history of the project, we understand why there is a general distrust of governance in the community, and how that has encouraged a combative, zero‐sum approach to disagreements. While those methods may work to effect change despite a leadership vacuum or to be heard by unresponsive governance, they contribute to burnout when leadership teams are trying to engage in good faith and foster productive discussion. That outcome only rewards those who don’t care to listen to the community or to pursue trust‐based consultative leadership at all, further reduces the small pool of experienced contributors with the time and desire to participate in governance, and risks locking in the historical status quo of decision‐making by deadlock and attrition.
We want to be clear that this decision is not the result of any one incident, but the culmination of long‐running patterns. The matters in our jurisdiction are left with no direct owner at present, with the SC acting as the final backstop as always. We both plan to reduce our Nixpkgs involvement and have no intention of running for SC. We still believe in the principles the team was founded on — that clear, lightweight processes for decision‐making and dispute resolution are critical to strengthening Nixpkgs and addressing the problems we’ve seen as contributors — and hope that a genuine delegation of engaged, technically‐focused, collaborative Nixpkgs leadership by top‐level governance will be possible in the future.
We’d like to thank everyone who has supported our work, and regret that the team hasn’t been in a position to solve these issues more comprehensively and sustainably.
On behalf of the Nixpkgs core team:
@alyssais
@emilazy
I use Strava for the obvious stuff, like runs, HIIT classes, and the occasional commute that goes full workout when I’m desperate to get my steps in. I’m not a pet owner, but I can understand a dog walk making it on there, too. The dog may be involved, but at least you’re still the one doing the walking.
But workouts uploaded from a hamster wheel? That feels like new territory.
Thijs de Buck, an MRI physicist based in Utrecht, the Netherlands, recently posted on Reddit that he built a speed and distance tracker for his hamster’s wheel, with the data automatically uploaded to Mollie’s own Strava account. Mollie, his 10-month-old hamster, is now committed to logging nightly runs with distance, pace, and time.
One recent activity showed 6.06 miles in 4 hours and 37 minutes. The next night, Mollie logged 5.55 miles in 3 hours and 56 minutes.
At first, de Buck just wanted to know how much distance Mollie was covering after dark.
“I bought a very cheap bicycle computer pretty much right away,” he told Runner’s World.
That worked at first, because the bike computer also used a magnet and sensor. But there was one very hamster-specific problem to deal with, as the sensor would shift into standby mode once Mollie stopped running for more than five minutes.
“So if Mollie would take a lunch break at 1 a.m., we’d have no idea how far he’d have run after that,” de Buck said.
The bike computer also only gave him total distance, and that just wasn’t going to cut it. De Buck wanted the full Strava treatment because apparently even hamsters deserve splits, uploads, and post-run analysis.
The build itself is clever, but the basic idea is simple. As de Buck explains it, a magnet on the wheel passes a hall sensor, which detects each rotation. An ESP32—basically a tiny programmable computer—keeps track of the data overnight. In the morning, he says a script on his laptop collects the information, turns it into a Strava-compatible .FIT file, and uploads the activity through the Strava API.
“All that remains is for me to manually add a photo of Mollie, and for Mollie to do the actual hard work during the night,” de Buck said.
De Buck could have stopped once the runs were uploading, but a hamster Strava account needed all the extra features. There’s a tiny organic light-emitting diode (OLED) display to show Mollie’s live speed, a code that helps for automated personal-best tracking, and more than 100 possible run titles, including “The Fast and the Furriest” and “No Rest for the Whiskered,” naturally.
The one thing he didn’t plan for was that auto-uploading the files this way required a paid account.
“There was really only one reasonable solution: my hamster now has Strava Premium,” de Buck said.
A hamster with this much performance data was always going to find an audience. De Buck said the account picked up thousands of likes, more than 1,200 kudos, and more than 600 followers within a week. He also signed Mollie up for Strava’s August 400-minute challenge, and Mollie completed it on Day 2—a wake-up call for anyone still ignoring their own monthly challenges.
Mollie has been with de Buck since Christmas, and his life outside training sounds, quite frankly, pretty focused. De Buck described it as “eat-sleep-run-repeat,” with Mollie spending much of the day hidden underground before waking up and alternating between food and wheel time.
De Buck and Mollie during a recent training session.
And the little guy’s not exactly phoning it in. De Buck said Mollie is averaging almost 10 kilometers per night, with a current record of 10.8 kilometers after the first week of tracking.
“I really believe he’ll be able to exceed that soon,” he said.
Mollie also has a weirdly consistent schedule for a hamster. Over one seven-day stretch, he started within the same 10-minute window on five nights, between 9:54 and 10:04 p.m. He tends to run in short bursts, sometimes reaching about 4 to 5 kilometers per hour on the live monitor, then hops off for water.
“Even elite athletes need to stay hydrated,” de Buck joked.
De Buck is a runner himself, which helps explain why the project ended up with this level of data. He said he loves “tracking every possible stat” during marathon training, so wanting more information about Mollie’s nightly mileage felt natural. He is also dealing with a minor injury at the moment, which gave him more time to work on the setup.
“When I get back, I think it’ll be a nice challenge to try to match Mollie’s weekly running distance,” he said. “I don’t normally hit 70km a week!”
The next milestone is Mollie’s 20th run, when Strava should start giving race predictions.
“I can’t wait to see his estimated 5K and marathon times,” de Buck said, “and whether he’ll manage to improve those predictions over time! Although I’m a bit worried he’ll have a better marathon time than me.”
Sean Abrams was the Senior Editor, Growth and Engagement at Men’s Health. He’s a former hip hop dancer who likes long walks on the beach and large glasses of tequila. You can find his previous work at Maxim, Elite Daily, and AskMen.
Terry Godier, “Browsers Have Standards, the App Store Has Judgment”:
A while ago I tried to submit an iOS app for Dark Hours, my astronomy website for normal people. It was rejected on the grounds that it was astrology.
It has no tarot function, no horoscopes, and nothing that I, or anyone else I’ve asked, would associate with astrology.
A while ago I tried to submit an iOS app for Dark Hours, my astronomy website for normal people. It was rejected on the grounds that it was astrology.
It has no tarot function, no horoscopes, and nothing that I, or anyone else I’ve asked, would associate with astrology.
I penned a nice little rant two years ago expressing my fury over the way that kooks promoting astrology often try to insinuate that their voodoo pseudoscience is even vaguely related to the hard science of astronomy. And it really is an unfortunate fluke of the English language that two subjects with a contentious relationship are differentiated as words by two letters. Even if you know the difference between the two, and care, if you’re reading quickly your eyes might conflate one word with the other.
But if you actually look at Godier’s Dark Hours, for even just a few seconds, it is instantly obvious that it pertains to the science of astronomy and has absolutely nothing — zero, zilch, nada — to do with astrology. So even if Apple’s App Store reviewer misread the submission’s description, and wrongly assumed it was yet another quack astrology app, if they launched it and spent just a few seconds poking around, they should have instantly recognized their incorrect assumption. But that’s not what happened. They rejected the app on the utterly incorrect grounds that it pertained to astrology. If this was an honest mistake from a reasonable judicial board, you’d expect the interaction with Godier, the developer, to have gone something like this:
App Review: REJECTED: Astrology. Developer: No, it’s astroNoMy not astroLoGy. App Review: Oh, sorry! Carry on, APPROVED.
But that’s not what happened at all. Godier proceeded through a series of escalations up to the App Review Board and the Review Board responded that they determined the original rejection was valid because, I shit you not, “We understand that the app includes a live tarot reading feature.” Which isn’t even about astrology. It’s straight out of Kafka.
Dark Hours is not just merely unrelated to astrology (let alone tarot-card reading). It’s actually exquisitely well-designed and painstakingly crafted. It’s exactly the sort of app that the App Store ought to celebrate and highlight. It doesn’t just belong in the category of astronomy apps in the App Store, it will raise the quality bar for astronomy apps in the App Store. iOS-exclusive, native Liquid Glass UI, smooth scrolling, beautiful typography and layout, and way more useful as a native mobile app than as a website. Go check out the website and I’m sure you’ll agree that it’s the sort of thing that would be even cooler as an app. But it is an app, and the app is better and more useful than the website version, and Godier has fought to get it approved. But Apple’s App Review Board said no, on fallacious easily-refuted grounds. This isn’t just contrary to the benefit of developers, like Godier. It’s obviously contrary to the benefit of Apple itself, which should not just accept an app like Dark Hours, but celebrate it as an exemplar of the platform.
Mistakes happen. But in a functioning system mistakes get corrected, and mistakes as obvious as this one get corrected almost instantly and include a quick apology for the conflation. The App Store is not a functioning system.
NASA just made an interstellar tweak to the Voyager 2 spacecraft, known as the “Big Bang”, to keep its remaining 50-year-old science instruments running a little longer.
Voyager 2 and its twin launched in 1977, called Voyager 1, rely on a form of nuclear battery known as a radioisotope thermoelectric generator that uses the heat produced by the decay of plutonium. But the supply of plutonium on each probe drops at about four watts a year on each spacecraft.
To keep the probe running on this dwindling power supply, engineers recently reduced Voyager 2′s power requirements by turning off a few non-science devices and using “lower-power alternatives” that are still effective enough to keep the spacecraft warm while it’s so far from the sun, NASA officials said in a statement. “The spacecraft power margins have grown razor thin, requiring the team to conserve energy by shutting off non-essential devices and systems,” NASA officials wrote of the mission, which is managed by the agency’s Jet Propulsion Laboratory.
The drop in power is having a measurable science impact on both spacecraft — each has turned off two of their science instruments since 2024 alone. While some of these instruments were shut off after the spacecraft finished their historic planetary flybys decades ago, others were turned off due to power requirements.
Each spacecraft initially launched with 10 instruments, and Voyager 2 is now down to only three instruments. At first it looked as though Voyager 2 would have to shut down another of these instruments later this year, but luckily, the new power shifts will allow all three to operate “for at least another year,” NASA said.
Voyager 1 will be tasked to do the same “Big Bang” power change “in the coming months.” A signal to each spacecraft takes nearly 24 hours (or one light-day) to make a one-way journey, and officials noted Voyager 1 is further from Earth than its twin. (Voyager 2 is at about 142 astronomical units or sun-Earth distances, while Voyager 1 is nearing 171 AU.)
The two spacecraft initially launched to take advantage of a rare alignment between the outer solar system gas giant planets, which in order of distance from the sun are Jupiter, Saturn, Uranus and Neptune. Each Voyager spacecraft first flew past Jupiter and Saturn, taking unprecedented imagery of the planets and their moons.
Next, Voyager 1 was directed to fly above the plane of the solar system (also known as the ecliptic) while Voyager 2 continued flying past Uranus and Neptune, becoming the first spacecraft to see these worlds and their moons. Voyager 2′s last planetary flyby was in 1989.
The two spacecraft continue to send scientific data from interstellar space; Voyager 1 passed into that region in 2012, while Voyager 2 did so in 2018. Voyager 1 is Earth’s most distant spacecraft, currently around 15.9 billion miles (25.5 billion kilometers) away from us, according to NASA.
Elizabeth Howell (she/her), Ph.D., was a staff writer in the spaceflight channel between 2022 and 2024 specializing in Canadian space news. She was contributing writer for Space.com for 10 years from 2012 to 2024. Elizabeth’s reporting includes multiple exclusives with the White House, leading world coverage about a lost-and-found space tomato on the International Space Station, witnessing five human spaceflight launches on two continents, flying parabolic, working inside a spacesuit, and participating in a simulated Mars mission. Her latest book, “Why Am I Taller?” (ECW Press, 2022) is co-written with astronaut Dave Williams.
AI coding tools deliver immense value: at Databricks, agentic coding has measurably improved every velocity metric we track and, in some teams, driven an order-of-magnitude gains in output. But nearly every company deploying AI tools at scale has hit the same wall: exponentially growing costs. That curve is unsustainable - left unchecked it will eventually overtake revenue. The spend explosion has left enterprises in a paradoxical situation: on the one hand, desiring to maximally push AI transformation and put powerful tools in the hands of employees, and on the other hand, having to reconcile with an aggregate cost profile that threatens to undermine or even reverse the very efficiency gains AI provides.
Fortunately, several of the earliest large-scale adopters have converged on a set of approaches that solve this puzzle, achieving a “dual mandate”: (a) providing broad access to AI tooling, with minimal friction, and (b) keeping aggregate costs inside of a roughly fixed envelope per user. This post outlines proven cost management techniques, based on our experience at Databricks and conversations with several other digital-native companies, including Stripe, Coinbase, Uber, and Ramp. The table below summarizes current techniques and associated savings; the numbers are directional, based on an informal survey of development teams:
Some of these techniques can be easily implemented with software many companies already use. Others require new infrastructure, particularly techniques that modify end-user clients or shift traffic across models. At Databricks, we’ve open sourced or made freely available our key infrastructure components: an end user meta-harness (Omnigent) and our AI Gateway (Unity AI Gateway). For completeness, this post also covers software used by other companies we spoke with.
The “Efficiency Frontier” for Coding Models
The single greatest cost lever in moving coding spend to more efficient models as they are released. This point bears some discussion, as the simple explanation of “cheaper models” in fact hides a nuanced relationship between model cost and quality.
Colloquially, the term frontier model means “the highest intelligence model,” and frontier labs largely focus on advancing peak intelligence. Frontier models can now solve novel problems in math or cybersecurity. But when AI is deployed at scale, a different type of frontier matters more: the efficiency frontier. The efficiency frontier is defined by the set of models that have the best price point for a given level of intelligence. Most day-to-day coding doesn’t require mathematical proofs or novel security insights, so what matters in aggregate is the cost of models that meet the quality bar for typical software engineering work. This “efficiency frontier” is advancing far faster than the intelligence frontier, with new models being released almost weekly that present better intelligence-per-unit-price than prior models.
Cost Lever #1: Moving to open source and lower cost models
Rapidly adopting newer, more efficient models delivers the largest cost wins of any technique. But to capture those gains, a company first needs to know which models actually beat its incumbents. This can be difficult because public benchmarks do a poor job of indicating real-world performance on coding tasks. To size up new models, many companies have built automated evaluations that they believe are more representative of their internal development mix. Databricks recently published an example of such a benchmark, in which we observed highly competitive price/performance for GLM models. That benchmark led us to roll GLM out to developers internally. Often, new models do not advance the efficiency frontier,and evaluations frequently produce negative results: Stripe found that Opus 4.7 did not meaningfully improve quality over Opus 4.6, while increasing cost. They therefore declined to make Opus 4.7 available internally. Databricks saw similar cost regressions when comparing Opus 5.0 to 4.8.
Harness and Model Flexibility
Since the biggest wins come from switching to new models, adopting end user tooling that allows for model flexibility is becoming a critical component of keeping costs down. The tool most commonly used in concern with a particular model is called harness. Proprietary frontier models are increasingly co-designed to work well with specific harnesses, meaning certain harnesses “work better” with certain models. If a company wants to preserve model independence there are roughly two approaches:
Ask users to switch harnesses. One approach is to provide developers with a set of harnesses (Claude Code, Codex, or Cursor) and then ask them to switch between harnesses when a company wants to migrate spend to lower cost models. This lets users work in their preferred harness when possible, but the downside of this approach is that switching costs for an individual developer can be high. If switching costs become too high, the harness itself becomes a de facto lock-in to a model family, limiting the ability to move spend to more competitive models.
Use a meta-harness. A new and increasingly popular approach is to use a meta-harness that surfaces a common user experience to developers while dispatching requests to underlying harnesses (both proprietary and open source). This approach allows both model/harness independence while also reducing developer switching costs. At Databricks, this is the default mode for developers who leverage Omnigent. Some companies we talked to have built custom internal meta-harnesses that integrate with their development toolchain.
Cost Lever #2: Dynamic Request and Task Routing
Instead of asking users to choose task-appropriate models themselves, a growing body of research suggests that automatic model and tool selection may further squeeze efficiency out of agentic coding workflows. Routing approaches roughly fall into three categories:
Request Level Routing: A stateful proxy sits in between a client (such as a coding harness) and the underlying foundation models. The proxy attempts to route requests to the lowest-cost model capable of answering each inference request. Routing for agentic use cases also needs to account for server-side caching, since a cold cache hit has a very high cost for large context workloads. A new wave of products is showing early, promising results for routing. Examples are: Cursor Router, OpenRouter’s AutoRouter, Ramps Router feature and Databricks own Smart Routing feature in Unity AI Gateway.
Task Level Routing (Meta Harness): A client-side process dispatches user tasks to different harnesses based on the complexity of the task. A user task might be “rename this component from X to Y” (a simple task) or an open-ended task like “Explore design considerations that would reduce latency” (a complex task). The dispatcher, often called a Meta Harness, examines which level of underlying model is required for a task and then delegates that entire end-to-end task to the model. Omnigent is an example of a Meta Harness that supports this pattern.
Escalation/Delegation Patterns: A single harness pairs two models (an expensive, high-intelligence model and a cheap worker model). In some approaches, such as Claude’s Advisor Tool, the cheaper model runs the show and escalates when it thinks a task requires more horsepower. The inverse pattern also exists: In Cognition’s Devin Fusion, the higher cost model is the main loop, and it selectively outsources work to a cheaper model.Internal results at Databricks suggest that our AI Gateway Smart Router is able to consistently reduce average task cost by more than 30%, while roughly matching the quality of the most expensive model in the working set. Other companies we spoke with have seen similar results.
Cost Lever #3: Giving developers visibility, tripwires, and budgets
It may be surprising that this entire article did not start and end with “Give users a monthly budget and be done with it.” Hard budgets, where usage is entirely cut off at a specific spend threshold, are often used only as a last resort option in every company we spoke with. There are two reasons that hard token budgets are not particularly effective for AI spend management: First, if a developer hits their budget ceiling, cutting off further access to AI tools would be debilitating to productivity. Neither the company or employee actually wants that outcome. Second, at least some of the “high spending” users are in fact those who have achieved monumental efficiency gains with AI and are producing immense output. Discouraging those users is self-defeating.
Instead of a hard user spending cap, most companies are adopting a more nuanced and progressive approach that focuses on visibility for end users and increased degrees of friction as spend increases.
Visibility: Every company we spoke with had a mechanism to provide near-instantaneous feedback to users on their ongoing spend, with many also offering specific tips or insights on how to reduce spend by using less expensive models. It is important that users be able to see their spend across all tools, since they may want to influence their choice of tool where they get the highest ROI.A developer dashboard at Databricks showing active spend
Visibility: Every company we spoke with had a mechanism to provide near-instantaneous feedback to users on their ongoing spend, with many also offering specific tips or insights on how to reduce spend by using less expensive models. It is important that users be able to see their spend across all tools, since they may want to influence their choice of tool where they get the highest ROI.
A developer dashboard at Databricks showing active spend
Spend Gates: Developers can be asked to take actions or seek approvals at increasing levels of spend. The simplest form of spend gate is one that can be self-cleared and serves as a warning that the spend rate is increasing above some threshold. At Databricks, we’ve found self-clearing gates a useful mechanism for preventing accidental or unintentional spend. Further gates can be introduced that require explicit budget approval (often through a management chain).
Downshifting: If a developer has hit a spend gate, they can be downshifted to a lower-cost model rather than being entirely suspended from token access. Since the lowest-cost models are drastically less expensive than frontier-intelligence models, this technique allows developers to continue getting work done without incurring massive ongoing spend.
Suspension: In the limit case, most systems do retain the ability to fully suspend users from all token access. As stated above, this is often a temporary measure only and the starting point for a conversation about how to efficiently leverage AI.
Cost Lever #4: Reducing Token Overhead
When a user types a relatively simple request into an AI coding agent (such as “Please investigate and fix this bug.”), that agent subsequently gathers massive amounts of relevant context, invokes a large number of tools, searches through the codebase, and integrates skills or system information provided by the company. By the time costly LLM inference occurs, the user’s initial statement accounts for only a negligible fraction of the data fed into the AI system, meaning costs are dominated by context the user did not explicitly include. Techniques in reducing context bloat are still new, but several promising approaches are being explored, such as:
Coercing more frequent compaction (compression) of the active context.
Using harnesses that are “less chatty” (more token efficient), or tuning existing harnesses to generate less token overhead.
Auditing popular tools and decreasing their verbosity.
Encouraging developers to break tasks into smaller individual units of work, decreasing context scope.
When contexts get large, prompt caching also plays a meaningful role in overall performance. Both proprietary and open source LLMs have settings that allow you to enable prompt caching and tune how long the cache is stored. Cache writes cost money, but cached reads can drastically reduce per-inference cost. This trade-off is dependent on a company’s specific workload, so hand-tuning of default cache settings to increase overall cache hit rate can have drastic improvements to overall cost.
At Databricks, relatively simple tuning of our harness and caching settings led to an almost 50% reduction in the number of generated tokens and associated costs, with no observed quality degradation for developers. We continue to explore techniques in this area and think meaningful additional optimization remains possible.
A drastic reduction in tokens per session by eliminating extraneous inference calls and reducing cache writes.
The AI Gateway design pattern
The techniques above had many implicit technical requirements: To rapidly take advantage of new models, companies must have a central location where the “model menu” is managed, and end-users must have a toolchain that supports model mixing. To provide budget visibility across multiple AI tools, a unified cost observability capability must exist. To manage context bloat, companies need a way to observe typical toolcall outputs and enforce compression or compaction. These needs are collectively being solved by a new class of infrastructure software, best described as an AI Gateway. An AI gateway is a central location where all of the following occur:
Capacity management and proxying of access to underlying models (both proprietary and OSS models).
Budget tracking and enforcement, including complex budget policies such as progressive friction levels and model downshifting.
Configuration management for end-user tools, to enforce model allow-lists, compaction settings, and other locally mediated aspects.
Logging of coding session traces for downstream efficiency analysis and benchmark.
At Databricks, we rely heavily on Unity AI Gateway for all of these capabilities.
Putting it all together
The exponential growth of AI coding costs is not an inevitability, it’s a solvable engineering and governance problem. Companies that have tamed it share a common playbook: relentlessly chase the efficiency frontier rather than the intelligence frontier, adopt tooling that preserves model flexibility, route work intelligently to the cheapest capable model, replace hard budgets with visibility and progressive friction, and cut the token overhead that dominates real-world spend. None of these techniques requires sacrificing the productivity gains that made AI adoption worthwhile in the first place; together, they let organizations satisfy the dual mandate of broad, low-friction access within a predictable cost envelope.
A set of new infrastructure abstractions is emerging to give companies the tools to manage their costs. At Databricks, we’ve released the key components in our cost management stack as open source or free software products: Our Unity AI Gateway for central management and Omnigent for developer tooling. Thousands of companies use these components every day. We invite more companies to share findings and compare techniques as this technology landscape rapidly evolves.
Acknowledgements: Thank you to infrastructure leaders at Uber, Stripe, Coinbase, and Ramp who provided commentary and reviews of this article. Thank you to Thrive Capital for feedback on an early draft of this article.
project:rosenbridge
: hardware backdoors in x86 CPUs
github.com/xoreaxeaxeax/rosenbridge // domas // @xoreaxeaxeax
Overview
project:rosenbridge reveals a hardware backdoor in some desktop, laptop, and embedded x86 processors.
The backdoor allows ring 3 (userland) code to circumvent processor protections to freely read and write ring 0 (kernel) data. While the backdoor is typically disabled (requiring ring 0 execution to enable it), we have found that it is enabled by default on some systems.
This repository contains utilities to check if your processor is affected, close the backdoor if it is present, and the research and tools used to discover and analyze the backdoor.
The Backdoor
The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU. It is enabled by a model-specific-register control bit, and then toggled with a launch-instruction. The embedded core is then fed commands, wrapped in a specially formatted x86 instruction. The core executes these commands (which we call the ‘deeply embedded instruction set’), bypassing all memory protections and privilege checks.
While the backdoor should require kernel level access to activate, it has been observed to be enabled by default on some systems, allowing any unprivileged code to modify the kernel.
The rosenbridge backdoor is entirely distinct from other publicly known coprocessors on x86 CPUs, such as the Management Engine or Platform Security Processor; it is more deeply embedded than any known coprocessor, having access to not only all of the CPU’s memory, but its register file and execution pipeline as well.
Affected Systems
It is thought that only VIA C3 CPUs are affected by this issue. The C-series processors are marketed towards industrial automation, point-of-sale, ATM, and healthcare hardware, as well as a variety of consumer desktop and laptop computers.
Looking Forward
The scope of this vulnerability is limited; generations of CPUs after the C3 no longer contain this feature.
This work is released as a case study and thought experiment, illustrating how backdoors might arise in increasingly complex processors, and how researchers and end-users might identify such features. The tools and research offered here provide the starting point for ever-deeper processor vulnerability research.
Checking your CPU
To check if your CPU is affected:
git clone https://github.com/xoreaxeaxeax/rosenbridge cd rosenbridge/util make sudo modprobe msr sudo ./bin/check
The provided utility must be run on baremetal (not in a virtual-machine), and is in an alpha state. It may crash, panic, or hang systems not containing the backdoor.
The utilities provided here are designed around a specific processor family and core; unfortunately, the tools will miss the backdoor if it has been even slightly modified from the researched form.
Closing the Backdoor
Some systems have the backdoor enabled by default, allowing unprivileged code to gain kernel level access without permission. If the steps in ‘Checking your CPU’ indicate that your CPU is vulnerable, you can install a script to close the backdoor early in the boot process:
cd fix make sudo make install reboot
Note that, even with this, an attacker with kernel level access can still re-enable the backdoor. This script is provided as an outline for correcting the issue during the boot process, but will require adaptation for different systems.
Tools and Techniques
The sandsifter utility is used extensively in this research for uncovering unknown instructions.
asm An assembler for the Deeply Embedded Instruction Set (DEIS). It converts programs written in the custom rosenbridge assembly into x86 instructions, which, when executed following the launch-instruction, will send the commands to the hidden CPU core.
asm
An assembler for the Deeply Embedded Instruction Set (DEIS). It converts programs written in the custom rosenbridge assembly into x86 instructions, which, when executed following the launch-instruction, will send the commands to the hidden CPU core.
esc A proof-of-concept of using the rosenbridge backdoor for privilege escalation.
esc
A proof-of-concept of using the rosenbridge backdoor for privilege escalation.
fix A rough outline for closing the vulnerability on affected systems, to the extent possible through model-specific-register updates.
fix
A rough outline for closing the vulnerability on affected systems, to the extent possible through model-specific-register updates.
fuzz A collection of utilities used to fuzz both the x86 and rosenbridge cores, in order to isolate the unknown launch-instruction and bridge-instruction, and resolve the instruction format of the rosenbridge core.
deis The fuzzer used to explore the effects and capabilities of the hidden CPU core.
exit It is thought that, on some processors, an exit sequence is needed to switch back to the x86 core at the end of a DEIS sequence. This directory contains the utilities used to search for the exit sequence in early stages of the research, but was abandoned when a processor was found not requiring any such sequence.
manager A collection of python utilities designed to monitor and manage fuzzing tasks distributed across a network of workers.
wrap A stripped down version of the sandsifter fuzzer, used to identify the bridge-instruction that will send commands from the x86 core to the hidden rosenbridge core.
fuzz
A collection of utilities used to fuzz both the x86 and rosenbridge cores, in order to isolate the unknown launch-instruction and bridge-instruction, and resolve the instruction format of the rosenbridge core.
deis The fuzzer used to explore the effects and capabilities of the hidden CPU core.
deis
The fuzzer used to explore the effects and capabilities of the hidden CPU core.
exit It is thought that, on some processors, an exit sequence is needed to switch back to the x86 core at the end of a DEIS sequence. This directory contains the utilities used to search for the exit sequence in early stages of the research, but was abandoned when a processor was found not requiring any such sequence.
exit
It is thought that, on some processors, an exit sequence is needed to switch back to the x86 core at the end of a DEIS sequence. This directory contains the utilities used to search for the exit sequence in early stages of the research, but was abandoned when a processor was found not requiring any such sequence.
manager A collection of python utilities designed to monitor and manage fuzzing tasks distributed across a network of workers.
manager
A collection of python utilities designed to monitor and manage fuzzing tasks distributed across a network of workers.
wrap A stripped down version of the sandsifter fuzzer, used to identify the bridge-instruction that will send commands from the x86 core to the hidden rosenbridge core.
wrap
A stripped down version of the sandsifter fuzzer, used to identify the bridge-instruction that will send commands from the x86 core to the hidden rosenbridge core.
kern A collection of helper utilities used to monitor kernel memory and registers for changes caused by fuzzed DEIS instructions.
kern
A collection of helper utilities used to monitor kernel memory and registers for changes caused by fuzzed DEIS instructions.
lock Utilities to lock or unlock the rosenbridge backdoor.
lock
Utilities to lock or unlock the rosenbridge backdoor.
proc A tool to identify patterns from the fuzzing logs to identify classes of DEIS instruction behaviors.
proc
A tool to identify patterns from the fuzzing logs to identify classes of DEIS instruction behaviors.
test A tool used early in the research, to attempt to identify the hidden core’s architecture by executing known RISC instructions.
test
A tool used early in the research, to attempt to identify the hidden core’s architecture by executing known RISC instructions.
util An alpha-state tool to detect whether or not a processor is affected by rosenbridge.
util
An alpha-state tool to detect whether or not a processor is affected by rosenbridge.
References
(TODO: link to whitepaper)
(TODO: link to slides)
Disclaimer
The details and implications presented in this work are the authors’ inferences and opinions, derived from the research described. The research is performed and provided with the goal of identifying and fixing a perceived security vulnerability on the described CPUs. VIA processors are renowned for their low power usage and excellence in embedded designs; we believe that the functionality described was created in good faith as a useful feature for the embedded market, and was unintentionally left enabled on some early generations of the processor. No malicious intent is implied.
Author
project:rosenbridge is a research effort from Christopher Domas (@xoreaxeaxeax).
To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".
10HN is also available as an iOS App
If you visit 10HN only rarely, check out the the best articles from the past week.
Visit pancik.com for more.