SpaceX Takes Cursor as AI Power Moves Down the Stack

SpaceX Takes Control of Cursor

One of the most widely used AI coding tools now belongs to SpaceX. The deal puts Cursor’s developer interface, models and access to a huge GPU fleet under one corporate roof.

Stay with this one, because the acquisition completed on 14 August is more revealing than another round of model benchmark claims. Cursor says it’s officially part of SpaceX, finishing a process that began in April and combining its AI coding platform with SpaceX’s large-scale computing infrastructure.

Cursor says access to SpaceX’s GPU fleet will help it build more capable models at lower cost. Those are company claims, and neither the performance improvement nor the savings have been independently demonstrated. What has changed immediately is the structure around the product: Cursor now has the compute and capital of a major aerospace and AI business behind it.

The financial terms remain murky. Earlier reporting said the agreement gave SpaceX an option to acquire Cursor for 60 billion US dollars, but the closing announcement didn’t restate a final transaction value. So that figure is useful context, not a confirmed closing price.

Cursor also says it will keep serving external customers. It isn’t being converted into an internal SpaceX engineering tool, at least according to the announcement. That reassurance matters because companies have already built development workflows around Cursor, and a sudden retreat from the broader market would be deeply disruptive.

The more interesting question is what external service means under this ownership. Customers aren’t only choosing an editor or a model. They’re becoming dependent on a stack whose developer environment, proprietary models, computing infrastructure and corporate priorities are increasingly aligned under a single owner. That could produce faster development and lower prices. It could also make switching harder if important workflows become closely tied to Cursor’s particular agents, context systems and models.

My read is that the coding-agent contest is moving beyond who can release the cleverest model. The durable advantage may come from controlling the place where developers work, the models acting on their code and the expensive infrastructure running those models. SpaceX can now connect all three.

For organisations, that makes vendor assessment broader than model quality. Reliability, pricing, data handling, product continuity and the practical cost of moving development context elsewhere all become part of the same decision. Cursor may genuinely improve with SpaceX behind it, but customers shouldn’t treat the promised benefits as established until they appear in the product and can be measured.

There’s a tension here worth keeping in view. Vertical integration can make an AI coding platform cheaper and more capable because fewer parts of the stack need to be negotiated separately. The same integration concentrates leverage. A tool that begins as a convenient layer in the development process can become infrastructure that an engineering organisation struggles to replace.

That’s why this acquisition deserves attention even before Cursor ships anything new. It shows where well-funded AI companies think defensible power lies: not only in a model, but in the combination of compute, software and the daily interface through which automated work gets done.

Water Systems Exposed

Corporate power is one kind of control; physical infrastructure makes the stakes much less abstract.

Reporting published on 10 August established that attacks on internet-exposed water and wastewater control systems had affected facilities across at least 12 US states. An earlier FBI alert had confirmed malicious activity against internet-facing programmable logic controllers in at least seven states.

A programmable logic controller, or PLC, is an industrial computer that operates physical equipment. In a water facility, that can mean pumps, valves and treatment processes. The confirmed effects included lost water pressure, flooding and degraded operations. This wasn’t only reconnaissance or stolen data. The compromises interfered with real services.

The Washington Post reported that US intelligence had confidence actors associated with Iran’s Islamic Revolutionary Guard Corps were responsible. The US government, however, hasn’t publicly attributed the campaign to a specific Iranian unit. The operational evidence is firmer than the public attribution, and those two levels of certainty shouldn’t be blurred.

The exposed systems are the uncomfortable part of this story. Attackers targeted PLCs reachable from the internet, turning basic weaknesses in connectivity and access control into physical disruption. Defending against that doesn’t begin with a futuristic security model. It begins with removing control equipment from direct internet exposure, strengthening authentication, locking down remote access and maintaining manual procedures that staff have actually tested.

That may sound mundane, but mundane controls are often what keep an intrusion from becoming a public-safety event. An advanced monitoring system can help detect suspicious activity; it can’t compensate for a controller that never needed to be openly reachable.

For water operators and the authorities overseeing them, the sensible conclusion is that exposure management deserves the urgency normally reserved for more dramatic cyber projects. The number and severity of all affected facilities haven’t been disclosed, so the full scale remains uncertain. There’s already enough evidence, though, to justify treating every internet-accessible industrial controller as an immediate operational risk rather than another item for a long-term security roadmap.

The wider lesson is sharp. When software directly controls pressure, flow or flooding, a weak password or poorly designed remote connection can have consequences far beyond the network. Public infrastructure doesn’t need an especially sophisticated attacker to become vulnerable. It needs one reachable path that should have been closed.

Robotaxis as a Partnership

From vulnerable infrastructure, let’s shift to infrastructure being assembled deliberately, one partner at a time.

Uber and Pony.ai announced on 13 August that they plan to deploy more than 2,000 Level 4 autonomous vehicles across four additional European cities. Level 4 means a vehicle can drive without a human taking control within the specific conditions and area for which the system is designed.

The companies are building on an existing launch in Zagreb. Their proposed model splits the job across several parties: Pony.ai supplies the autonomous-driving system, Uber provides the ride-hailing platform, and local fleet partners operate the vehicles. They also intend to expand the collaboration in the Middle East.

There are major blanks in the announcement. Uber and Pony.ai didn’t name the four European cities or give a deployment timetable. Every launch remains subject to local regulation. The figure of more than 2,000 vehicles is therefore a plan, not a fleet already on the road, and there are no disclosed commercial terms showing how the economics will work for each participant.

Even with those limits, the operating model is significant. Robotaxi companies once looked likely to build vertically integrated services: the driving technology, the vehicles, the fleet and the customer application all controlled by one business. Here, Uber is positioning itself as the distribution layer connecting riders to autonomous systems developed by other companies.

That could make deployment more practical for cities and fleet operators because no single participant needs to own every part. It also creates coordination work. Vehicle capability, local permits, maintenance, insurance, fleet operations and passenger support still have to function as one service, even when responsibility is divided among several organisations.

My assessment is that robotaxi expansion is becoming as much a regulatory and ecosystem problem as an autonomy problem. For Uber, supporting multiple driving systems could be more strategically valuable than winning the race to build one itself. For cities, the partnership model offers flexibility, but it also makes accountability worth examining carefully before permits are issued. When something goes wrong, a service assembled from several layers still needs a clear answer about who is responsible.

YouTube Raises the Earning Bar

The next gate is digital rather than geographic, and it affects who gets a chance to earn.

YouTube announced on 10 August that it will raise key entry thresholds for new applicants to the YouTube Partner Program from 1 February 2027. New creators will need either 8,000 qualified public watch hours over 365 days or 20 million qualified Shorts views over 90 days.

That doubles the central watch-hour requirement. Existing members of the Partner Program are protected: YouTube says they won’t lose access simply because they fall below the new entry thresholds.

The company is also changing monetisation terms and expanding revenue sharing from Premium Lite. It hasn’t fully quantified how those changes will affect individual creator income, so it’s too early to claim that established channels will necessarily earn more or less. The part we can measure is the higher barrier confronting people who aren’t yet inside the program.

That shift lands at an interesting moment. Automated editing, synthetic media and other production tools are lowering the cost of making videos. YouTube appears to be responding to a world with more abundant content by making access to monetisation more exclusive. Production gets easier; earning platform revenue gets harder.

For a new creator, the practical risk is that more time and money may be required before the channel produces direct platform income. A creator can meet the higher threshold, but the platform retains control over discovery, qualification and monetisation terms along the way. Established members, by contrast, gain some protection from the new barrier because their existing status is preserved.

My view is that anyone building a new media business on YouTube should treat Partner Program income as a later-stage possibility rather than an early operating assumption. That isn’t a prediction that new channels can’t succeed. It follows directly from a higher qualification bar whose effects won’t be measurable until after it takes effect.

The change may discourage low-effort automated uploads, which would suit viewers and serious creators. It may also favour well-funded channels that can sustain production for longer without revenue. We don’t yet know which effect will dominate. What’s certain is that YouTube is shifting more of the early discovery and income risk onto the person making the work.

A Reusable Satellite Mechanic

Now for a genuinely different maintenance problem, a long way above the ground.

Northrop Grumman’s SpaceLogistics business has completed a servicing transition around Australia’s Optus D3 satellite and is preparing a reusable robotic vehicle to work on ageing spacecraft from 2027.

The earlier Mission Extension Vehicle detached from Optus D3 after providing more than a year of life-extension service. That type of vehicle effectively stays committed to the satellite it supports. The new architecture is different: a Mission Robotic Vehicle is intended to visit spacecraft, install separate propulsion pods and then move on to other jobs.

Northrop launched the robotic vehicle and three Mission Extension Pods in July 2026. The company says each pod can add about six years to a satellite’s service life. Beyond pod installation, the vehicle is designed for inspection, relocation, repair and upgrade work.

The central capability still needs to be demonstrated. Its first pod installation is planned for 2027, and the reusable commercial service hasn’t yet completed that defining operation. Northrop’s six-year extension figure is also a company claim rather than a result already observed across routine missions.

If it works, the economic change could be substantial. An operator might extend a valuable satellite without dedicating a complete servicing craft to it for the remainder of the mission. A reusable robot could distribute its cost across several clients while leaving a smaller propulsion pod attached to each spacecraft.

That reduces some pressure to replace an otherwise functional satellite merely because its onboard propulsion is running out. It also pushes orbital infrastructure towards a model we already understand on Earth: assets can be inspected, maintained and upgraded instead of treated as mostly disposable hardware.

For satellite operators, the useful judgment is to view servicing capability as part of future fleet planning, but not yet as a routine assumption. The first attachment and subsequent operations need to prove that the reusable model works reliably and commercially.

There’s a strategic edge as well. Rendezvous systems and robotic manipulators that can approach, move or modify a friendly satellite are inherently dual-use capabilities. The same technical competence has implications beyond maintenance. That doesn’t negate the commercial benefit, but it means reusable servicing will be watched by governments as well as customers. The shift from a dedicated tug to a roaming repair vehicle changes both the economics of satellite life extension and the significance of the machinery doing it.

Account Security Becomes Personal Safety

Back on personal devices, one short warning deserves more weight than its length suggests.

The FBI said on 10 August that sexual-exploitation actors are compromising social-media and personal accounts to steal explicit material. Attackers then attach identifying information to that material and distribute or sell it online. Adults and minors have both been targeted.

The methods aren’t exotic. They include phishing, reused credentials, lists of passwords or PINs, and people impersonating customer-support staff. That combination makes the warning relevant well beyond anyone who thinks of themselves as a likely target for an advanced cyberattack.

An ordinary account takeover can produce consequences that are difficult or impossible to reverse once material is copied and republished. The briefing identifies risks including extortion, employment harm, reputational damage and threats to physical safety. The FBI hasn’t disclosed how many victims are involved, the financial scale or which groups are responsible, so this warning describes a serious pattern without establishing its total reach.

The protections are familiar because they work against familiar entry points: use unique passphrases, enable multifactor authentication and avoid keeping sensitive media on internet-accessible services where possible. Impersonated support messages also deserve suspicion, especially when someone asks for credentials, codes or urgent access.

The editorial takeaway is that cloud-photo and social-account security now belongs in the category of personal-safety infrastructure. Financial theft isn’t the only plausible harm from a compromised login. When stolen material is packaged with a person’s identity, a reused password can expose their work, relationships and physical security all at once.

Fewer Licence Gaps in Software Inventories

There’s also a quieter GitHub change that could remove a fair bit of compliance grunt work.

On 13 August, GitHub began supplementing repository licence detection with metadata from major package registries. That information feeds dependency graphs, software bills of materials and GitHub Advanced Security.

GitHub says it indexes roughly 170 million packages. Before the change, 45 per cent lacked an identified licence in its data; that figure has fallen to 24 per cent. The improvement applies automatically to dependency and compliance views that consume GitHub’s licence information, so teams don’t need to rebuild their software inventory process merely to receive the broader coverage.

That’s a large reduction in missing metadata, but 24 per cent is still roughly one package in four. Registry declarations can also be incomplete or wrong, and GitHub hasn’t quantified the accuracy of the new registry-supplied classifications. More complete data shouldn’t be confused with conclusive legal analysis.

For security, legal and engineering teams, the immediate gain is a better first-pass inventory. Automated systems should surface fewer packages with no licence information at all, leaving people to focus on unresolved or conflicting cases. That can make software bills of materials more useful in practice, especially in organisations with large dependency sets.

My take is that this improves the value of automated compliance without removing the need for escalation. A generated bill of materials can tell a team what GitHub and package registries report. It can’t settle every ambiguity about the rights attached to a package.

The sensible operating model is therefore automation for coverage, followed by human review where licence data is absent, contradictory or consequential. GitHub has reduced the blind spots considerably. It hasn’t made them disappear, and teams that treat the resulting inventory as infallible would be replacing one compliance gap with a different one.

What Changes for You

One last development is immediately usable if you build software in JetBrains, though it comes with a real governance choice.

GitHub added two capabilities to Copilot’s JetBrains integration on 11 August: persistent memory across sessions and Ollama as a bring-your-own-key model provider.

Persistent memory allows Copilot to retain relevant project context between working sessions. For a long-running codebase, that could reduce the time spent repeatedly explaining architecture, conventions and current work. Users can disable the feature, and organisations need to decide what project context they’re comfortable retaining.

The second addition lets developers select models available through a local Ollama installation instead of relying exclusively on GitHub-hosted model providers. That gives JetBrains users more control over where model execution happens and makes it easier to experiment with locally hosted options while staying inside the Copilot interface.

There are real limitations. Ollama requires a working local model installation and enough hardware to run the model at a useful speed. GitHub hasn’t shown that local models will match hosted alternatives for capability, latency or tool compatibility across different projects. Local availability is a choice, not a guarantee of equal performance.

Memory has the opposite trade-off. Retained context can make the assistant more useful over time, but it creates a governance question about which project details persist. Teams handling sensitive code should make that an explicit setting and policy decision rather than letting convenience settle it by default.

For JetBrains developers, the practical improvement is continuity plus model choice. You can spend less time rebuilding context and test local execution without leaving the coding environment. The useful approach is to evaluate the two features separately: decide what Copilot may remember, then measure whether a local model is actually capable enough for the work you expect it to do.