Over the past two or three years, most fast-growing AI SaaS products, except for the few that train their own models, have shared a business model that can be summarized in one blunt phrase: wrappers. They wrap OpenAI/Anthropic API calls inside a vertical workflow, add a layer of markup, and sell it to users as a subscription.

Users see “AI copywriting tool for $59/month,” “AI customer support at $0.99 per resolution,” or “AI note-taking tool for $20/month.” But behind many of these products, what actually happens is simple: the product takes the user’s input, appends it to a prompt, calls a model, and places the output inside an interface that looks more like software.

This is not a sin. SaaS has always made money by hiding complexity. Users do not want to handle API keys, understand tokens, think about rate limits, context windows, retry logic, or prompt/context/harness engineering. They just want to finish a task. AI SaaS packages the annoying parts, and users pay for convenience. A perfectly normal value exchange.

But this model depends on one premise: users cannot see the model bill, and they do not have their own model quota.

That premise is breaking.

AI model vendors like OpenAI/Anthropic are turning high-capacity token plans into subscription products for individuals and enterprises. Agent runtimes like Codex/Claude Code are also moving beyond developer tooling into broader knowledge work. At the same time, more new products are starting to let users bring their own Codex/Claude Code subscription quota, instead of using the SaaS product’s own included credits.

Users will start asking two questions:

If Codex/Claude Code can already call a SaaS product’s tools and data through MCP, why do I still need to open the SaaS interface to get work done?

If I already bought a high-capacity Claude Code/Codex subscription, why should I pay another AI SaaS for included credits again?

The first question will restructure the user entry point for AI SaaS. The second will restructure its gross margin.

From BYOK to BYOT

People used to talk about BYOK, Bring Your Own Key. The idea was that users would paste their own OpenAI API key or Anthropic API key into a third-party app, pay the model cost themselves, and the SaaS would only charge for the software.

This model never became widespread because normal users do not care about API keys. They do not know where to create them, how to set budgets, or how to read the rate limits and prices of each model. Asking a normal user to use an API key inside a product is like asking someone who just wants to drive to first understand how an engine works. What they actually want is to get from one place to another.

For AI SaaS companies, refusing to support BYOK is not only a UX issue. BYOK separates model cost from product value. It lets users immediately see what they are actually paying for. If the product’s main value is calling a model, BYOK exposes the pricing on the spot.

So many AI SaaS products preferred selling included usage. Users did not need to understand model cost, and companies could mix inference cost and product value into one subscription price. As long as users felt the product saved them trouble, the math worked.

But BYOT is different.

Now, the subscriptions OpenAI/Anthropic sell to individuals and enterprises are moving from usage quotas inside chat products into token entitlements that can be called by Codex, Claude Code, Agent SDKs, and third-party agent runtimes.

Users can use methods like Sign in with ChatGPT and Claude OAuth to use their existing model subscription quota inside third-party products. Previously, users could only use these AI capabilities inside the official ChatGPT and Claude interfaces. Now, these quotas are being brought into more tools, editors, workflows, and agent-native products.

This change improves authentication UX for users. More importantly, it changes the user’s mental account.

Before, the user felt: “I am buying this AI SaaS.”

Later, the user will feel: “I already pay OpenAI/Anthropic $20, $100, or $200 per month for a pool of AI compute. This product just helps me use that compute better in a specific business workflow.”

The first mental account can accept AI SaaS bundling model cost into a subscription and selling it at a markup. The second will instinctively ask: are you selling the model, or are you selling your business capability?

BYOT is separating model cost from product value, forcing users to decide again which part is worth paying for.

From SaaS embedding AI to AI calling SaaS

But BYOT only changes cost ownership. The more dangerous shift is that agent runtimes will also change the user entry point.

Codex’s recent spread among general knowledge workers shows that it is no longer just a coding agent. It is becoming a general agent. For SaaS companies, this is far more dangerous than “another developer tool got popular.”

Because the essence of SaaS is not a few buttons on a webpage. It is helping users complete a certain kind of work. If an agent runtime can read files, run commands, operate tools, call MCP, and execute long-running tasks inside a sandbox, many SaaS products will move from “the place where users do work” to “a tool the agent can call.”

Whoever owns the entry point gets to rewrite the business model.

In the past, SaaS embedded AI. Notion embedded AI. Figma embedded AI. Attio embedded AI. Pylon embedded AI. AI was the feature; SaaS was the host.

In the future, this relationship flips: AI calls SaaS directly.

The user path will move from: “Open a SaaS product to make a report.”

To: “Codex, organize this month’s sales pipeline, call Attio CRM MCP, check Stripe, read Pylon customer tickets, and generate a board update.”

In that process, Attio, Stripe, Notion, and Linear may all be called. But the user entry point is the agent, not the SaaS product.

SaaS companies have always wanted to own the main interface where users work every day. That interface means habit, data, collaboration, distribution, and upsell. Now agent platforms want to become that interface, and SaaS becomes a tool, a data source, a permission layer, and an operations layer.

It is like going from restaurant to back-of-house supplier. You can still make money, but your bargaining power is completely different.

Of course, not every SaaS product will lose value because of this. An agent can call Stripe, but it cannot replace Stripe’s payment records, risk controls, settlement, and compliance responsibility. An agent can call Linear, but it cannot replace Linear’s issue model, team collaboration, permissions, and project history.

But the change in entry point still matters. In the software business, the entry point has never been just a UI issue. The entry point determines user habits, distribution power, who defines the workflow, and who captures more profit.

In the past, users opened SaaS first, then used the AI feature inside it. In the future, users may open an agent first, then let the agent call SaaS.

This is a transfer of power.

The dilemma for existing AI SaaS

When the agent takes the entry point, it damages SaaS habits and distribution. When token entitlement can be brought into third-party products, it damages the value structure of SaaS. Put the two together, and you get the real problem for existing AI SaaS.

If they do not support Agent SDKs, and insist on included token usage pricing plus a self-built agent harness, they will face four problems: 1) new BYOT products will have a cost-structure advantage; 2) users will question the extra pricing on AI features; 3) they will have to compete with OpenAI/Anthropic, two companies with extremely high talent density, on agent harness development; 4) the large amount of API token calls needed to support agent workloads will significantly lower gross margin.

Even if these existing AI SaaS products start supporting Agent SDKs, they will still face real pain: 1) in the short term, they need to adjust technical architectures that already deeply integrate API calls and move them toward Agent SDK calls; 2) in the short term, they risk stagnating growth by cannibalizing existing subscription revenue; 3) in the long term, they can no longer earn a premium through intelligence markup, and must explain again why users should still pay for workflow, data, permissions, and outcomes.

This is the transformation dilemma for existing AI SaaS.

If they do not support it, they may lose to new products on cost structure and user mental accounting.

If they do support it, they actively split open their revenue structure and expose the intelligence layer that used to be bundled inside the subscription.

When the intelligence layer inside existing AI SaaS gross margin is eaten by OpenAI/Anthropic through Agent SDKs, and these companies are left with only workflow and system-of-record value, users and capital markets will reprice them.

Future users will not want to pay ten different AI SaaS products for ten separate intelligence markups. They are more likely to pay one or two agent platforms for high-capacity token plans, then let different workflow apps call those entitlements.

The ambition of model vendors

The release of Codex SDK/Agent SDK shows that OpenAI/Anthropic will not be satisfied sitting behind SaaS companies as API vendors while downstream SaaS companies capture the fattest profit pool of the AI wave. To model vendors, AI SaaS intelligence markup is the most attractive profit pool.

Classic: your margin is my opportunity.

The trend is already clear. Codex/Claude Code may not consume all enterprise software budgets, but they will consume a large share of new AI budgets, AI add-on budgets, and knowledge work automation budgets.

Enterprises will not want to buy a separate AI add-on for every SaaS product. The more natural path is that every knowledge worker, or at least every role that frequently uses software to get work done, gradually gets a company-procured agent/token plan, then completes work through SaaS MCPs, APIs, and permission systems.

This is also why OpenAI/Anthropic are actively pushing Codex, Claude Code, Agent SDKs, Apps SDK, and MCP. Their goal is not to make third-party SaaS companies more comfortable. Their goal is to make more third-party workflows run on their own token plans.

This trend appeared first in developer tools, such as agent-native editors/workspaces like OpenCode, Conductor, and Zed. Next, it will spread into more ordinary knowledge work: design, documents, customer support, research, and operations. Design workflows like MagicPath and agent workspaces like Craft Agents are early shapes of the same direction.

Their forms may differ, but they share one trait: the product no longer treats model API calls as its core asset. Instead, it redesigns the workflow directly around an existing agent runtime.

This will push users toward higher-tier, more economical token plans, rather than using AI SaaS included credits that do not support Agent SDKs. Model vendors can then use their own token plan subscriptions to eat the intelligence markup that used to belong to AI SaaS.

Eventually, AI tokens will become like electricity, water, and bandwidth: infrastructure that consumers and enterprises have to pay for every month. OpenAI/Anthropic will capture the largest profit by monopolizing the supply of the intelligence layer and selling it directly without middlemen.

What remains for SaaS

But this is not a “SaaS is dead” story. More accurately, SaaS products that mistake model calls for product value will die. Software with real business depth will become more valuable.

Products with system-of-record status will not die easily. Linear, Salesforce, Stripe, Rippling, ServiceNow, Figma, Notion, and GitHub are not valuable because of AI alone. They own object models, permissions, history, team collaboration, business state, and organizational memory.

Agents can call these systems, but they cannot casually replace them.

Likewise, products with organizational workflows and responsibility boundaries will not die easily. Enterprises do not buy software only for features. They buy audit trails, RBAC, SSO, approval workflows, compliance, SLAs, permission isolation, and vendor accountability.

These things are boring, but they are valuable. In business, many of the things that actually make money are boring.

The dangerous products are those with no owned data, no system of record, no organizational workflow, no responsibility for outcomes, and only a workflow wrapper around an API. They used to make money because users could not see the token bill. Agent SDKs will make that bill transparent.

So what remains for SaaS is not slapping the word “AI” on the pricing page. It is returning to the most basic value of software: helping users get work done.

Workflows that fit business best practices, well-abstracted data models, intuitive interfaces, correctly routed permission flows, traceable audit records, stable import and export, and collaboration systems that teams can use over the long term. These values rooted in the business itself may turn out to be what remains for SaaS.

The new agent-native product shape

In this reshuffling, the new opportunity for founders is not building another “SaaS with AI.”

The real question is: can your product become a system of work in the agent era?

If you are building SaaS now, you should not stop at AI-native. You should build agent-native. In other words, the product should not only call OpenAI/Anthropic model APIs. It should redesign the workflow around agent runtimes like Codex/Claude Code.

Let inference cost return to the account relationship between users and model vendors. You focus on the business workflow.

The business architecture shifts from the old web app + server-side API + inference COGS carried by SaaS + users paying by seat or AI add-on, toward desktop/local runtime + Agent SDK + the user’s own Codex/Claude Code subscription + SaaS charging for workflow/interface.

This structure has several obvious advantages.

  1. COGS no longer explode linearly with user token consumption, especially for agentic applications. Gross margin becomes healthier, closer to traditional SaaS.

  2. The user’s mental account is cleaner. He will think: “I already bought Claude Max. This app just helps me use that quota better in a specific business workflow.” This is easier to accept than “I pay ten different AI apps again every month.”

More importantly, the AI compute a user can access through their own Codex/Claude Code subscription will often exceed what AI SaaS included credits can provide. At the same unit price, BYOT products can offer a higher usage ceiling and more value to the user.

When enterprises start concentrating AI budgets into agent plans like Codex/Claude Code, it will be hard for third-party products to charge an extra AI premium. But if you can build on these agent runtimes and provide low-cost marginal efficiency gains in a specific domain, you still have a chance to enter the enterprise IT budget conversation.

  1. Desktop/local runtime is closer to the real work environment. A lot of work already happens in local files, browsers, CLIs, repos, PDFs, Excel, and strange folders. Traditional web SaaS always wants to pull users into its own system. Agent-native products running on local runtimes can grow along the user’s existing work environment, while also avoiding the cost of deploying a server-side agent runtime.

  2. The product can be more focused. You do not need to rebuild a large SaaS AI backend. You only need to build around a specific job-to-be-done: tool orchestration, prompts, evals, templates, local state, human approval, and final delivery.

But there is a brutal premise here.

Connecting to an Agent SDK is not a moat.

If your product is just a thin-shell agent, OpenAI/Anthropic can copy it by adding a skill. The real moat must be domain workflow density. You need to understand a specific workflow deeply enough that users are willing to pay for your judgment, defaults, failure handling, and output quality.

Because as models get stronger, prompts get cheaper, and tool calling becomes more standardized, the scarce thing will become knowing what should be automated and what should not; which steps can be handed to an agent and which must stay human-in-the-loop; what can be delivered directly and what must be checked first.

Opinionated software built with good product taste will win users in this era.

Conclusion

The impact of Agent SDKs on SaaS is not that they add one more way to call a model. It is that they redraw profit ownership across the software value chain.

The profit of the intelligence layer never really belonged to most SaaS companies. OpenAI/Anthropic models will get stronger, token plans will get more economical, and agent runtimes will become more general. Competing with them for model-layer profit has poor odds over the long run. The more reasonable choice is to admit that model vendors will eat this layer of profit, then build your company on what they cannot eat, or do not want to eat.

Because if a SaaS product is truly valuable, its value should not mainly come from model resale. It should come from workflow, data, permissions, interface, collaboration, audit, quality, and outcome delivery. Models are responsible for intelligence. SaaS is responsible for work.

Companies that cannot tell the difference will be repriced sooner or later.