OpenAI has cut API prices for its GPT-5.6 Terra and Luna models by 20% and 80%, respectively, while also reducing the number of usage credits the models consume in ChatGPT Work and Codex, in an effort to effectively increase the amount of AI work enterprise subscribers can perform without paying more.

“Starting July 30, API pricing is $2 per million input tokens and $12 per million output tokens for Terra, and $0.20 per million input tokens and $1.20 per million output tokens for Luna,” the company wrote in a blog post.

Prior to this update, enterprise customers paid $2.50 per million input tokens and $15 per million output tokens for GPT-5.6 Terra. For Luna, pricing stood at $1 per million input tokens and $6 per million output tokens.

These lower prices and effective reduction in credit consumption, OpenAI said, are the result of improvements in serving efficiency that allow it to deliver “more intelligence per dollar” for its most advanced family of AI models.

The efficiency gains, the company added, stem from optimizations across its AI training and inference stack, including software and GPU infrastructure, with GPT-5.6 Sol helping optimize production GPU kernels used to run AI workloads and reduce inference costs without compromising model performance.

Enterprises likely to spend differently, not less

Analysts say the price cuts are less about reducing enterprise AI spending and more about lowering the cost of deploying AI at scale.

“For CIOs, the biggest impact is likely to be scaling AI adoption rather than simply cutting costs or lowering AI budgets. Lower prices make it easier to move pilots into production, expand AI across more employees and business processes, and economically deploy more complex agentic workflows that require multiple model calls,” said Pareekh Jain, principal analyst at Pareekh Consulting.

“Instead of shrinking AI budgets, most enterprises will reinvest the savings into higher AI usage, allowing agents to perform more reasoning, automation, and multi-step workflows while delivering more business value for roughly the same spend,” Jain noted, saying the likely outcome reflects the Jevons paradox, the economic principle that efficiency improvements often increase overall consumption of a resource rather than reducing it.

Echoing Jain’s view, Chandrika Dutt, research director at Avasant, pointed out that enterprise teams are likely to use the leeway from the pricing change to build increasingly sophisticated agentic workflows that were previously difficult to justify economically.

CIOs need flexible AI architectures to benefit

More broadly, CIOs should view OpenAI’s pricing update as yet another sign that inference costs are likely to keep falling over the next 24 months across model providers, such as Anthropic, Google, and Microsoft, with a sharp increase being unlikely.

“These price decreases are broadly sustainable in the long run. New chips, better software, and more efficient model designs will keep driving down the cost per token, and heavy competition makes big price hikes risky for any single provider and thus unlikely,” Jain pointed out.

For enterprises and their leaders, that should mean designing AI strategies that prioritize AI FinOps and flexible architectures so models can be swapped as price-performance continues to improve across vendors, Jain added.

The larger and more advanced model in the GPT-5.6 family, named Sol, though, is not undergoing any pricing changes. Instead, OpenAI has introduced a new Fast mode for the model, replacing Priority Processing in the API. Existing API requests tagged “priority,” though, will continue to work, it added.

KotlinLLM, a research prototype for delegating runtime logic to a large language model (LLM) from Kotlin code, is now going open source and public, JetBrains announced.

Revealed July 28, KotlinLLM is an IntelliJ IDEA plugin prototype for experimenting with LLM-driven “Smart macros” in Kotlin, enabling code generation, runtime updates, and hot-reloading. In software engineering, LLMs are commonly used during development for code completion, code generation, and program comprehension, JetBrains noted, but using an LLM at run time of a compiled application is much less common. The existing options for doing this have the following trade-offs, according to JetBrains:

• Direct runtime delegation is slow, non-deterministic, and costly, and makes the application depend on an LLM service at run time.
• External agent workflows keep the generated logic outside the codebase, where it is harder to review, test, and ship.
• Most prior work (byLLM, nightjar, Healer) targets interpreted languages like Python, not a compiled, statically typed language like Kotlin.

KotlinLLM addresses these limitations in three ways, JetBrains said:

• The call site shows that a feature is LLM-backed, so it is visible in code review.
• Generated behavior is saved as an ordinary Kotlin source, not kept only in the runtime session. It can be committed, reviewed, tested, and distributed like any other code.
• Once generated, the code runs as plain Kotlin without the plugin. For scenarios that are already covered, there is no further LLM call, so no added latency or cost, and the result is reproducible.

KotlinLLM is open source under Apache License 2.0. The repository contains the KotlinLLM IntelliJ IDEA plugin, the Smart macro API, and example projects.

One percent of AI-active developers now generate 46 times more AI-written lines of code per day than the median active user, according to the Cursor Developer Habits Report. The bottleneck is no longer writing software. It is understanding what happens after that software ships.

Every new service, dependency, feature flag, generated abstraction, and deployment path increases the number of ways a production system can fail. AI has compressed the time it takes to create that complexity. It has not compressed the time it takes to understand it.

The result is a production environment that changes faster than engineers can rebuild a mental model of it. AI can help in this situation because most debugging practices were designed for a slower world.

Debugging yesterday and today

For decades, debugging was largely a spatial problem. A failure in Service A belonged to the team that owned Service A. They knew the deployment history, the operational quirks, the useful log queries, and the odd behaviors that never made it into the runbook. Incident response reflected that assumption. Teams owned services. Runbooks were scoped to those services. On-call rotations mirrored organizational boundaries.

That model still works when failures stay local. If a deployment introduces a memory leak, or a bad configuration causes a service to crash, the symptom and the cause usually live in the same place. The owning team can investigate, identify the issue, and restore service. Those incidents are becoming a smaller share of production failures.

AI-generated code is not inherently less reliable than human-written code. The change is volume and speed. Teams can now introduce more code, touch more systems at once, and evolve architectures faster than before. As systems become more interconnected, failures increasingly surface somewhere other than where they start.

A single-hop incident is local. The service experiencing the failure is also the service causing it. Investigation stays inside one team’s boundary.

A multi-hop incident looks different. The checkout API begins timing out. Nothing appears wrong inside checkout. Latency is normal. Error rates are low. The actual problem is a queue consumer silently dropping messages because a schema change deployed two days earlier was only partially backward compatible. The queue team sees healthy throughput. The data platform team never receives a page because nothing in its service violates an alert threshold. Every team is right about its own system, yet nobody can explain why customers cannot complete purchases.

The problem is not a lack of evidence. Modern production systems produce more telemetry than any human can use during an incident. The problem is knowing which evidence matters, which signals are coincidental, and how separate clues connect into a causal chain.

The role of AI in production ops

That changes the role AI should play. AI should not be treated as a magic on-call engineer. A frontier model does not know your architecture. It does not remember prior incidents. It does not know which dashboards lie, which services fail together, what changed last week, or which dependencies matter most. On its own, it reasons inside a vacuum.

The useful version of AI in production is more specific. It can assemble context, test hypotheses, trace dependencies, compare the current incident against past incidents, and rule out explanations that do not fit the timing or blast radius. It can do the work that currently eats the first 20 minutes of an incident: gathering evidence, checking recent changes, mapping dependencies, and narrowing the search space.

Humans still make the decisions that require judgment. They decide whether the evidence is strong enough to act, whether a rollback is worth the risk, whether to wake another team, and whether the safest move is mitigation or deeper investigation. But they should not have to spend half the incident reconstructing a system the organization already operates.

That is the larger productivity shift.

If AI can absorb more of the troubleshooting tax, engineers can focus on the work that actually compounds. They can simplify fragile architectures. They can improve instrumentation in the places where incidents repeatedly go dark. They can design safer degradation paths, sharper alerts, better rollback patterns, and evals that catch semantic failures before customers do. They can feed production knowledge back into development, so code assistants and review processes understand which services are risky, which patterns have caused outages, and which dependencies deserve extra scrutiny.

This is the work engineers rarely get enough time to do because they are stuck resolving the same classes of incidents again and again.

Letting the engineers engineer

The goal is not to remove engineers from production. The goal is to stop wasting their judgment on work the system should already be doing. AI should make incidents shorter, but that is only the first-order benefit. The larger benefit is giving senior engineers more time to prevent future incidents instead of being pulled into every confusing one.

As AI accelerates software creation, production operations need the same kind of acceleration on the other side. Not just faster debugging. Better allocation of human attention.

The AI code avalanche will not be managed by asking engineers to troubleshoot forever at machine speed. It will be managed by making production systems more legible, more resilient, and less dependent on whichever expert happens to be awake.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

AI agents are being connected to real systems faster than most organizations are learning how to secure them. That should concern us.

The first wave of AI security discussion has been useful, but limited. The industry has learned the vocabulary: prompt injection, indirect prompt injection, tool misuse, data leakage, excessive agency, unsafe retrieval, and broken authorization boundaries. These terms are important because they give teams a way to talk about risk. 

But vocabulary is not containment.

The harder problem is what happens after a dangerous behavior is discovered. A team may adjust a prompt, restrict a tool, add a guardrail, or change the surrounding application logic. That may solve the immediate issue. What it does not automatically solve is the next release, the next model change, the next tool integration, or the next developer who unknowingly breaks the assumption behind the original fix.

This is where AI agent security still feels immature. In traditional software engineering, serious bugs become regression tests. The lesson is captured in code so the same failure cannot quietly return later. Security should work the same way. Agentic systems need a way to preserve discovered failures as repeatable checks.

That is the gap the OWASP Agent Security Regression Harness is trying to address. As a community-led open-source initiative within OWASP, this project aims to turn security insights into practical engineering work.

Agent security is becoming a systems problem

A chatbot can give a bad answer. An agent can take a bad action. That difference changes the security model.

Once an AI system can call tools, inspect repositories, query databases, open tickets, summarize internal documents, interact with APIs, or trigger workflow automation, the boundary is no longer just the model. The boundary includes permissions, tool design, application logic, data flow, logging, authorization, and the assumptions developers made when they connected everything together.

The risk is not limited to strange model behavior; the risk is system behavior. An agent that reads untrusted content and treats it as instruction is not merely confused—it has crossed a trust boundary. An agent that leaks private context through a tool call is not just producing a bad response; it is exposing data through an action path. These are the kinds of failures teams will face as agents move from prototypes into production.

The security industry has seen this pattern before. Cloud platforms and CI/CD pipelines increased leverage, making teams faster but making configuration errors more consequential. Agentic AI is another increase in leverage. That is why a one-time review is insufficient. Regression testing exists for exactly this kind of problem.

The missing workflow in agentic AI

Security teams do not need another reminder that AI agents can be manipulated. They need a workflow that turns manipulation into evidence. A hidden instruction inside a support ticket should not remain a warning; it should become a scenario that can be rerun. A tool call that leaks context should become a check with a clear failure condition.

The value lies not only in finding the first failure, but also in preserving the lesson. Production incidents become postmortems, serious bugs become tests, and security findings become backlog items. AI agent security should not be exempt from that discipline simply because the system includes a model.

The challenge is that agents are harder to test than traditional code. A brittle test that expects one exact sentence will fail in real-world conditions. Useful agent security tests must focus on outcomes. Did the agent cross a boundary? Did the agent call an unsafe tool? Did it disclose protected data? The OWASP Agent Security Regression Harness provides a standardized way to work on these questions in the open, focusing on practical, reproducible tests.

Why OWASP matters for AI

OWASP is valuable when it turns security problems into shared practice. The OWASP Top 10 did not eliminate web application vulnerabilities; its value was giving teams a common language and a practical reference point. AI agent security now needs the same kind of shared structure.

The field is moving quickly, and fast-moving fields tend to produce two unhelpful extremes: one side turns everything into hype, while the other turns everything into fear. A regression harness is a more useful answer because it is narrow and practical. It does not claim to solve every AI security problem, nor does it replace threat modeling or architecture review. It simply provides a necessary method for teams to prove that their controls hold after the system changes.

OWASP project stewardship

Open-source security projects need clear technical direction to turn a broad concern into something engineers can understand, run, and maintain. Under the leadership of OWASP Project Lead Mert Satilmaz, the OWASP Agent Security Regression Harnesshas moved past a theoretical idea into a functional tool. Satilmaz is a widely known leader in the AI security community, and this is reflected in the practical direction he has set for the project and the engineering skill involved.

The project benefits from a focus on release discipline, contributor workflows, and wide adapter coverage—supporting everything from the OpenAI Agents SDK to LangChain/LangGraph. By generating machine-readable results, it allows security teams to integrate these checks directly into CI pipelines. This approach treats agent security as a systems engineering problem rather than just a model behavior problem.

The method is the contribution

One OWASP project will not solve agent security by itself. That is not the point. The important part is the method the project represents.

AI security needs to become less dependent on warnings, one-off demonstrations, and claims that are difficult to verify. It needs more repeatable scenarios, clearer evidence, and better ways to test system behavior under security constraints. Teams should not be satisfied with saying a weakness was fixed. They should be able to prove the relevant control still holds after the system changes.

The best security work often looks boring from a distance: a harness, a test case, a clean project structure, and a workflow that lets another engineer reproduce the problem. AI agents will continue to become more capable and more connected to sensitive systems. Security teams need methods that are as practical as the technology is powerful. Regression testing is one of those methods, and adopting this workflow is an important step toward making secure AI a reality.

Microsoft has released MCP C# SDK v2.0, a major update of the company’s official C# SDK for Model Context Protocol (MCP) servers and clients.

Unveiled July 28, MCP C# SDK v2.0 implements the 2026-07-28 revision of the MCP specification, which Microsoft described as the protocol’s largest revision since its launch. The 2026-07-28 revision makes the MCP protocol stateless by default, standardizes the HTTP surface to allow ordinary HTTP infrastructure to route MCP traffic, and introduces Multi Round-Trip Requests (MRTR) to support interaction without requiring long-lived sessions.

MCP C# SDK 2.0 moves in lockstep with these changes, Microsoft said. The HTTP server transport now runs statelessly by default. Whereas version 1.x of the SDK configured stateful sessions out of the box, in version 2.0 HttpServerTransportOptions.Stateless defaults to true.

MCP C# SDK v2.0 also implements a small set of HTTP headers that the 2026-07-28 MCP revision standardizes. A tools/call now includes Mcp-Method: tools/call and Mcp-Name: get_order_status alongside the JSON-RPC body. With the 2026-07-28 revision, an MCP request becomes a single, self-describing HTTP POST. This means that ordinary HTTP infrastructure such as load balancers, proxies, gateways, and web application firewalls now can act on MCP traffic without deep packet inspection, Microsoft said.

And MCP C# SDK 2.0 adds support for MRTR on the server and on the client. MRTR addresses scenarios in which tools can’t answer in a single round trip, such as when a server wants to confirm with a user before taking a significant action. In previous versions of MCP, these interactions worked only over a live, stateful session. With MRTR, they work with no session at all, because all the continuity travels in the payload, Microsoft said.

With the 2026-07-28 spec compliance landing in MCP C# SDK 2.0, Microsoft said the SDK’s next focus is end-to-end authentication and authorization. The goal is to make secure MCP deployments as “turnkey” as the rest of the stack, building on the closer OAuth and OpenID Connect alignment the spec introduced, Microsoft said. 

OpenAI’s renegade AI agent, which carried out a high-profile breach of the AI platform Hugging Face, also reportedly compromised a customer of the cloud platform Modal Labs, according to Reuters.

The agent is said to have exploited a vulnerability in the customer’s own code, where an unprotected endpoint allowed anyone to run code in an isolated test environment.

Modal Labs emphasized that its own infrastructure was not compromised and that the security isolation worked as intended.

OpenAI declined to comment on the Modal case, but referred to a recent update in which the company confirmed that the tested AI agent managed to gain access to four accounts across four separate services. The company has not named the services.

When Nvidia CEO Jensen Huang speaks, the tech industry listens. He used his first-ever post on X last week to argue that open AI models “strengthen safety and cybersecurity, accelerate innovation and diffusion, and enable sovereignty.”

Nvidia is a chip company (with a focus on GPUs). But it also has its own AI models that include Nemotron, an open-weight model that’s free to download and modify. The company is also pushing for open AI technologies and security through the Nemotron Coalition  and the newly launched Open Secure AI Alliance. 

With Huang’s recent comments in mind, Computerworld sat down with Kari Briski, Nvidia’s vice president of generative AI (genAI) software, to find out more about open models and why they matter for enterprise and sovereign applications.

Nvidia

What do open models really give enterprises and countries? “Open models allow enterprises and countries to own, inspect, and adapt models with their own data. The learning rate of adoption differs by region and enterprise, so there are different pockets of acceleration, but all the models have made tremendous progress closing the gap. What’s interesting about Nemotron is that we also publish our data, and that opened up a new world of engagement. 

“Enterprises reached out, saying, ‘Thank you, but I want to understand why you put this set of data out.’ That got them in the mindset that they could curate, create, capture, and control their own data.”

When you develop these open models, do you have CIOs in mind, or sovereign uses? Where does the rubber hit the road? “Both. At the highest level, it’s very much the same: use cases, data sets, outcomes you want to achieve. It used to be question and answer, now it’s agentic workloads, getting stuff done, calling tools. To get a task done, which tool do you call? That’s different for every enterprise and every local region, which is why we match local models to local ecosystems, with post-training on those local models. 

“One enterprise can have 2,000 tools; a local region, 2,000 regional tools. [They’re] fundamentally the same, but with different go-to-market motions: reinforcement learning environments, synthetic data generation, or anonymizing and differential privacy for healthcare and banking data.”

Why does Nvidia put its models out in the open? What do you get out of it? “We’re building Nemotron first and foremost for ourselves, to understand our systems running at scale — not just for training but also for inference, which allows us to iterate on things like model architecture for token efficiency. We believe in a thriving ecosystem. When you put a model out into the open, you get more startups, more builders, lower entry barriers.”

What’s the connection between open models and sovereign AI? “To be very honest, it’s about bootstrapping a region that otherwise didn’t have the compute to get to a base-level model. Centers of excellence historically lived in higher education or research, and in certain pockets of the world, getting onto a compute cluster was grant-based: get on, get off, then find another grant. That start-stop, not being able to constantly iterate, is difficult. It’s the scaling laws of AI: the more compute, the more intelligence; the more access, the faster you can drive them. Open models and open data are that bootstrap. You don’t have to recreate capturing the knowledge of the internet as a pre-training model.”

Regionally, things are different. Voice and word of mouth are big in South Asia, chatbots less so. What’s the approach going forward? Is it an SLM approach? “You’re going to hate my answer: it depends. Language is ever evolving. Go back to first principles: AI is infrastructure. Not just the model, but the harness, the skills, the runtime. All of this is a new computing platform, and when we deploy it, it’s how can it understand and adapt. We’re at the tip of the iceberg integrating AI into everyday applications. The more it can understand and update even dialects, the better. 

“Understanding those niche areas is what drives the data flywheel of deploying AI. It won’t be overnight. That’s why this is a new industrial revolution. We have to lay the infrastructure everywhere for these models to update. And to your point, it could be a large teacher model that at the edge is an SLM. It depends.”

AI companies in Nepal told me, “We can’t innovate because we don’t have access to a GPU.” They want a model that runs on the hardware they have. Is that the way you look at it? “If you know Nvidia, it’s all about the ecosystem, and we want to enable developers. This is why we have many different sizes: Nano, Super, and Ultra of the Nemotron family, not just for where you deploy, but for developers to iterate on smaller GPUs, then scale to a more robust model like Ultra.

“We run as a model-as-a-service across the cloud providers. Day zero, they all had it ready to go, along with our inference partners, optimized and efficient for their workload. We don’t pitch the checkpoint over the wall; we help them take it that last mile, and partners get early access, so on release day it’s available on whatever platforms they use.”

The industry works together on open technology like Linux. Can you partner on models, and is the focus on performance or quality? “On performance versus quality, it’s both. You can’t have a high-quality model that is slow or heavy, and you can’t have a fast model that sucks. We’re going after three dimensions: efficient, state-of-the-art, and open. And models do work together today — a planning agent routes a question to the best model to complete the task.

“On partnering, that’s our goal in true open source and in the Nemotron Coalition, bringing the best and brightest minds with the commitment to open source and collaboration. Members contribute in different ways: pre-training new architectures, post-training RL environments, contributing data. The goal is everybody working together on one model. That’s why the coalition matters for model architecture —  token efficiency, latent mixture of experts, changing how we route it. These are new architectures we’re thinking about. We need these ideas coming in from others.”

Is the latest open-source model always the best? In developing countries, some go back to older models they’ve tested enough to predict the responses. “Models aside, that’s true for any software. You do an upgrade and it’s just not working the way it worked before. The results aren’t better. When you build a system around it with certain prompts, a model might not react the way it used to. This is why we built the coalition, why we work with a very close set of partners. We pull their evaluation benchmarks in-house to make sure we’re not regressing, only improving. 

“You have to switch your mind with AI and the way you test it. Is the latest model necessarily the best? I’m going to say yes. Companies and countries need the skills to quickly evaluate, update prompts, and adopt new models.”

Can I fork an Nvidia model, put it on Hugging Face, and do what I want with it? Do you take lessons from the forks and benchmarks? “We have a very open license. We put out reduced precision NVFP4 checkpoints. Those are the most popular, especially with Ultra, because people want the smallest footprint to run that robust model. Even with mature models, there’s all kinds of quantization happening and getting posted back, and I love that community engagement. I love seeing different forks of our models. We track those, too, which gives us an idea of what matters to people. That’s the purpose of putting it out in the open: to see how they change it, how they need to adapt it, then put it back out for the rest of the world to enjoy.

“Benchmarks are table stakes, not the ceiling of where we need to go, so we’re always looking for new benchmarks and new workloads. In the last 90 days, the style of workload changed dramatically, going from question-answer pairs to agentic workloads, and those workloads mattered to make sure we were tracing our model, which led to us being able to fully trace it. We want to show that you can be just as intelligent in a short amount of time, compute efficient, token efficient.”

I’m an old Borland guy. I started using Borland tools in the early 1990s, from Turbo Pascal through Delphi. I dabbled in Paradox. I even tried to stick with Borland Office. I wandered through the Inprise years, and the Kylix endeavor, and I was actually a Borland employee during the CodeGear/Embarcadero migrations. 

You could write a book about the rise and fall of Borland. Suffice it to say that things got dodgy when Borland strayed from its focus on developer tools, and they never really recovered.  

One of Borland’s missteps came with the open-sourcing of InterBase, its RDBMS. In the early 2000s, open-source software emerged from the academic shadows and began to commercialize. With the IPO of Red Hat, everyone was jumping on the Linux and open-source bandwagon. Borland made their move into this arena with InterBase. 

Two things soon happened. First, the Firebird project was created as a fork of the InterBase source. Second, Borland retreated from the open-source project and reincorporated InterBase as a closed-source product. One might mark this as the beginning of developers losing faith in Borland.

It was developers, then

And it always ends up being about the developers, right? I mean, who can forget a sweaty, maniacal Steve Ballmer jumping around onstage screaming “Developers, developers, developers”? For many years, Microsoft was notoriously anti-open-source, but even they eventually recognized the power of open-sourcing major tools like .NET and Visual Studio Code. 

But Microsoft didn’t do that out of the goodness of their heart — they clearly saw those tools as a means to bringing developers to their Azure cloud platform. When Amazon launched AWS, they clearly were sidestepping the IT procurement process, making it easy for developers to spin up VMs with just a credit card. Apple shipped the iPhone without an SDK, expecting developers to figure things out.  That didn’t last long, and they soon course-corrected.

Open source is great — but always remember that it offers benefits to companies beyond the software development process. Borland fumbled the ball with their open source efforts, but it soon became obvious how to leverage open source for corporate success. Or, as Stephen O’Grady argues in his book The New Kingmakers, developers are the ones who decide what technologies succeed. Companies quickly recognized that courting developers with open-source software and other free resources was the way to bring them into the fold. Because developers write all the software that makes a tool, platform, or application successful, it’s always a smart move to make developers happy.

It’s developers, now

AI hasn’t changed this equation. The latest incarnation can be seen from the company Nvidia. We think of Nvidia as a hardware company, cranking out GPUs as fast as they can. But GPUs don’t sell unless there is software that runs on them. Coding against a GPU in plain C++ was miserable, so Nvidia developed CUDA, a proprietary layer that made building for their hardware relatively easy. And the more CUDA is used, the more people depend on Nvidia hardware. This is not an accident. As Nader Khalil, Nvidia’s Director of Developer Technologies, told me, “You have to make the best hardware that you can, and you have to make the best software to utilize it. Software is the part of the stack that touches the user.”

Today, of course, developers are all about agentic coding, and Nvidia is eyeball deep in that world. As such, Nvidia provides a set of open-weight models called Nemotron that developers can use, inspect, and fine-tune for their own purposes. And of course Nemotron runs really well on top of CUDA. 

Nvidia, like Microsoft and Amazon, is doing this because they want to sell their products to more people. Nvidia can’t make enough GPUs for Anthropic and OpenAI to keep up with demand, but they also want to sell GPUs to us developers by enabling us to run our own models on our own computers. 

The open source movement began with pure hearts and noble ideals. But the reality of open source is that its nobility is easily melded with business needs. Open source software is really the bait — and developers are the real catch.

The 19^th-century French novelist Honore de Balzac is believed to have said that behind every great fortune lies a great crime.

That’s even more true today than it was 200 years ago — just look at how Big AI, including Anthropic, OpenAI, Google, and others have built their trillion-dollar fortunes. 

They all use vast amounts of copyrighted material to train their large language models (LLMs) without paying the copyright holders. In other words, they steal it. They don’t call it stealing, though. They call it “fair use,” which in this case amounts to the same thing.

Generative AI (genAI) training requires massive amounts of text. The better-written and more information-dense that text is, the more it helps. AI gets a lot smarter a lot faster when it’s trained on well-written books and magazine and newspaper articles than when it’s trained on social media banter (or most everything else you find on the internet).

Since the dawn of AI, companies have been hoovering up copyrighted material wherever they find it — on the open web, behind paywalls, even in manually scanned books — and then used the scanned text. And they do it all without asking authors’ or publishers’ permissions, and without paying them.

It’s the greatest intellectual property theft in history by a long shot — billions and billions of dollars worth. Books, articles, music, photographs, artwork, you name it. If a human being has created it, Big AI has likely grabbed it and ingested it without asking, then made big profits off it.

I know this from personal experience; I’ve got skin in the game. Big AI companies have used at least 30 of my books to train their models without asking.  And that’s only what I’ve confirmed. Big AI might well have stolen even more. And it also might have stolen many of the thousands of articles I’ve written through the years.

For the AI bigwigs, it’s standard operating procedure. So it was surprising to see Microsoft CEO Satya Nadella calling out Big AI for its hypocrisy in using other people’s intellectual property without paying, then crying foul when small AI companies use Big AI’s work to train their own models using a technique called distillation.

He wrote on X: “While the great innovation that comes from model providers having fair use rights to train models on public data is needed, I find it ironic that the status quo is to then turn around and impose restrictive terms on distillation, and to reserve the right to learn from customer usage and interaction data.” 

One important note here: Nadella believes Big AI should be allowed to steal copyrighted material for training purposes. He makes that clear by his mention of “fair use.” His issue is that he believes smaller AI companies should be able to use Big AI’s work to train their models — and Big AI doesn’t want to let them do it.

Alistar Barr, in Business Insider, makes a related point: “Anthropic, OpenAI, and Google are discovering what the rest of the internet has already learned through painful experience: once you put something online, people will find ways to use it in ways you don’t like and can’t stop.” 

Before we look at whether Nadella is right in calling Big AI’s actions hypocritical, let’s examine the technique at the heart of the issue: distillation.

The lowdown on distillation

Distillation refers to an AI training technique in which you take outputs from one AI model, such as the answer to a prompt, and use that output to train your own model. AI companies do that quite frequently and have been doing so for a long time.

Barr explains distillation this way: “Distillation looks an awful lot like what AI companies have been doing to the rest of the internet. Scrape web content for free and without permission. Turn it into a product you sell. Argue it’s fair use. Hope the lawyers sort out the details later.”

Elon Musk has admitted his company xAI used distillation techniques to take output from competitor OpenAI to train xAI’s Grok chatbot. He explained, “Generally AI companies distill other AI companies.”

Analysts point out the AI industry is built on distillation. Neil Shah, vice president of research at Counterpoint Research says, “The reality is none of the models is an island and the entire industry has mostly evolved based on recursive learning. The newer entrants are in many instances going through the same routes of ‘distillation’ and ‘optimization.’”

It’s only become an issue now because Chinese AI companies have been using distillation techniques to catch up to American AI companies.

OpenAI CEO Sam Altman has been pressuring the US to take legal action against the Chinese companies.  Anthropic has piled on as well, saying the fight against distillation requires a coordinated response across the AI industry, cloud providers, and policymakers.

Hypocrisy or fair use?

So are OpenAI, Anthropic and other big US AI firms hypocritical, as Nadella claims? Absolutely. They’ve built their businesses on the theft of billions of dollars of stolen intellectual property and call it fair use. Now, they’re playing the victims when competitors do the same to them. (They’re also in some cases paying up; Anthropic just last week settled a copyright suit, paying out $1.5 billion.)

It’s good to see Nadella call out their hypocrisy. But Microsoft is as guilty of intellectual theft as the others — its AI Copilot is powered by OpenAI’s and Anthropic’s chatbots. The company faces major lawsuits for intellectual property theft. Among them is one by the New York Times, New York Daily News, and Center for Investigating Reporting, another by 400 local and regional newspapers, and another by 11 authors, including Pulitzer Prize winners Kai Bird, Jia Tolentino, and Daniel Okrent.

So, don’t praise Nadella for speaking out. Criticize him (and other AI tech leaders) for stealing billions of dollars in intellectual property from countless writers and publishers and calling it fair use.

For years, the public cloud was the default for new workloads because its convenience, elasticity, and breadth of services made sense. However, as AI’s strategic importance grows, its economics and infrastructure are changing. Tesla is one of the clearest examples of a company deciding that AI is too important, too expensive, and too central to its business to leave largely in the hands of a third-party cloud provider.

 At the center of Tesla’s strategy is a simple idea. If AI is key to how you build your products, run your business, and define your future, the infrastructure that powers AI becomes a strategic asset. It is no longer just plumbing but part of the product itself. Tesla’s models, databases, applications, and workflows increasingly rely on infrastructure that is built, hosted, and managed by Tesla. That means the company has direct control over the hardware, the software stack, data movement, performance tuning, and security posture. For a company that depends on AI to support autonomy, robotics, manufacturing intelligence, and future product direction, that control matters.

This is the real heart of the matter. Tesla is not treating AI as a side project or a feature layer added on top of an existing business. AI is central to Tesla now and into the future. It is a force multiplier, but more than that, it is an essential aspect of product development, operational efficiency, automation, and competitive differentiation. Once a company reaches that level of dependence on AI, the conversation around infrastructure changes very quickly.

Public cloud is attractive because it provides a complete AI ecosystem on demand. You can provision compute, storage, training environments, managed services, orchestration tools, and deployment pipelines without building much yourself. That is why I often call public cloud “the easy button” for AI. It is fast, convenient, and feature-rich. But convenience comes with a premium, and for many companies moving deeply into AI, that premium is becoming very hard to justify.

Cost is driving AI out of the cloud

One of the biggest forces driving this shift is price. Many enterprises moving into AI are shocked by what public cloud providers charge for AI infrastructure. Training clusters, inference engines, storage, networking, observability, and support services all add up quickly. What begins as a convenient path to experimentation can become an extremely expensive operating model when AI moves into production at scale.

In my experience during the past 15 years, public cloud is often at least twice as expensive as comparable private infrastructure for sustained workloads. That is not true in every case, and it depends heavily on utilization patterns, architecture, and operational maturity. However, for large, predictable, always-on AI workloads, public cloud economics often become difficult to defend. The markup associated with convenience, elasticity, and managed ecosystems is substantial.

In response, companies are increasingly exploring alternatives. Some are moving toward neoclouds that specialize in AI infrastructure. Others are evaluating sovereign cloud options for control, locality, or compliance reasons. Many are revisiting private cloud infrastructure for the most strategic and cost-intensive workloads. Tesla is becoming the poster child for how successful that approach can be when a company has the scale, the sophistication, and the long-term commitment to execute it well.

Control, governance, and security

Cost is only one part of the equation. Control is the other major driver. When Tesla runs its AI infrastructure on equipment it owns and operates, it gains much tighter control over performance, data handling, workload placement, governance models, and operational priorities. That matters a great deal when the workloads involved are mission-critical and directly connected to the future of the company.

A privately controlled AI environment can provide better security because the organization has direct oversight of the infrastructure stack. It can provide better governance because data, models, and workflows remain inside systems the enterprise fully controls. It can also improve reliability and performance tuning because engineering teams can optimize specifically for their own AI pipelines rather than adapting to the generalized patterns of a shared cloud environment.

Of course, many people are quick to point out that running your own private infrastructure comes with significant labor and cost. They are not wrong. Building and operating private AI infrastructure requires capital, engineering skill, facilities, procurement discipline, operational excellence, and long-term commitment. This is not a shortcut, nor is it easier than public cloud. In many ways, it is harder.

However, the point is that for sophisticated companies with large-scale, steady-state AI needs, it can be worth it. Better control, better governance, better security, and ultimately lower cost can justify the additional operational burden.

The future of AI infrastructure

What makes Tesla so important in this discussion is that the company chose this route because AI is inseparable from its business strategy. Many other enterprises are heading in this same direction. As AI becomes less experimental and more operational, the infrastructure conversation shifts from convenience to economics, control, and differentiation.

Not every company should follow Tesla’s path. Many enterprises are not ready to build, host, and manage their own AI environments. Many lack the scale to justify it. Many still benefit tremendously from the agility of public cloud. But for organizations where AI is becoming central to products, services, and competitive advantage, Tesla’s strategy is increasingly relevant.

There are three things every enterprise should think about when considering ownership of its own AI infrastructure:

• First, understand the operational burden in full. Private AI infrastructure requires teams, processes, facilities, and discipline that many organizations underestimate.
• Second, know the economics of your workload patterns. If AI demand is large, steady, and strategic, the cost advantages of ownership may be compelling.
• Third, think beyond cost alone and focus on control. If AI is core to your future, owning the infrastructure may offer strategic benefits in governance, security, optimization, and long-term independence that public cloud cannot easily match.

Tesla’s strategy is not for everyone, but it is a persuasive example of what happens when a company decides that AI is too important to rent forever. Public cloud remains the easy button, and for many organizations, that will be enough. But for companies that see AI as fundamental to how they will compete, private infrastructure may turn out to be the smarter choice.