This week, Cohere released North Small Translate 1.0 under a CC BY-NC 4.0 license: the weights are there to download, evaluate and study, but not to run in production without a commercial agreement.

It’s an interesting choice from the Canadian foundation model company, which has built its pitch around AI sovereignty for regulated industries and describes this release as part of a mission “to make sovereign AI a technological reality.” Sovereignty there means control over where the model runs and who sees the data. A commercial license keeps that promise intact. It stops short of independence from Cohere. Enterprises keep their data and their infrastructure. They don’t get to fork the model, build a product on it, or keep running it if the terms change at renewal.

Open weights, except for commercial production

North Small Translate is an open-weights mixture-of-experts model built for machine translation across over 50 languages and locale variants. It has 218 billion total parameters, with 25 billion active parameters and a 16,000-token context window.

Not all users have the same access to those weights.

Per Cohere, the model is designed to give researchers, developers, and enterprises “flexible ways to evaluate and deploy machine translation while retaining control over their data and infrastructure.”

That’s an appealing description for organizations keen on pursuing sovereign AI. But the open-weight release comes with an important caveat: Not all users get the same rights to take advantage of those weights.

North Small Translate is available today on Cohere’s free tier through the Chat V2 API. For those who intend to use the model weights for non-commercial use, the FP8 weights are available on Hugging Face under the CC BY-NC 4.0 license.

But if enterprises want to put them into production, then a different set of terms applies. They’ll have to purchase a commercial license and deploy North Small Translate through Model Vault, Cohere’s fully managed inference platform.

Cohere’s not the only one drawing a line around open-weight use

Other AI companies are starting to attach more conditions to their open-weight models, too.

Last month, Chinese AI lab Z.ai released the weights for its flagship GLM-5.3 model on Hugging Face. But like the Canadian AI company, it also changed its licensing terms depending on who is deploying the model — a departure from its previous approach. While GLM-5.2 shipped under the permissive MIT license, GLM-5.3 adds new requirements for certain commercial users.

Cohere, for its part, has been similarly mum about why it made North Small Translate’s open weights noncommercial.

These requirements apply only to companies with aggregate revenue over $10 billion over 12 consecutive months. Additionally, if these companies want to host GLM-5.3 or its derivative works for commercial purposes, they have to first pass the Chinese lab’s security review.

Z.ai didn’t explicitly spell out why it decided to make such an about-face for GLM-5.3, which is especially puzzling given that its predecessor shipped under MIT without any commercial stipulations. Cohere, for its part, has been similarly mum about why it made North Small Translate’s open weights non-commercial.

Sovereign deployment, with restrictions

The Canadian company’s decision to make North Small Translate available as open weights but gate commercial use is a head-scratcher, given its history of selling sovereign AI to enterprises.

In fact, in June, it pitched North Mini Code, its first coding model, as a response to developers demanding the same sovereignty guarantees that regulated industries have long required.

Unlike North Small Translate, though, this open-weight model was released under an Apache 2.0 license from the get-go — without any comparable restrictions for commercial users.

Clearly, Cohere is going in a different direction with its latest open-weight release, emerging as another example of AI companies putting tighter terms around increasingly capable open-weight models.

The post Cohere’s new translation model is open weights — but not for commercial use appeared first on The New Stack.

On Tuesday, Warp introduced Warp Factories, open infrastructure for building cloud software factories, agentic systems that automate work across the software development lifecycle, which have been popping up in different forms from companies like Augment Code and Chainguard. 

Warp, an agent development platform, calls Warp Factories “the building blocks” for developers to create their own scalable factories. It’s pitching the infrastructure as the solution for two problems founder and CEO Zach Lloyd says are frequent engineering complaints: 1) measuring and improving coding agent ROI; 2) governance and control.

The aim is to tackle both problems by making sure “the annoying bits [are] taken care of” so developers can focus purely on optimizing factories for specific products. 

As Lloyd writes in a blog post, he “predicts software factories will be as ubiquitous as CI/CD in the next few years.” Experts tell The New Stack they see software factories gaining traction, but they’re more cautious about the timeline.

“I think the software factory is inevitable,” Lee Faus, founder and CEO, Atomic Software and former global field CTO, GitLab, tells The New Stack. “But before software factories become as foundational as CI/CD, the industry needs to solve a deeper infrastructure problem.”

Specifically, he calls out the importance of tracing agent work: “We’re spending a lot of time talking about how to build the software factory,” Faus continues. “I think we’re going to spend much more time asking what becomes the system of record for the factory.”

Build the factory without building all the infrastructure 

Lloyd acknowledges that many organizations already have engineering teams at work building cloud software factories — but he argues that’s too big to be an inside job. 

Warp Factories, thus, emerges as the infrastructure on which developers can build their own factories, providing the core components to speed development without making organizations sacrifice flexibility, programmability, customization, or ownership.

When asked about Lloyd’s take on building infrastructure, Erik Gfesser, long-time engineer, tells The New Stack he agrees it doesn’t make sense for most organizations to tackle it in house.

As Lloyd writes, Warp’s new infrastructure is “built to increase coding agent ROI over time” with evals and benchmarks to measure effectiveness and built-in self-improvement and memory. Developers get queryable metrics on agent throughput, cost, quality, and ROI, visible via the Factory control room, API, and Factory MCP. Scorers evaluate how work items move through the factory with an eye on things like token spend, code quality, and whether or not the work introduced defects. 

From there, those scores power self-improvement loops and benchmarks. “Observer” agents score select agent runs and then search for ways to make improvements by adjusting variables like the harness, model, or context before making PRs to improve underlying factory functionality. Benchmarks, meanwhile, let developers score tasks across different models and harness configurations to compare performance.

Governance gets easier, but there’s more to solve

Per Warp, the infrastructure includes features to address governance and control, alongside factory definitions as version-controlled code, definitions for distinct agents, plus skills, MCPs, and permissions. 

Looking more broadly, Faus tells The New Stack software factory governance will require more than just controlling how agents operate, though:

“A software factory without a record of change risks becoming a very efficient way to manufacture code that nobody can fully explain.”

“Shared infrastructure can make permissions, model access, tool use, MCP connections, policies, cost, and execution environments easier to manage centrally. That’s valuable,” he says. “But governance isn’t just being able to control what an agent is allowed to do. It is being able to prove what it actually did.”

As software factories help speed up code generation, he says the harder problem becomes understanding the scores of interconnected decisions both humans and agents make across the development cycle. 

For example, if one agent triages an issue, another researches it, a third implements it, and still others review and verify it, how can an engineer reconstruct why that change was made six months later? “That record has to remain connected to the change itself,” says Faus. “[Otherwise,] a software factory without a record of change risks becoming a very efficient way to manufacture code that nobody can fully explain.”

Software factories are probably the future, but it will be a slow roll-out

Though Warp’s founder is gung-ho about the rapid rise of software factories, other experts are less certain. Like Faus, Gfesser expects software factory adoption to take time: 

“My expectation is that software factory adoption will likely be fragmented across multiple vendors similarly to the early stages of CI/CD.”

“As an early adopter of CI/CD myself, I know that CI/CD didn’t catch on the way it did until quality open source products were made available for widespread usage.”

He points out that while the Warp client is open source, the server, the Warp Drive backend, and OZ (Warp’s agent orchestration layer) are proprietary. Also worth noting: OpenAI is named as the founding sponsor of Warp’s open source repository. 

“As such, my expectation is that software factory adoption will likely be fragmented across multiple vendors similarly to the early stages of CI/CD,” he says. 

The post Warp wants to make it easier to build your software factory appeared first on The New Stack.

AI trash-talkers love to rip on the technology for failing to produce meaningful business results, often pointing to studies like that from MIT NANDA, which reveals a 95% failure rate for enterprise AI solutions, or that from IDC, which states “only 9% of [Europe, Middle East, and Africa] organizations have been able to deliver measurable business outcomes from most of their AI-related projects over the past two years.” 

What many AI skeptics fail to account for is the experiential nature of AI prototypes; not all these projects are actually meant to move beyond the testing phase. Still, a 5% success rate is embarrassing. 

What’s the holdup? 

Two things. First, most organizations build AI prototypes on sand; that is, the data infrastructure on which they build early applications can’t support later moves to production. Meanwhile, the operational teams responsible for managing those applications in production often lack the human power to keep up with engineering’s growing output. 

4 reasons prototyping infrastructure  ≠ production infrastructure

When asked why so many AI prototypes don’t make it to production, Phillip Merrick, co-founder, CPO, and chairman, pgEdge, tells The New Stack that data infrastructure is largely to blame. 

Specifically, he explains that prototype environments don’t meet the requirements of large enterprises for production, naming four main ways they fall flat.

First, Merrick says prototyping environments lack the deployment flexibility organizations need to move from prototype to production. 

Vendor-managed cloud platforms, he acknowledges, may seem like an obvious choice for prototyping, as they allow teams to get up and running quickly. Still, he warns they lack the technical chops to support AI applications in production, especially in security, compliance, and governance. Particularly for organizations in healthcare, finance, or other regulated industries, vendor-managed cloud platforms often lack the stringent controls found in self-managed cloud or on-prem environments. 

“You’ve got to be able to choose where that AI prototype is ultimately going to be put into production.”

In this way, flexibility and security go hand in hand. Merrick asserts. “You’ve got to be able to choose where that AI prototype is ultimately going to be put into production.” 

Similarly, when it comes time to shift to production, Merrick says vendor-managed cloud platforms can introduce data sovereignty challenges at both the enterprise and regional levels. 

“Your data layer is obviously where you enforce this,” notes Merrick. But he says the environments most teams use for prototyping muddy the waters: “If it’s on a vendor-managed platform in who knows what cloud, what region, then you’ve lost data sovereignty.” 

Lastly, Merrick brings attention to reliability, explaining that AI prototypes can’t move into production without assurance of high availability. For example, when it comes time to upgrade the database or swap hardware, can it be done without downtime? 

“In the vendor-managed cloud world, the answer to that is almost always no,” says Merrick, reiterating his point that moving AI apps from prototype to production requires enterprise-grade infrastructure. 

So why are developers prototyping where they can’t productionize?

If data infrastructure selection is what’s holding developers back from moving AI prototypes into production, then why do they keep starting on the wrong foot? 

As Merrick explains, many are attracted to the ease of use of vendor-managed cloud platforms. “These prototyping environments admittedly make it very easy to get started,” he says. But prototyping shortcuts, it seems, don’t pay off in the long run, as someone else is ultimately on the hook for making those prototypes production-ready. 

Still, Merrick doesn’t blame developers for looking for the easy way out. Rather, he says there’s a disconnect between the prototyping playground and the production battleground that prevents developers from understanding what it will take to productionize prototypes down the pike. 

---

More pgEdge articles in The New Stack

• Why developers are betting on Postgres for AI
• Moving AI apps from prototype to production requires enterprise-grade postgres infrastructure
• Reinventing PostgreSQL for the Next Generation of Apps
• How distributed Postgres solves the cloud’s high-availability problem
• Scaling AI inference at the edge with distributed PostgreSQL

---

Years ago, he says, tooling decisions were primarily made top-down without developer input: “Then, starting 15–20 years ago, the developers won back, quite rightly, the power in being able to choose their own tools.” 

The problem now, Merrick claims, is that developers make tooling decisions exclusively for prototyping environments, without anticipating production needs. Internal divisions mean developers are often only responsible for building prototypes before passing the baton to an entirely separate operations team for production: 

“The upshot is you really don’t have, in some organizations, this throughline of understanding [of] what the production requirements are all the way back to the developer making the initial choices.” 

For Merrick, this disconnect is where AI projects start to fall apart, as teams are left trying to move AI prototypes from accessible-but-inadequate vendor-managed cloud platforms to enterprise-grade data infrastructure that meets requirements for deployment flexibility, security, data sovereignty, and high availability. 

“But if you make the right data infrastructure choice, you won’t have that disconnect,” he says, “because you’ll have this throughline from prototype to production.” 

He names Postgres as the data infrastructure that best helps developers bridge this divide, calling it “the Swiss army knife of databases” due to its extensibility, fully open-source nature, and ability to address diverse data management problems, from unstructured data to vector embeddings to geospatial data. 

Where and how Postgres is run matters too, Merrick points out, again drawing attention to the limits of many vendor-managed cloud environments that often lack the governance controls to meet data requirements and/or the deployment flexibility to shift to compliant on-premises or BYO cloud environments. 

But picking the right data infrastructure only solves half the problem

Merrick says there’s another part of the equation most organizations are overlooking: people, or more precisely, database administrators (DBAs) and their growing workloads. 

Per Stack Overflow’s 2025 Developer Survey, 84% of respondents use AI tools, up from 76% the year prior. Meanwhile, Supabase says over 60% of databases on its platform have been launched “by some sort of AI tool.” As Merrick points out, this explosion of productivity comes with a catch: there aren’t enough DBAs to keep up.

“You’ve had this massive, massive step shift in developer productivity,” he explains. “But you have to have some way of managing that on the production side; these databases can’t go unmonitored.” Operations and administration teams were already struggling to keep track of existing Postgres databases before agentic engineering added even more, he says: “Who’s going to manage them?” 

He says it’s time for agentic operations to catch up with agentic engineering. 

AI DBA agents can give humans “superpowers” 

If it seems Merrick is proposing organizations look to fully autonomous DBA agents to take over, he says the industry isn’t there yet: 

“The world is not ready for fully autonomous databases administered by AI DBA agents. But there is a massive resource shortage and productivity problem, and DBAs can only manage so many databases,” he explains. Meanwhile, new “AI applications require so many more databases to put in production.” 

“The world is not ready for fully autonomous databases administered by AI DBA agents.”

So how can organizations increase their operational capacity? 

Merrick says DBAs should look to new AI DBA agents, not to take over but to give them “superpowers” to monitor and manage more databases with less manual slog. 

pgEdge’s Ellie is one example. Part of the pgEdge AI DBA Workbench, Ellie is an AI agent that has 21 MCP tools and can run EXPLAIN ANALYZE, inspect schemas, query historical metrics, and walk through multi-step diagnostic workflows. When a database falters, Ellie finds the problem, diagnoses it, and provides a solution in the form of working SQL code for the human DBA to review. “When you’ve reviewed it and agree that it’s the right course of action, you literally press the play button, and the agent plays that SQL code into the database, and you solve your problem,” explains Merrick.

In this way, Ellie should bring more capacity to operations teams, where Merrick insists organizations are starved for DBA expertise. To his point, some industry predictions say 41% of today’s database professionals intend to leave the industry in the next decade, half moving into retirement and the rest seeking other work. 

“An agent … can actually respond to those alerts far more quickly and productively than a human can.”

Without AI agents, Merrick argues, DBA work is tedious, laborious, and time-consuming. As he explains it, a database may have been humming along just fine, but when there’s a snag, trouble can manifest across multiple applications; it’s then up to the DBA to comb through monitoring data to observe and diagnose the problem, essentially scouring for a needle in a haystack. 

“An agent,” he says, “can actually respond to those alerts far more quickly and productively than a human can.” 

Better infrastructure AND people: It takes two to improve AI prototype success rates 

In nearly any context, AI raises questions about quality over quantity, and enterprise AI projects are no exception. Agentic engineering means developers can now produce more, but all those prototypes don’t just fly directly into production. Limitations in both infrastructure and operational human power are creating obstacles that cause many AI prototypes to fail. 

For Merrick, easing the transition from prototype to production requires not only great AI tooling but production-ready data infrastructure, paired with agentic operations that can keep up with the agentic engineering boom. 

The post Why most AI projects fail: It’s infrastructure and people  appeared first on The New Stack.

OpenAI on Wednesday announced Jalapeño, its first custom inference accelerator, co-developed with Broadcom and supported by Canadian electronics manufacturer Celestica, and the first step in its multi-generation compute platform. 

The AI company says Jalapeño was designed to work with all large language models (LLMs) and will help make AI faster, better, and cheaper. Behind that rosy mission, OpenAI isn’t shy about its desire to own the full AI stack, something more AI giants are already leaning into.  

“Those serious about platforms should be serious about silicon.”  

As Ben Bajarin, CEO and principal analyst at consumer technology research firm Creative Strategies, posted on X: “Those serious about platforms should be serious about silicon.”  

Remember my mantra, yes this is an intentional play on Alan Kay's quote.

Those serious about platforms should be serious about silicon. https://t.co/ghWmCqkCKe

— Ben Bajarin (@BenBajarin) June 24, 2026

But with few technical details released, developers are left wondering if OpenAI’s widening footprint will be empowering or restrictive. 

Get in, Big Tech. We’re all building in-house chips now. 

OpenAI isn’t the only Big Tech name to mint its own AI chips. 

Way back in 2016, Google designed and built its own custom hardware for TensorFlow, its machine learning software, the Tensor Processing Unit (TPU). A couple of years later, Amazon debuted AWS Inferentia, its first purpose-built chip for AI and ML. Trainium then hit the scene in 2022, shortly followed by Microsoft’s Azure Maia AI Accelerator in 2023. And nothing is certain yet, but in April, Reuters reported Anthropic is contemplating designing its own chips, though the AI company remains noncommittal for now, at least publicly. 

Why is everyone jumping on the custom-chip bandwagon? 

Blame the compute gold rush, as AI companies increasingly clamor for compute power — ”a compute-powered economy,” as Greg Brockman, president, chairman, and co-founder, OpenAI, puts it. And the numbers surely back it; Stanford’s 2025 AI Index Report says, “training compute doubles every five months.”

While building custom AI chips in-house doesn’t completely alleviate compute pressures, it is one way for OpenAI and its Big Tech brethren to expand compute capacity while potentially lowering costs and reducing reliance on third-party suppliers. 

Exciting claims, no proof

In its announcement blog post, OpenAI describes its new chip as “designed to be the best inference platform for LLMs.”

Specifically, Richard Ho, head of hardware at OpenAI, states: 

“We optimized the architecture around the kernels, memory movement, networking, and serving patterns that matter most for frontier AI models. Based on early testing, Jalapeño will efficiently execute our most important workloads close to the hardware’s theoretical limits.”

But the AI company remains tight-lipped on any real technical details. 

While it claims current tests put Jalapeño’s performance “substantially better than current state-of-the-art,” it doesn’t provide benchmarks to back that up. Instead, it tells developers to expect a detailed technical report “in the coming months.”

What OpenAI does divulge is that engineering samples of the chip are currently running on ML workloads in its lab, including GPT-5.3-Codex-Spark.

Will Jalapeño serve developers, or is OpenAI’s desire to own the AI stack? 

OpenAI makes no qualms about its quest for full-stack control. In doing so, the AI company claims it will make its models “faster, more reliable, and more affordable for users.”

Its logic goes a little something like this: Better infrastructure means more efficient compute, which means better training, which means better models, which means better products, which means more revenue. Then, it explains, it can reinvest that revenue in its infrastructure to make intelligence better for everyone.

But given how little the AI company has revealed about the chip’s specs, it seems developers will have to sit back and watch where the chips fall. 

Jalapeño, then, is simply the next move in OpenAI’s quest to control the whole AI chessboard, moving beyond models and products to the underlying infrastructure itself. 

For developers, OpenAI seems adamant on insisting its full-stack strategy will lead to better performance and pricing for everyone and ultimately empower “anyone trying to learn, create, or solve hard problems.” Still, it’s worth considering: As OpenAI’s grip tightens, will developers become beholden to its ecosystem? 

Several times in its announcement, OpenAI reiterates that it designed Jalapeño for current and future LLMs — all of them. But given how little the AI company has revealed about the chip’s specs, it seems developers will have to sit back and watch where the chips fall. 

Built fast with a long roadmap ahead

The few behind-the-scenes details OpenAI does choose to share boast about its development speed, stating it brought Jalapeño from design to manufacturing tape-out in nine months — “what we believe to be the fastest ASIC development cycle ever achieved in high-performance advanced semiconductors.”

The AI company chalks up that fast timeline, in part, to its own models accelerating parts of the design and optimization processes. 

Looking ahead, Jalapeño is slated for deployment at a gigawatt scale in Microsoft’s and other partners’ data centers by the end of the year. 

That’s just the beginning. OpenAI hints at an upcoming multi-generation roadmap, posing the question: What will it seek to control next? 

The post OpenAI wants to claim more of the AI stack with Jalapeño, its first custom chip appeared first on The New Stack.

This week, Sakana AI released Fugu, a multi-agent orchestration system designed to deliver frontier-model performance all while reducing the risks of relying on a single provider. 

The Japanese AI R&D company says Fugu performs as well as Anthropic’s Fable 5 and Mythos Preview on engineering, scientific, and reasoning benchmarks by breaking up tasks into subtasks and strategically routing them across a swappable pool of expert agents. But early reactions are mixed.

While Sakana positions Fugu’s “collective intelligence” as the blueprint for AI sovereignty, not all users report frontier-model-level performance. Others note fast burn rates and unnecessarily high prices. 

Many agree that, though interesting, Fugu likely won’t be the hero to AI sovereignty it hopes to be. 

Is this just another router? Not really. 

Sakana says Fugu’s internal routing logic is founded on its own research in learned model orchestration, specifically noting two papers, Trinity and the Conductor. 

Unlike multi-model routers, such as OpenRouter Fusion, that send a prompt to multiple models and then compare or combine the results, Fugu breaks down user prompts into subtasks and determines which subtask to send to which model. In this way, Fugu “dynamically orchestrates the world’s best models to tackle complex, multi-step tasks,” so Sakana says. 

From the outside, you just see what looks like one model, accessible via a single OpenAI-compatible API.

But what the AI company doesn’t tell you is how it decides which tasks get routed where; that information is proprietary. From the outside, you just see what looks like one model, accessible via a single OpenAI-compatible API.

“relying on a single company’s model for national infrastructure is a massive risk. As recent export controls have shown, access to top models can disappear overnight.”

Fugu doesn’t have to farm out every task, though. It’s a language model itself, specialized for model selection, delegation, verification, and synthesis internally, so it can also solve requests directly when its own response is sufficient.

A hero for AI sovereignty, it appears not

In an X post, Sakana CEO and co-founder David Ha writes, “relying on a single company’s model for national infrastructure is a massive risk. As recent export controls have shown, access to top models can disappear overnight.”

Human intelligence is fundamentally a collective intelligence. We solve complex problems by participating in a vast cultural network that builds upon ideas across generations.

I believe the strongest AI systems will become a collective intelligence, too.

Since we started Sakana… https://t.co/yulKqdei2c

— hardmaru (@hardmaru) June 22, 2026

That “massive risk” comment is likely a jab at what happened to Anthropic, when an export control directive forced the AI company to pull Fable 5 and Mythos 5 just three days after launch. 

See also: Fable 5 ban: 4 open models responded before Anthropic could restore access

Following this news, Sakana positions Fugu as the antidote to single-provider reliance. Because it relies on a pool of “entirely swappable agents,” the idea is that Fugu is less likely to leave users in a bind if one provider suddenly restricts access. It can simply route work to other models. 

The AI company considers this capability enough license to claim it’s “delivering the realistic, resilient blueprint required for AI sovereignty.” But some initial reactions call that hyperbolic: 

“This is just a highly advanced router/wrapper, not a fundamental leap like Mythos/Fable was,” argues one Redditor.

Though it’s likely not fair to call Fugu a simple multi-model router, its ultimate reliance on other models means it’s not the hero for AI sovereignty it aspires to be. After all, if more than one model provider restricts access at the same time, Fugu’s capabilities also take a hit. 

As another user writes on HackerNews: “As a developer outside the US I think it’s vital to have alternatives to OpenAI and Anthropic, but sadly this is not it,” calling out what they describe as the tool’s unfortunate price-to-burn-rate ratio, an “extremely slow” API, and poor quality in comparison to Fable:

“It’s nowhere remotely near usable as a day-to-day workhorse.”

Not all user reviews back up the benchmarks

Sakana points to coding, reasoning, science, and agent benchmarks to prove Fugu’s value, stating its tool consistently beats Gemini 3.1, Opus 4.8, and GPT 5.5.

It also highlights what it says is the success of its beta program, where almost 500 early users tested Fugu on lengthy, multi-step computational workflows.

In particular, it claims that one cybersecurity engineer confirmed Fugu successfully operated within parameters and avoided destructive actions, while other teams praised Fugu Ultra for besting GPT 5.5 in code review and maintaining an “unusually strong persona stability across long sessions.”

But moving from benchmarks and PR-ready examples to early community sentiment adds more color to the story. 

One user on HackerNews calls Fugu “quite strong” for a few agentic coding tasks, but notes they weren’t able to do many deep reviews before their quota ran out, adding: “For implementation I found it weaker, it made a few mistakes that I haven’t seen frontier models make in a long time.” 

A Redditor had a different experience. They, too, bemoan burn rate issues, but note: “It caught things Opus 4.8 ultra and codex 5.5xhigh clearly missed in a fairly large data ingestion / processing project.”

Some users question the price tag

Furu is generally available today in most regions (save the EU) in two tiers: a low-latency model that integrates with chatbots and tools like Codex for daily tasks and Fugu Ultra, the heavy-hitter that coordinates a deeper pool of experts for more complex, high-stakes tasks. (This is the one that’s supposed to rival Fable 5 and Mythos Preview.)

Subscription plans are available at $20, $100, and $200 monthly rates for both Fugu and Fugu Ultra. Pay-as-you-go pricing is also available, with Fugu billed at standard rates per underlying model, and Fugu Ultra running at $5 per million input tokens and $30 per million output tokens, with higher rates when context exceeds 272k.

Several early users on Reddit and HackerNews deem these price tags too high, especially when they’re experiencing what now feels like the soundtrack of new agent tools: burn rates that get away from you too fast. 

As one HackerNews user jabs: “I love when they put a black box in front of the other black boxes so I can get a questionably better black box for slower service and more money!” 

Is collective intelligence the future? 

On X, HA posits that large-scale, monolithic models have had their time in the sun and that solving more complex real-world challenges will require a different beast: collective intelligence. 

Moving forward, Sakana plans to incorporate new models in its agent pool, which could shore up that resilience Sakana is aiming for. But so far, users seem to question whether paying another company to sit between them and frontier models is really worth the spend.

The post Sakana Fugu is more than a router. But it’s not the blueprint for AI sovereignty, either. appeared first on The New Stack.

Today it was announced SpaceX will buy Anysphere, Inc., maker of AI coding agent Cursor, for $60 billion. 

The news comes a few days after SpaceX’s historic IPO listing, with the rocket and AI company stating in its SEC filing that the Cursor deal will likely close in Q3 2026. 

Developers can now wonder how the AI coding agent might change under the Musk umbrella.

April partnership brings June ownership

SpaceX and Cursor have been flirting about a potential acquisition for a couple of months now. 

Back in April, the pair inked a unique partnership, where Elon Musk’s company agreed to either pay $10 billion to the then-independent startup in a model-training collaboration or opt to buy the whole company later on for $60 billion. 

That day has now come. 

At the time, Cursor described its partnership with SpaceX as a way to accelerate its model training efforts, stating in a brief announcement blog post that Musk’s company would enable the startup to scale up intelligence via xAI’s Colossus infrastructure. 

For its part, SpaceX posted on X back in April that working with Cursor would allow it “to build the world’s most useful models.” 

SpaceX sets its sights on AI coding

It seems SpaceX has been eyeing Cursor’s talent for quite some time.

Even before the April partnership, back in March, Reuters reported that xAI had hired two engineers from Cursor. In fact, Peter Swimm, former principal product manager — Microsoft Copilot Studio, Microsoft, tells The New Stack he expects it’s largely engineering and AI talent that SpaceX hopes to gain from the new acquisition: 

What remains genuinely scarce is elite AI engineering talent and the teams that know how to build these systems at scale.

“The more interesting lens is to view it as an acqui-hire and talent consolidation play. The AI coding assistant market is crowded, features are converging rapidly, and long-term differentiation is proving difficult. What remains genuinely scarce is elite AI engineering talent and the teams that know how to build these systems at scale.” 

SpaceX may very well need that talent. As The New Stack wrote back in April, “SpaceX’s xAI has not had a coding hit since its grok-code-fast-1 model had its time in the sun.”

Though SpaceX’s recent IPO puts its valuation at an eye-watering $2+ trillion, its coding division has not been performing up to par, as Reuters reported in March when several aXI founders left the company. Cursor, meanwhile, rocketed to a $29.3 billion valuation at the end of 2025, scooping up $2.3 billion in Series D funding.

By bringing Cursor into its fold, SpaceX is likely hoping to score more engineering talent and level up its AI coding. 

What does it mean for developers? 

Swimm tells The New Stack he thinks Cursor users can expect better performance from the coding agent, assuming access to SpaceX’s deep resources.

What he says remains to be seen is whether the tool will “maintai[n] broad model support and ecosystem neutrality” or face sweeping changes à la Twitter when Musk morphed the social media company into X:

“For Cursor users, the question isn’t whether the product gets better. With significantly more resources behind it, it probably will. The question is whether it remains an independent platform optimized for developers or becomes another component in a larger corporate strategy.” 

Whoever owns the interface where developers spend eight hours a day gains visibility into how software gets built, which models get adopted, and ultimately where AI spending flows.

If that’s the case, he also predicts procurement evaluations will change, as enterprises may now assess the coding agent as one piece of Mr. Musk’s growing AI puzzle rather than an independent vendor. 

Bigger picture, Swimm says the SpaceX acquisition highlights where real strategic value likely now sits. He doesn’t see AI coding agents, themselves, as the gamechanger but the access they provide into developer workflows: 

“What it [the acquisition] does suggest is that access to developer workflows is becoming strategically valuable. Whoever owns the interface where developers spend eight hours a day gains visibility into how software gets built, which models get adopted, and ultimately where AI spending flows.” 

The post SpaceX acquires Cursor for $60 billion. Can it fix Musk’s coding division? appeared first on The New Stack.

At Microsoft Build on Tuesday in San Francisco, the company debuted Microsoft Scout, a new personal agent for work that uses your existing tools to understand how you work and proactively handle routine tasks. 

What Scout does

Microsoft Scout — available now for all Frontier customers, with more details and a broader rollout to come later — is built on OpenClaw and WorkIQ, the intelligence layer for Microsoft 365 Copilot.

According to Microsoft, the personal agent will work alongside users’ existing toolsets — think Teams, Outlook, and more.

Scout “understands how you work” and can proactively handle jobs, like resolving scheduling conflicts, preparing for meetings, and other routine tasks, without having to be asked. 

The technology company says Scout “understands how you work” and can proactively handle jobs, like resolving scheduling conflicts, preparing for meetings, and other routine tasks, without having to be asked. 

Why now?

In its release, Microsoft says it believes “your agents should reflect how you think and operate,” taking into account the broader scope of your work environment, including workflows, business logic, and institutional knowledge — and notes that this context should extend to always-on, autonomous agents. 

Microsoft Scout is only available to Frontier customers. Microsoft says it will share more information soon as part of a broader roll-out. 

Scout’s debut comes alongside a slew of other announcements from the company as it kicks off its two-day Build conference, including: Microsoft IQ, a new context layer that grounds agents in enterprise and world knowledge, available today across GitHub Copilot, Microsoft Foundry, and Copilot Studio; WebIQ, an AI-first web search stack and what Microsoft calls “the fastest real-world grounding you can give your agents”; plus, a family of seven new in-house models from the Microsoft AI Superintelligence Team, including the company’s first reasoning model, MAI-Thinking-1. 

At Build, Microsoft stressed the changing tides of the new agentic era, noting developers now need “ubiquitous intelligence” and a full stack that supports them from the cloud to the edge. If Scout can understand how teams work and provide proactive support for at least some day-to-day tasks, then it could play a supporting role in helping teams build agentic systems faster. 

The announcement of Scout comes after recent leaks of Google’s Remy, an OpenClaw-style agent the tech giant is rumored to be developing that can perform actions on a user’s behalf. Remy is suspected of serving as a Gemini-powered personal agent. It’s too early to tell whether and how Microsoft Scout compares to the rumored Remy, but the limited information available suggests both companies are moving toward personal agents that go beyond answering questions or summarizing content. 

The post Microsoft debuts “Scout” at Build, a new personal agent for work appeared first on The New Stack.