Tech

V2X Technology Gets a 5G Cellphone Network Solution

Published

9 hours ago

August 7, 2026

The history of networking is full of tools that repurposed solutions to very different kinds of problems first. Wi-Fi’s origins trace back in part to a team of Australian radio astronomers trying to detect signals from evaporating black holes. But the data processing tools they’d developed also proved capable at extracting clean messages from any chaotic, echoing signal environment. Echoes are echoes, after all, whether from distant star systems or from the far corner of the house.

I research vehicle communications networks, connecting cars to cars and to transportation infrastructure like traffic lights—for tomorrow’s vehicle-to-everthing (V2X) networks.

V2X research has long relied on models that assume “perfect” or “ideal” network conditions. Which is a simplifying assumption that makes the math tractable. But this assumption doesn’t reflect how real wireless signals behave in a moving, obstructed, high-density environment. That gap is exactly the kind of real-world unpredictability that open radio access networks (a.k.a. O-RAN)—an open, programmable architecture behind some 4G and 5G cellular networks—were built to manage.

So why has the O-RAN standard—which is open and available to be applied well beyond 5G telecom—never been used for vehicle communications?

Solutions to the vehicle-to-everything (V2X) problem have to date relied on new networking protocols built from scratch—only to discover chicken-and-egg problems, thorny standards wars, and real signal congestion challenges at scale.

By contrast, O-RAN allows V2X engineers to reuse the networking protocols already developed for cellular communications. O-RAN was developed assuming cellphone towers are generally fixed in place. But, as can be seen below, O-RAN accommodates mobile “towers”—cars and trucks, in this case—with little additional effort.

Imagining a New Way to Connect Vehicles

Self-driving vehicle technology has largely been an each-car-for-itself endeavor. Tesla’s approach, for instance, relies heavily on powerful on-board banks of computers and suites of sensors spread around the car.

However, as an alternative to the “data center on wheels” model, this new O-RAN approach to V2X that relies on each cars’ nearby neighbors, wherever they are on the road. Each O-RAN connected vehicle can then use a diversity of cars’ sensors and viewing angles for better group coordination and decision-making.

There is, to be clear, no O-RAN V2X test network operating in the world. Not yet.

It was just ten years ago that the Third-Generation Partnership Project (3GPP) released its initial cellular V2X standard. The 3GPP have refined V2X over three major releases since. In the U.S. and the E.U., the FCC and related European agencies have put forward other standards for short-range wireless V2X communication protocols.

However, no consensus standard has yet emerged. So lacking any clear, unambiguous guidance on the future of V2X networks, autonomous-car makers—like Waymo, Tesla, Zoox, and Cruise—have leaned more on self-reliance, bulking up each vehicle with as many sensors and GPUs as possible.

Here, though, is where O-RAN might be able to help.

A little like APIs (a.k.a. application program interfaces) connect one app to another on your smartphone, O-RAN serves as an API for the network itself. And because of O-RAN’s open standards, a wireless network becomes programmable, vendor-neutral, and open to custom applications called xApps.

To test our proof-of-concept framework, I have been part of a team simulating five-minutes of O-RAN V2X network traffic over one square kilometer of urban area, using real buildings and real-world road layouts from OpenStreetMap and traffic patterns generated by the modeling package SUMO. The simluations assumed a traffic density of 50-70 vehicles per km—not rush hour but not light traffic either. In our simulation, we assumed vehicles communicated via a millimeter-wave frequency of 28 gigahertz and that each component of our O-RAN V2X system had its own dedicated xApp.

Taken together, these inputs—real geometry, real traffic, and each vehicle’s live GPS position—constitute what network researchers call a digital twin of the urban environment. That’s a virtual replica detailed enough for the network to reason about the physical world in real time.

This virtual world gave us a real result, too.

The simulations, published recently in IEEE Network, revealed that existing V2X standards—in which cars uncoordinatedly spit out messages into the network—result in signals “talking” over each other some 80-100 percent of the time. However, using O-RAN signal coordination, the message “collision” rate dropped to near zero.

And that matters because a seized-up V2X network doesn’t just fail quietly. It can fail in ways that might make a road turn treacherous.

How O-RAN Can Coordinate V2X Traffic

High-frequency data links between cars are already difficult to maintain, even on a clear day with no buildings or city infrastructure getting in the way.

Yet, in this situation, existing V2X networks leave a car to conduct blind searches for each dropped signal beam. Traveling at highway speeds, that search takes long enough for the surrounding world to change completely.

An O-RAN network continuously tracks signal conditions across the network, and in O-RAN V2X simulations, we also gave the network access to a detailed map of the urban environment—building positions, road geometry, intersection layouts—combined with each vehicle’s GPS trajectory. Together, these parameters let the network’s control layer predict where and when a signal link is about to fail and instruct each car’s antenna to adjust before the connection drops.

Signal pointing is one failure mode. Losing the connection entirely—because no direct path exists at all—is another.

Consider, for instance, a crossroads of two busy streets, with a few alleys and parking lots adding to the list of potential dangers.

If a signal from car A cannot reach car B directly, or if the path length is too far for an individual beam to travel, the signal must find an intermediary car or stationary sensor nearby that can pass along the message. And existing V2X standards are slow and reactive—polling potential relay vehicles one-by-one: Are you available? Can you redirect this message?

By contrast, O-RAN keeps a running graph of optimized message routes, accounting for a range of real-world constraints. So when an O-RAN link fails (whether that link is direct from sender to receiver—or indirect), the system already has a reroute mapped out.

This is partly why we included “multi-hop routing” in the O-RAN V2X simulations.

Multi-hop V2X O-RAN routing complicated three separate elements of the simulation: for each signal’s middleman (some cars may be ideally positioned to relay a signal from car A to car B, but we made the simulation neglect any cars that were also overwhelmed with their own signals and signal-processing needs); for each signal’s strength (we required that every intermediate link be able to maintain a stable network connection, factoring in distance and traffic conditions); and for each signal’s latency (we required a realistic accounting for added signal latency time for each additional hop in a multi-hop routing).

And with each added complication, O-RAN V2X multi-hop routing continued to extend the network’s capacity from 25 percent of nearby cars connected (without multi-hop) to nearly 100 percent (with multi-hop).

These complications, at least at the simulation level, did not slow the V2X network down.

How Could O-RAN Ever Be Scaled Up for the Real World?

We are in touch with potential collaborators and institutions to develop testbeds, prototype hardware, and tester vehicles for potential proving grounds. The Institute of Science Tokyo, for instance, has already expressed interest in working on some of these early-stage problems.

To date, our published research on O-RAN V2X has centered around a computer simulation only. Real-world hardware will undoubtedly surface challenges our simulation could not. So questions of network latency and the computational overhead needed for O-RAN V2X signaling remain as yet unresolved.

Plus, concerns about full interoperability and realistic security will each demand their own investigations. After all, no one will trust a V2X network to do anything if that network’s cyber vulnerabilities haven’t been anticipated and patched in advance.

Realizing the O-RAN V2X vision will require progress on multiple fronts simultaneously. On the standards side, O-RAN’s vehicular extensions—the interfaces that allow vehicles to participate in the network as managed elements rather than passive users—would ultimately need to be formally adopted by the O-RAN Alliance and recognized by 3GPP’s V2X specifications. That process takes years.

On the industry side, there is a more immediate problem that our architecture is already positioned to solve: interoperability.

Today, a car made by one manufacturer cannot necessarily parse V2X sensor data sent from a car made by another. Firmware is proprietary; data formats differ. But an O-RAN control layer would act as a universal translator—normalizing each vehicle’s data into a common format and accelerating a push toward true multi-platform vehicle-to-vehicle communications. A more widespread and truly universal standard would, by itself, represent a substantial step forward for V2X.

From Your Site Articles

Tech

OpenAI says it slowed Astra model development over security concerns

Published

1 hour ago

August 7, 2026

qasimgillani

OpenAI said Friday it has suspended work on some aspects of its upcoming model Astra after an internal review found it had made significant advancements in agentic coding and cybersecurity — enough to warrant concern over its capabilities.

OpenAI said in a blog post Friday that this model, which is still in development, reached its “critical cybersecurity threshold,” meaning it could independently identify and carry out cyberattacks against traditionally well-protected real-world systems. Under the company’s “Preparedness Framework,” which it created in 2023, this triggered additional safeguards.

“While we continue to benchmark and assess this model, our preliminary evaluations indicate strong enough performance that we cannot rule out Critical capability level at this time,” OpenAI wrote. “Astra is an upcoming model, and was not involved in exploiting Hugging Face.”

The disclosure highlights an unusual moment in the topsy-turvy, and still nascent frontier AI labs sector. Companies across every industry hold back products over potential risks, including for safety and cybersecurity concerns. But they rarely announce those decisions publicly when it’s a product that is still under development.

In this case, OpenAI is already under scrutiny after a different unreleased model breached Hugging Face’s systems during internal testing — the first verifiable incident of an AI lab losing control of its model. Since then, OpenAI and AI labs such as Anthropic have disclosed other incidents in which AI models breached their sandboxes and posed threats during cybersecurity tests.

The string of cases — seems like a new disclosure every day now — has triggered varying reactions from cybersecurity experts, lawmakers and the AI labs themselves. Some express fear and call for stricter oversight. But there’s also a bit flexing. In certain circles, any AI lab with a model that has that kind of capability will be seen as an impressive advancement.

OpenAI said it was sharing this information because it believes “it’s important to be transparent with the public and the safety and security communities about this potential shift in capabilities.”

The AI lab said it’s also taking action, including enacting stricter security controls and pausing internal activites involving Astra that don’t meet these beefed guardrails. OpenAI said it is working with relevant government agencies and “select AI safety organizations” to test the capabilities for this model.

When you purchase through links in our articles, we may earn a small commission. This doesn’t affect our editorial independence.

Tech

Cloudflare Launches Kitesurf, a Lightweight Browser Built for AI Agents

Published

2 hours ago

August 7, 2026

qasimgillani

Just like humans, AI Agents need web browsers designed to meet their specific needs.

The primary way we access the internet is through a web browser. Similarly, AI agents require a browser if they are to perform some tasks on our behalf. However, the current browsers weren’t created for machine actors. They contain a lot of unnecessary functionality and lack certain security measures needed for agentic actors.

Cloudflare has introduced Kitesurf, a new headless browser designed specifically for AI agents, with lower CPU and memory requirements and built-in isolation. This product is available in Beta version through Browser Run, Cloudflare’s headless Chrome browser in the cloud.

The challenge with traditional browsers

Chromium-based headless browsers can consume significant CPU and memory because they support many features designed for human users that AI agents may not need.

In Cloudflare’s own tests, Kitesurf used 3.1 to 3.8 times less CPU and 4.7 to seven times less memory than Chromium, depending on the task. However, Kitesurf took 1.7 to 1.8 times longer to complete those tasks.

Cloud engineers will quickly notice that these are some of the key cloud resources that drive up the cloud bill.

The desire to get a specialized browser for AI agents didn’t just begin with Cloudflare. In April 2025, OpenAI shared that they would be interested in buying Google Chrome, if Google was forced to sell due to the mounting regulatory pressure. The intention was to build on it to develop their AI browser.

The need for specialized browsers for autonomous agents was clear.

How Kitesurf fits into the existing landscape

Kitesurf joins other lightweight browser projects designed for automation, including Lightpanda and Obscura.

Cloudflare’s developers said Kitesurf was initially inspired by Obscura, a Rust-based headless engine for AI automation.

The key differentiator is that Kitesurf is built on Cloudflare Workers, the platform’s serverless compute environment. This means that Cloudflare customers don’t need any special setup to get started with the browser.

Furthermore, Kitesurf is compatible with software libraries like Puppeteer and Playwright, which provide high-level APIs to interact with browsers. Therefore, developers don’t need to do away with these tools that they’ve already been using.

The enterprise takeaway

AI agents in production need the right tools and guardrails to execute their tasks. This ensures better performance and also protects them from attacks like prompt injection.

Cloudflare shared that the Kitesurf browser was designed with isolation for each page in mind, ensuring that no information leaks from one page to another. This security measure ensures that if an agent accesses a malicious source in one page, it can’t corrupt other browser pages.

Additionally, Cloudflare has already provided Kitesurf on a free trial basis to its customers. Therefore, enterprises can experiment with this new product without risking their budgets.

The Cloudflare team has also said that they intend to open-source the tool once it’s ready.

As autonomous agents increasingly need web access to complete their tasks, organizations need to manage the resource and financial constraints that this presents.

Read more: BioShocking attack exploited AI browsers to expose credentials, highlighting the security risks that agent-focused browsers such as Kitesurf must address.

Tech

After Rippling blew millions on AI in months, it built an employee ROI tool

Published

3 hours ago

August 7, 2026

qasimgillani

HR software provider Rippling this week unveiled AI Spend Console, an anti-tokenmaxxing product that helps a company track and contain its AI spending. One of the most interesting features is that it maps how much individual employees, teams, and roles are spending and if they are genuinely more productive, or generally producing more AI slop.

The company promises the tool will show “which engineers have high AI spend whose peers frequently ask them to redo work in code reviews,” the company says in its blog post.

The tool was born after Rippling went all in on tokenmaxxing at the start of the year — as so many did — only to discover employees were wildly burning cash. Chief Product Officer Matt MacInnis still recalls the executive team meeting in March when CFO Adam Swiecicki presented a number that shocked them.

Rippling was on track to burn 40% of its R&D headcount budget on AI tokens, meaning it was spending as much on tokens as 40% of all the compensation it paid employees in that unit. Millions of dollars. (The R&D org is home to engineering at most tech companies.)

Spending was growing by 80% month-over-month, and if that trend continued, the next year it would spend almost as much on AI tokens — 90% — as it spent on its high-paid R&D unit employees.

“We were incredulous,” MacInnis told TechCrunch.

Management immediately undertook an “urgent” project to understand the spending and what they were getting for that money, he said. In fact, the launch ad for this new product features Swiecicki sitting on a stool while employees are picking up wads of cash and dumping them into a paper shredder.

When Rippling conducted an analysis, it discovered facts like “roughly 10–15% of our employees were driving about 60% of total AI spend. One engineer was spending $50,000 a month,” its blog post shared.

Rippling didn’t want to stop AI usage, just rein it in — a lot. It started by negotiating a max spending cap with each of the tools its company used: Cursor, OpenAI, and Anthropic. It immediately found an obvious issue: Employees defaulted to using the most recent, and most expensive, frontier models for all tasks.

“The truth is that the inference providers, like Anthropic and OpenAI, have absolutely no incentives to help you control your spend. They have every incentive for it to be a runaway expense, and that’s exactly what they do. They don’t provide you with great usage insight, and they don’t collaborate with one another,” MacInnis said.

That was a common early-2026 problem. Now, eight months into the year, enterprises have figured out a couple of things. First, they know they need multiple models from multiple AI labs at various price points, including a frontier open weight option, perhaps of Chinese origin.

Rippling founder and CEO Parker Conrad noted last month that when his company conducted its own benchmarks for its own internal uses, it discovered SpaceX’s Grok was the all-around leader but that “GLM 5.2 is 85% cheaper but [had] nearly identical performance” to the frontier models. (SpaceX now owns Cursor, which offers access to Grok and dozens of other models.) Z.ai’s GLM 5.2 has become a particular favorite Chinese model for coding tasks among tech companies these days. Databricks has also been championing it.

Second, enterprises now know they need an AI gateway that routes prompts to the best, most cost-effective model for the task. Rippling came to that conclusion too. So it built its own AI gateway that is also part of this product. MacInnis says it is possible for enterprises that already use another gateway to still use the AI Spend Console product, though if they want the features that govern spending, they would need to use Rippling’s gateway.

AI Spend Console produces dashboards (once known as leaderboards in the tokenmaxxing days) that score attributes such as prompts per day combined with work output (lines of code/pull requests) and spend.

With this tool in place, Rippling said it dropped its token spend from 40% of its headcount budget to about 15%. But it didn’t curtail AI usage. The company spent a peak of 605 billion tokens the month the CFO issued his warning, MacInnis shared. In July, internal usage hit 600 billion tokens again, yet “the cost of July’s token spend was 37% of the cost of April’s token spend,” he said.

“That’s just because now we’re routing to the more effective models,” he said, joking that “we’re not letting the sales team do grammar updates using Fable.”

But technology solutions aren’t enough, Rippling notes. The company found people using AI effectively and made them “AI captains” tasked with assisting the rest of the company.

Still, such efforts to use AI beyond engineering are a work in progress, MacInnis says, as software engineers have been the primary users so far. But Rippling is, for example, working on it for customer onboarding teams to automate some mailing data and data-reconciliation tasks. The dashboard will then measure productivity in terms of onboarding more customers.

“We have to be able to link token consumption in G&A functions and in customer-facing functions back to productivity. If we can’t do that, all bets are off on any of this stuff being available to the broader employee base,” MacInnis says.

So, if Rippling is an example, tokenmaxxing may have swung so far the other direction that employee AI access may no longer be like Slack or email. If the company can’t measure productivity, then all employees might not have access.

As for the product, AI Spend Console is included for Rippling’s HR subscribers, though there are additional AI usage-based costs. It can also be purchased as a stand-alone product and integrated with another HR system of record, MacInnis says.

When you purchase through links in our articles, we may earn a small commission. This doesn’t affect our editorial independence.