The Cheapest Way to Run an AI Product Is to Not Pay for It

Every AI product I have priced starts from the same assumption: we buy the inference, we mark it up, the customer pays a subscription. That is how ours works. Every clip ViralFaceless renders bills us at OpenRouter, ElevenLabs and FAL before it bills the customer anything.

In the twenty-four hours before this was written, three separate products shipped the opposite assumption. Not cheaper inference. No inference bill at all, because the user already has one.

What the three of them actually did

A desktop video tool called Videoclaw ships a build whose interface offers two ways to pay for the model. We pulled apart version 0.0.36, an Electron app built on the Claude Agent SDK, and the strings are unambiguous:

"Click to connect your Claude Code plan""Claude usage counts against the Claude Code plan signed in on this Mac. Open Account to change it."

The alternative, in the same interface: "Claude usage is metered through Videoclaw credit." Two modes, user's choice: their subscription, or the vendor's credits through a gateway.

The same week, Petr Brzek(opens in new tab) launched Macaly Cloud on the argument stated plainly: they built it without the most expensive part of a vibe-coding platform, the coding agent, because you already pay for ChatGPT or Claude. The price on their own page(opens in new tab), checked 2026-09-17, is free until October 1 and $10 a month after.

And on 2026-09-16, Nigel Hungerford-Symes posted a measurement(opens in new tab) from the far end of the same idea: 18 hours of autonomous coding across two local models on two GPUs, 925,000 tokens of working code, "no cloud, 0% subscription usage, no 5 hour limits and it cost about $0.35 in electricity."

Three points in twenty-four hours is not a market. It is enough to notice that the expensive part of an AI product has started moving off the vendor's balance sheet.

The same product category, four different answers to who the inference bill goes to.

Why this is structurally different from being cheap

The usual moves against inference cost are quantitative. Smaller model, shorter context, cache the repeated calls, batch what can wait. Each one buys a percentage.

Moving the bill to the user's existing plan is not a percentage. It changes what kind of cost it is. Ours is variable and vendor-denominated: every render is a line item at three suppliers, the price moves when their price moves, and gross margin is a function of usage we do not control. Theirs is fixed, the cost of the software once, and the marginal render is free to them because somebody else already paid for it.

That difference shows up everywhere downstream. A product paying per render has to meter, and metering is where we charged 900 credits for a video that did not exist. A product that does not pay per render has nothing to meter. It never builds the billing edge cases, never reconciles a vendor's idea of success against its own, never has the argument about who eats a failed generation. That last one is worth dwelling on, because a vendor reporting success for work that never landed is its own failure mode, and it is much cheaper to discover when you are the one being billed for it.

It also inverts who absorbs a price change. When FAL reprices, we absorb it or pass it on. When Anthropic reprices, a BYO product's users absorb it and the vendor reads about it.

Two cost structures, drawn as shapes because the amounts are not ours to publish.

The part nobody in the three examples mentions

Anthropic's legal and compliance documentation(opens in new tab) addresses this pattern directly, and it draws a line:

"Anthropic does not permit third-party developers to offer Claude.ai login into their own applications, or to route requests through Free, Pro, or Max plan credentials on behalf of their users. Moreover, developers may not collect, store, or intermediate Claude.ai credentials or session tokens — sign-in to a Claude account must complete through Anthropic's own flow."

And immediately after, the carve-out:

"Nor does it prevent an end user from signing in to the unmodified Claude Code binary with their own Claude subscription, including where a platform hosts Claude Code."

So there are two versions of "the user's subscription pays for it." One is an end user signing into Anthropic's own unmodified binary, which the terms explicitly protect. The other is a third-party application relaying that user's plan credentials through its own infrastructure, which the terms explicitly prohibit.

From the outside, both look identical. Both show you a connect button, both bill nothing for inference, and both say your usage counts against your plan. The difference is whether the credential ever touches the vendor's infrastructure, and that is an implementation detail no product's marketing page discusses.

Videoclaw's string, "the Claude Code plan signed in on this Mac," reads like the permitted shape: the user's own binary, the user's own machine, the vendor watching from a distance. Reads like. We took apart their bundle and can tell you it is an Electron app on the Claude Agent SDK with a gateway at a Cloud Run address. We cannot tell you which of the two shapes the OAuth actually follows, because that is not visible in a shipped binary's strings, and they have not published it.

That is the honest state of this: the model everyone copied this month has a compliance boundary running through it, the boundary is documented, and the products sitting on it are silent about which side they are on.

If you are considering this for your own product

Three questions, in the order that matters.

Does the credential touch your infrastructure at any point? If a request carrying a user's plan credentials passes through a server you operate, you are in the prohibited shape, whatever the UI says. Pass-through sign-in that completes in Anthropic's own flow is the permitted one. This is a question about your architecture diagram, not your terms of service — and like most questions of that kind, the honest answer comes from what the system refuses to do rather than from what its copy claims.

What happens to your product when the policy moves? The page carries no effective date, and it reserves the right to enforce these restrictions "without prior notice." A product whose unit economics depend on a third party's current interpretation of its own terms has a dependency it cannot version-pin, and no changelog to watch.

What are you actually selling? Macaly's answer is coherent: they sell the database, auth, hosting, domains and payments, and the model is something you bring. That is a real product with a real bill. If removing inference cost from your product leaves nothing anyone would pay ten dollars for, the model was the product and this was never a pricing decision.

We have not made this change and are not announcing one. Our costs are variable and vendor-denominated, and for a server-rendered pipeline that is mostly unavoidable. The render has to happen somewhere, and it is not happening on the user's laptop. But the desktop case is genuinely different, and any product shipping a binary to a machine that already has a Claude subscription on it is now having this conversation whether it wants to or not.

The question worth sitting with is not whether to copy it. It is whether you could tell, from the outside, which side of that line a competitor is on, and whether your users could tell about you.

FAQ

Is it against Anthropic's terms to let users pay for inference with their own Claude subscription?

Not inherently. Anthropic's documentation explicitly permits "an end user signing in to the unmodified Claude Code binary with their own Claude subscription." What it prohibits is a third-party application offering Claude.ai login inside its own app, routing requests through consumer plan credentials on users' behalf, or collecting, storing or intermediating those credentials. The same mechanism is permitted or prohibited depending on whether the credential passes through the vendor's infrastructure.

Does this make AI products cheaper to run?

It makes inference cost structurally different rather than smaller. The vendor's marginal cost per request approaches zero because the user's existing plan absorbs it. The trade is a dependency on another company's subscription terms, and the loss of any margin on inference itself, which for some products is the entire business.

Why would a user agree to spend their own plan's quota on someone else's product?

Because they are already paying for it and usually under-using it. A Claude or ChatGPT subscription is a fixed monthly cost with a usage ceiling most people never reach. A tool that draws on that ceiling costs the user nothing incremental until they hit it, which is a genuinely better deal than paying a second subscription for the same inference.