Zero Token Design, After ChatGPT Work

Two months ago I wrote a piece called Zero Token Design.

The core claim was this: an AI product doesn't always need to burn its own tokens at runtime. The old logic, where every click fires another model call and burns another token, works differently once the user already has their own agent workspace.

The better way is to let the user finish the reasoning inside their own agent workspace, and then push the structured result back into the product. The product owns the schema, the database, the versions, the rendering, and the distribution. Basically: let the agent do the work, and let the product catch the result.

But that piece quietly rested on one assumption I never said out loud.

It Only Worked for a Few People

Not everyone has an agent workspace.

A developer might already have Codex, Claude Code, or OpenCode installed. They know how to open a terminal, they know what npx is, and they know where to paste a quick-start prompt.

But for most ordinary users, that's still too much of a leap. They're not going to install a coding agent just to use some small product, and they're not going to set up a new working environment on their laptop.

So Zero Token Design held up as an architecture, but it really only belonged to developers. It was a developer's design.

ChatGPT Work Is That Agent Workspace

After ChatGPT Work shipped, I realized that missing piece was now in place.

ChatGPT Work is no longer the old chat box. It can read files, connect to external services, run multi-step workflows, and keep working for much longer stretches. It's an agent workspace in its own right.

What matters more is that it runs in the cloud, and it is on the phone. The agent workspace that used to live only on a developer's laptop now sits in everyone's pocket.

You don't need the phone itself to run an npx command. The real execution environment already lives in the cloud workspace behind ChatGPT.

But the role of npx has flipped completely. Before, npx was how a user launched a product's capability. Now, npx is just how a developer packages that capability into the product. The user doesn't even need to know it exists. They just have to ask.

So for the first time, Zero Token Design goes from an architecture for developers to an architecture for everyone.

That Screenshot Importer? Don't Build It

I once built a high-speed rail app called Raily.

Someone gave me a very reasonable suggestion at the time: why not add a screenshot import feature? A user buys a ticket on 12306, drops the order screenshot into Raily, and Raily automatically reads the date, train number, departure and arrival stations, time, and seat, then creates a trip.

By the old product logic, of course you should build this. I would have to build image upload inside Raily, request photo library permissions, wire up OCR, parse the fields, handle recognition errors, add a confirmation step, and finally write the data to the server.

But looking at it now, that feature does not need to live inside Raily at all.

The user buys the ticket and sends the screenshot straight to ChatGPT: add this train to my Raily.

ChatGPT reads the screenshot. The Raily Skill turns the train number, time, stations, and seat into the data structure Raily needs, then calls Raily's API to write it to the server. The Raily Skill and the Raily app share the same account, the same database, and the same server.

The next time the user opens Raily, the trip is already on the timeline. They never had to open Raily to make it happen, never hunted for an import button, never re-uploaded the screenshot, and never learned what formats Raily supports.

But Raily Doesn't Disappear

This doesn't mean ChatGPT replaces Raily.

Because a chat box isn't necessarily the best interface for looking at rail trips. Users still want a clean timeline, transfers between cities, departure and arrival reminders, station details, trip history, maybe even a map of where they have traveled by rail. A dedicated vertical app can probably do these better than a chat box.

What actually changes is that Raily no longer has to carry everything at once. ChatGPT handles understanding what the user wants and pulling in real-world input. Raily handles showing the rail trip beautifully.

They're not two competing products. They're two interfaces of the same system. One handles input, one handles display, and they share the same data underneath.

This logic is not limited to a rail app. A spending tracker is the same: the user no longer has to download an app, sign up, photograph a receipt, wait for OCR, fix errors, and pick a category just to reach a report page. They can snap a receipt inside ChatGPT and say log this expense, then open a website to see the full monthly chart. Both sides read the same data.

ChatGPT Work Becomes the Entry Point for Every Small Product

So the real change this time is not that screenshot import got more convenient.

It's that ChatGPT Work might become the entry point for every small product from now on.

In the past, every product had to build its own entry: sign up, login, upload, search, forms, a help center, plus a new AI chat box and its own inference service. Every founder was rebuilding the same things.

But what users actually need is usually not these entries. It's the small bit of capability behind the product: a set of domain rules, a data structure, a stable execution flow, and the state that accumulates over time.

The point of ChatGPT Work is that it strips this generic shell out of every product.

So the small product of the future may only need four things: a clear data structure, a reliable server, a Skill or Plugin that agents can call, and a display surface that genuinely deserves to exist on its own. The first batch of users might use your product entirely through ChatGPT.

Design the API Before the Pages

At that point, the structure of a product shifts.

It used to be: the user opens the app, the app understands the user, the app calls the AI, the app writes the data, the app displays the result. Now it might be: the user opens ChatGPT Work, ChatGPT understands the user, the Skill calls the product's capability, the product server holds the state, and the app displays the result.

So the first question a founder asks may no longer be how many pages do I need to build. It becomes: can my product be called by an agent? Can it reliably accept a structured result? Can identity and permissions carry over between ChatGPT and my product? Can the Skill and the app read and write the same data? When the user never opens my product, does it still create value?

This also changes the logic of distribution. We used to ask how to get the user to open our product one more time. Now we may have to ask how to get ChatGPT to call our product at the right moment.

SEO is about getting a search engine to find your page. There may be a new kind of optimization ahead: getting an agent to understand your capability, trust your interface, and call you in the right situation.

Back to Zero Token

This is also why I wanted to write about Zero Token Design one more time.

The first time, I cared about the token cost, about not making every product carry the same inference over and over. But looking at it now, what really matters about Zero Token Design may not be how much money it saves. It is that it redefines where a product is allowed to happen.

In the past, a product had to happen inside its own website and app. Now, a product can happen inside the user's agent workspace. And ChatGPT Work moved that agent workspace from a developer's terminal into everyone's phone. This time, the user doesn't need to install Codex, doesn't need to understand npx, and only needs to open ChatGPT.

And once a product starts happening inside the agent workspace, the place where users enter it moves there too. Where a product happens and where the user enters it become the same place, for the first time.

So from now on, don't rush to stuff another chatbot into every product, or rebuild a page for every kind of input. Hand the agent what belongs to the agent, and keep a good app only for the places that genuinely need a dedicated display.

In the past, we designed an entry point for each product. In the future, all products may share the same entry point. And that entry point is ChatGPT Work.