# Zero Token Design / 零 Token 设计

> Published 2026-05-07 · By lawted (https://x.com/lawted2) · Published on HA7CH (https://ha7ch.com)
> Canonical: https://ha7ch.com/writing/zero-token-design

## English

I'm not saying the product doesn't need AI. What I mean is: an AI product doesn't always need to burn its own tokens at runtime.

Think about how we built AI SaaS products in the past. The logic was simple: every time a user clicks, the product calls the model. Another click, another request. Another request, another token burned.

That made sense in 2023, because back then, most users didn't really have their own AI workspace.

But now it's different.

Codex, Claude Code, OpenCode, Cursor, and other local agent workspaces are getting more and more mature. They are no longer just chatboxes. They can read your directory, read your documents, run bash commands, edit code, run npx or uvx, and handle a whole workflow inside the user's own environment.

So I think the next generation of AI products can be designed differently.

Not every product needs to put a chatbot inside the webpage and pay for all the reasoning costs by itself. A better way might be: let users finish the reasoning inside their own agent workspace, and then push the result back into your product.

And this is different from Bring Your Own Key.

BYOK still asks users to apply for an API key, configure the key, understand billing, and put that key into your product. Honestly, that's just transferring the bill to the customer, but the UX is still heavy.

Zero-token design is not about asking users to configure a key inside my product.

It is about letting my product work with the tools they already use, like Codex, Claude Code, OpenCode, or Cursor.

CV.pro is a zero-token AI product in my understanding.

It is definitely an AI product, because resume parsing, JD tailoring, and content rewriting all need AI. But these things don't have to happen on CV.pro's server.

The more natural way is: the user copies a quick-start prompt, and maybe there is an npx command inside that prompt. Then they paste it into their own agent workspace. The agent runs the command, parses the file, handles the errors, generates the structured schema, and pushes that schema back to CV.pro.

So CV.pro is responsible for the schema, database, URL views, versions, rendering, and distribution.

Basically: Let the user's agent do the work. Let the product handle the result.

And I think every founder building AI products should think about this carefully.

Should your product do all the reasoning by itself?

Or should it become a system that can be operated by agents, capture the result, and distribute it beautifully?

That's the difference.

## 中文

它不是说产品不用 AI，而是说：AI 产品不一定要在自己的 runtime 里烧 token。

以前做 AI 产品，默认逻辑是用户点一下，产品调用一次模型；用户再点一下，产品再烧一次 token。这个在 2023 年可能合理，因为用户没有自己的 AI 工作台。但现在不一样了。

Codex、Claude Code、OpenCode、Cursor 这种本地 agent workspace 已经越来越成熟。它们不只是聊天框，而是可以在用户自己的项目目录里读文件、跑命令、改代码、执行脚手架的工作台。

所以我觉得，下一代 AI 产品的默认架构应该变了。

不是每个产品都自己包一个 chatbot，然后自己承担推理成本。更好的方式是：让用户在自己的 agent workspace 里完成推理，把结果写回产品。

这和 Bring Your Own Key 不一样。BYOK 还是让用户去申请 API key、配置 key、理解 billing，本质上只是把账单转嫁给用户，体验很重。零 Token 设计不是让用户把 key 塞进我的产品，而是让我的产品进入用户已经在用的 Codex / Claude Code / OpenCode 工作台。

CV.pro 就是我理解里的零 Token AI 产品。它当然是 AI 产品，因为简历解析、JD tailoring、内容重写都需要 AI。但这些动作不应该都发生在 CV.pro 的服务器里。更自然的方式是，用户复制一段 quick start prompt，丢进自己的 agent，agent 自己去跑 npx、解析文件、处理错误、生成结构化数据，然后写回 CV.pro。

CV.pro 负责的是 schema、数据库、URL view、版本、展示和分发。

说白了就是，让 agent 去干活，让产品把结果接住。

这可能也是我现在对下一代 AI 产品的一个判断：不要急着在网页里塞一个聊天框。先想清楚，你的产品到底应该自己推理，还是应该变成一个能被 agent 操作、能沉淀结果的系统。