Model Optionality Is the Defense Against Volatile Token Economics

Sarah Sachs leads AI engineering at Notion and negotiates its model contracts. Her premise is that applied-AI companies cannot treat inference cost as an implementation detail. It is a structural barrier: it determines whether a product can be served at scale, whether automation can be deployed broadly, and whether a company is passing an unattractive deal to customers or investors.

The immediate problem is not simply that frontier models cost money. Their economics can shift without a corresponding increase in an application’s revenue or a customer’s willingness to pay. Sachs described two recurring patterns Notion has encountered: a reasoning-model upgrade that retained the same per-token price but used roughly three times as many output tokens on some tasks; and a successor model that made material reasoning gains, cost 40% more, and deprecated its predecessor within four months.

More capable models can be worth paying for. Sachs’s question is commercial: is the application growing revenue by 40% over that period, or earning three times as much because a model consumes three times the tokens? Usually, she argued, it is not. An automatic upgrade can therefore become a bad deal for someone—either the customer absorbing higher prices or the company absorbing lower margins.

Large companies can field procurement, consulting, and technical teams to navigate those shifts. Sachs framed her advice as a negotiation playbook for the “Fortune 5 million”: companies without Fortune 500-scale leverage but with the same need to understand model tradeoffs. Their defense is not to out-negotiate every lab on token price. It is to avoid building a business whose economics depend on a single supplier remaining favorable.

Sarah Sachs’s strongest warning is that a frontier-model provider is often both an upstream vendor and a downstream competitor. A lab can sell a first-party product directly to users while selling API tokens to an application that must mark those tokens up again. In that arrangement, she argued, the application begins at a cost disadvantage that an interface alone cannot explain away.

“You will always be getting a bad deal on tokens with someone who builds them natively,” Sachs said. The lab is serving a first-party product while the application buys tokens “at a huge surcharge” and resells them at another surcharge. That is not value a company can defend unless it provides something materially beyond model access.

The SemiAnalysis comparison Sachs presented contrasted first-party subscription pricing with approximate API-equivalent token spend. She used it to illustrate how much more usage a lab may make available through a direct subscription than through an API customer that must build and sell its own product on top.

The other danger is lock-in. A provider may be cheaper when a company commits, but pricing can change. If product behavior, prompts, infrastructure, and workflows are tightly coupled to that provider, the company’s ability to leave is limited precisely when it needs bargaining power.

Sachs’s formulation was blunt: “If you don't have the capability to walk at any point, you are stuck.” She considers the engineering investment in interoperability cheaper than the strategic cost of being unable to exit.

She did not argue that frontier models should be avoided. Autonomous agent paths, large-scale data analysis, and deep-research work can warrant frontier capability. The error is treating all traffic as though it requires the leading model. Notion may recommend Opus for large-scale data analysis, she said; using it to triage an email inbox and charging for that usage would be “ripping you off and ourselves.”

Sarah Sachs argued that the relevant unit of optimization is not token price. It is a task’s cost, required capability, and acceptable latency: “cost-per-capability-per-second.”

That requires product-specific judgment. The dividing line is not fixed by a benchmark or a vendor’s pricing page. The application builder has the context to assess tool failures, complete task trajectories, latency requirements, and the quality threshold a user actually needs.

Sachs cited a Citadel Securities view that simpler models may be the most cost-effective productivity path for much of the economy, while inference-intensive frontier AI becomes concentrated among firms able to absorb its compute costs and deploy it in high-value operating domains. She agreed with the basic distinction between frontier and everyday usage, while stressing that every product has to determine its own boundary.

Pricing is not a reliable proxy for the capability an application needs. Sachs described a market in which the leading reasoning model can price at the top because it serves tasks others cannot yet perform, while a slightly weaker provider can price only marginally below the leader and compete for the rest. In her view, that means price does not necessarily track incremental capability growth.

The practical response is to evaluate whole trajectories rather than isolated model calls. Sachs pointed to Notion’s evaluation of web-search providers: a provider might not be cheapest or fastest on one call, but could perform better across the sequence of actions that makes up an actual search workflow. The relevant evaluation is the one that measures customer outcomes across the entire path.

That evaluation expertise is also a form of leverage. Sachs said Notion’s scorecards, use-case feedback, and early-access partnerships give frontier labs something valuable in exchange, reducing the need for extraordinarily large commitments. The alternative to a large spend commitment is not necessarily a weaker supplier relationship; it can be specific evidence about what a model does well or poorly in a consequential application.

Sarah Sachs said routing only works if the architecture preserves the ability to switch. The leading frontier provider changes frequently enough that a company committed to one lab can leave customers without the best available frontier capability for substantial periods. A discount can improve short-term margin while reducing customer value and bargaining power.

Notion’s “AI Switzerland” approach is to make several state-of-the-art models available while operating an auto model that handles about 75% of its AI traffic. That routing layer lets Notion switch providers underneath the product and gives customers access to models without binding the experience to one vendor.

Sachs’s operating advice is to build infrastructure across major providers, assess value on a cost-per-capability-per-second basis, and switch frequently as models and tool requirements change. Her slide suggested revisiting choices every two to three weeks. She acknowledged that this is difficult: systems may need to clear caches or change models during an ongoing transcript. But the harness still needs to be designed for interoperability.

The point is not to expose every underlying choice to customers or to offer every model on the market. It is to ensure the product can use the appropriate one and can change that choice when capability, latency, pricing, or reliability shifts. Sachs’s view is that the discount is not worth the loss of optionality.

Sarah Sachs presented open-weight models as an expanding alternative for moderate tasks. She did not present them as universally superior to frontier systems. Her claim was that they are now capable enough for a growing range of routine workloads, and that reinforcement learning on top of them has expanded the work they can cover.

That creates two advantages. It lowers the cost of work that does not need a frontier model, and it gives buyers a credible alternative to the small group of providers at the top of the market. In Sachs’s framing, that alternative can exert downward pressure on pricing even when an application continues to use frontier models for genuinely difficult work.

Sachs said Notion had found Kimi 2.6 to outperform GPT-4o in an earlier comparison, and named GLM 4.0 as another model worth considering. These examples were not offered as universal rankings. Her broader point was that open-weight systems are no longer useful only for narrow supervised fine-tuning. Teams should test whether a model is sufficient for their actual system, including its tool errors, latency, and task success—not merely whether it leads an external benchmark.

The same discipline applies before choosing a model at all. Sachs’s “CPUs over GPUs” formulation is a warning against turning ordinary software operations into reasoning problems. Turning a CSV into a PDF, making a Notion tool call through a CLI, and running deterministic SQL queries do not require an LLM. Those jobs can be handled as discrete code execution through workers and tools.

This is both an economic and a product-design decision. Deterministic execution can be cheaper and more predictable, while reserving model inference for work that actually calls for language understanding, judgment, or planning. Treating every task as a prompt is, Sachs argued, one way companies become token-poor quickly.

Sarah Sachs expects the next constraint on agentic systems to be less about raw model capability than about security, safe execution, and orchestration.

She adopted Simon Willison’s “lethal trifecta” for agent risk: access to private data, exposure to untrusted content, and the ability to communicate externally. Untrusted material can arrive through ingestion, email, MCP, or web search; outward communication can include payloads sent through a search process. Once those capabilities coexist, Sachs said, the system is exposed to data-exfiltration risk. More autonomy makes that risk less supervised.

The problem is not solved by buying a larger model. Safe sandboxes and execution environments can make an agentic product more deterministic while also avoiding needless inference. Sachs’s broader argument is that product value lies in governing what agents can do, not simply in increasing what they are capable of doing.

She described governance through three pillars:

• Visibility: knowing what exists, who owns it, and what changed, supported by usage analytics, audit-ready history, and benchmarks.
• Maintainability: keeping knowledge and agents accurate, current, and compliant through verification, ownership transfers, archiving, and deprecation.
• Control: setting boundaries for who can access, build, and automate through role-based permissions, connector allowlists, and agent-tool permissions.

A Notion administration view tracked credits used against a 1,000-credit allocation, five members building custom agents, 391 live custom agents during the month, and 808,135 completed runs. Sachs’s point is that model optionality expands what a platform can offer on governance: an organization can control not only agent behavior, but also the providers and systems through which that behavior is implemented.

Multi-agent orchestration creates a related challenge. Teams need to determine what each agent sees, what it can do, what it can send out, and what enterprise knowledge persists after a task is complete. Sachs said persistence is under-discussed, and warned against workflows so elaborate that engineering teams spend their time babysitting the factory rather than benefiting from it.

Sarah Sachs’s software-factory model is built around shared context, specialized roles, human decision rights, and reviewable hand-offs. The system should not merely dispatch a general-purpose model at a task. It should preserve the task’s underlying record, direct particular agents to work for which they are suited, and leave people able to select a path, contribute judgment, and inspect the work that follows.

Her demonstration used a Notion task about making deleted blocks visible. A Claude Agent scoped the work and laid out implementation paths. When a product decision required customer evidence, another agent, Decagon Dust, was asked to retrieve user feedback; the coding agent did not have to serve as the customer-voice specialist. After a human chose an approach, Claude created a pull request, and Codex reviewed it and found two issues.

The active document matters in this arrangement. It contains the problem, technical plan, customer evidence, human decisions, agent outputs, and review history rather than reducing the process to a static markdown handoff. The operational value is in making those contributions legible and connected: a specialist can supply evidence, a person can make the decision, a coding agent can implement it, and another agent can challenge the implementation.

That is what Sachs means by product value beyond token resale. The product determines which specialist should work on which step, retains the relevant context, establishes where people intervene, and connects agents to the tools and permissions they need. A customer-voice agent need not be the coding agent; a code-review agent can assess a pull request drafted by another system. The value is in coordinating those roles, not in claiming exclusive access to a particular model.

Notion uses related workflows internally for feedback routing and initial coding work, Sachs said. In the example she presented, a feedback router acknowledged an interface-bug report, filed it for the relevant team, and passed along the issue. Sachs said much of Notion’s polish work and larger feedback flows are coordinated through these software-factory mechanisms.

A displayed Notion test of four custom-agent templates—Q&A Agent, Task Triager, Weekly Status Reporter, and Morning Brief—reported a 93% average success rate and an average completion time of five minutes and 25 seconds for users who used a custom agent. Users who did not use one had a 59% average success rate and took eight minutes and 47 seconds on average.

The economic implication returns to Sachs’s central argument. An AI factory is not valuable because it buys more tokens or adopts one lab’s newest release by default. It is valuable when the product can determine which model, deterministic worker, tool, permission, and human collaborator a task actually needs—and can change those choices when the market shifts.