People are freaking out about AI. That’s never a good starting point for sensible policy. So we get weird ideas.

One idea is to tax computer processing capabilities, sometimes called a “compute tax.” Andrew Yang is pushing it, so you know it must be serious. John Arnold captured the general sentiment on Twitter:

As Anton Korinek told the WSJ: “Half a year ago, it was something you would hear about only in very select circles. It really has become much more mainstream in the last three months.” That piece has a lot of great quote, so I will keep comping back to it. It also has Nobel laureate Simon Johnson saying a compute tax is a “sensible policy lever to slow down automation.”

Is it sensible?

We agree that when you tax something, you get less of it. That would slow automation down. “Sensible” is not the word I would use, though. If you just hate AI and want less of it, then maybe Simon Johnson is right, and a compute tax is sensible.

A compute tax is about as bad as a tax can be, by the standard benchmarks used in public finance. If you care about things like increasing output, total surplus, minimizing deadweight loss, those types of things, stay away from this.

This newsletter explains why. In many ways, this will mirror what we’ve discussed before about tariffs, so I’m going to keep bringing them up in this piece. I know. Sorry. But, as Herbert Spencer said, “Only by varied iteration can alien conceptions be forced on reluctant minds.”

What is a compute tax?

A compute tax is a levy on computational resources. Think GPU hours, processing power, data center electricity, or some similar proxy for AI work. But “compute tax” bundles two quite different proposals, and the difference matters.

Korinek and Lockwood have written the most careful framework on this in a Brookings working paper on public finance in the age of AI. They draw the key distinction: there is a stock version and a flow version.

A stock tax is if you tax the GPUs, the data centers, the training clusters. This is basically a form of capital taxation (which we will talk a lot about below). My reading is that this is the most commonly proposed tax. The idea of banning data centers is an extreme tax on the stock of compute.

In principle, you could also tax the output. This is a tax on the flows, through the tokens generated, the images produced, the AI services consumed. Korinek and Lockwood are more sympathetic to this form of taxation. But once you add the B2B exemption that they suggest, you’ve described a regular sales tax or VAT on AI consumer services. I don’t think we should call that a compute tax.

Taxing the wrong thing

There are a few main results in optimal taxation that show up again and again. People can quibble over the exact ordering but I’d say the most important comes from Diamond and Mirrlees.

The takeaway is don’t tax intermediate goods. Keep the production side of the economy as efficient as possible, then redistribute from the output. That’s why it’s called Diamond-Mirrlees production efficiency.

Compute (again, as a stand-in for computer processing) is huge now but going to be the intermediate input of the modern economy. It goes into drug discovery, weather forecasting, fraud detection, medical imaging, logistics, customer service, and, yes, generating cat pictures. When you tax compute, you raise the cost of every single one of those downstream applications. You shrink the economic pie before anyone gets a slice.

Korinek and Lockwood have a great line about how a compute tax is like “taxing steel during the industrial revolution.” You don’t make people richer by making steel expensive.

This was also the core problem with tariffs on intermediate goods. As I’ve explained before, a 10% tariff on imported car parts compounds through the supply chain and becomes a 30% effective tax on the finished car.

The supply chain aspect may not be as extreme as if you’d say tax something even further up the supply chain, like semiconductors, but a compute tax compounds in the same way. Tax the GPU hours that train an AI model, and the cost cascades through every product that uses the model. The drug company, the weather service, the fraud detection startup, the accounting firm, they all pay more. Pascual Restrepo told the WSJ: “Why do you want to increase the cost of all of that?”

This feeds directly into another one of the main results in optimal taxation: don’t tax capital. The original Chamley-Judd result says that you shouldn’t tax capital. The original result said “in the long run,” but, really, even in the short run.

Data centers are capital. Training clusters are capital. The entire AI infrastructure buildout is a massive capital investment.

A compute tax discourages precisely the investments that make AI cheaper and more widely available over time. This is the equivalent of taxing ladders to protect the people climbing trees with their bare hands. You don’t help the bare-handed climbers by making ladders expensive. You help them by making ladders cheap enough that everyone can afford one. Then, if you want to redistribute, tax the coconuts.

It also doesn’t make sense to tax capital from a redistribution point of view, as John Arnold seems to worry about in his tweet. I made this exact argument about AI and capital taxation in my response to Trammell and Patel. The features of AI that people worry about (easy substitution between capital and labor, mobile capital, self-replicating infrastructure) are exactly the features that make capital taxation counterproductive. With elastic capital supply, a capital tax doesn’t stick to capital owners. It falls on workers through lower wages. The more mobile and substitutable capital becomes, the worse taxing it gets for the workers you’re trying to help.

The optimal rate is below zero

So far, Diamond-Mirrlees and Chamley-Judd say a compute tax is a bad tax at any rate. It’s not obvious that we shouldn’t even go further. Maybe we should subsidize compute?

The Pigovian principle (1920) says the optimal corrective tax on an activity equals its marginal external damage. When an activity generates negative externalities (pollution, congestion), tax it at the marginal external cost. When an activity generates positive externalities, the optimal “tax” is negative. A subsidy.

It’s plausible that compute has positive externalities from at least two distinct sources.

There’s a learning-by-doing element. If we’re training models and other people are learning from that process, the industry supply curve can be downward sloping, so my production actually helps your production. The firm producing the millionth GPU does not capture the full social value of pushing the technology further down that curve. Everyone who uses cheaper GPUs in the future benefits from that producer’s accumulated experience without paying for it. That’s an externality. We may want to push producers down the supply curve to lower everyone’s cost

There seems to be something to that when we see GPU performance improving, but it could be this is almost all internal to NVIDIA so its not ’s not an externality.

There’s a slightly different angle around general-purpose technology (GPT) spillovers. Bresnahan and Trajtenberg (1995) defined a GPT as something that is pervasive across sectors, improves over time, and has the capacity to spawn complementary innovations. So things like steam, electricity, semiconductors, and now AI compute all qualify. GPTs generate two-sided externalities, where users don’t capture the value of pushing the technology down its cost curve, and producers don’t capture the value of enabling downstream innovators they never anticipated. So it’s like learning-by-doing combined with when people use your good, you don’t get all the benefit.

In practice, I don’t think we have a good enough sense of exactly how to subsidize it to make it work. I’m skeptical of externality-based arguments. If we are going to start saying externalities for anything we want, that becomes a huge mess of just asserting AI is wonderful or going to kill us.

I’m saying it’s not obvious, from a Pigovian perspective, that we want to tax.

You can’t even define it

Above is all in the land of standard economic theory. It’s at a level of abstraction. But let’s take practice a bit more seriously.

Now suppose the legislature sits down to write the statute. What counts as taxable compute?

It seems like we definitely want to count a GPU training a large language model. How are we going to track that? What about a GPU rendering a video game? When my laptop is running code or my phone is autocorrecting, is that compute? Probably not. What if it is happening on the cloud through data centers?

Tax practitioners flagged this same problem with robot taxes (also a dumb idea for the same reasons). Are we going to tax ATMs?

Any definition will be either so narrow that firms route around it by relabeling their compute, or so broad it taxes everything with a processor. Both outcomes are terrible.

Let’s not forget about all those lovely exemptions. Will where get to the point where we have that “U.S. data” (undefined in statute) must be “processed” (also undefined) on “U.S.-made motherboards” (also undefined). Will medical AI get a carve-out? Climate modeling? National security applications? Each exemption is a lobbying target.

A broad consumption tax doesn’t have this problem. It taxes the final transaction. It doesn’t need to know whether an AI or a human produced the good. It doesn’t need to distinguish between “AI compute” and “regular compute.” It’s technology-neutral by design.

The revenue isn’t there

If you want to just slow down automation like Johnson, that’s one thing. But if you want revenue, say for redistributing to labor (ignoring the problems abovee), that’s another thing. Here’s the part that compute tax advocates don’t want to talk about. Korinek, who takes the AI displacement concern seriously, points out that the numbers don’t work, and a compute tax “would raise a little bit of money but would not really make a significant impact.”

U.S. compute spending is large in absolute terms but small relative to GDP. A tax high enough to fund meaningful UBI payments would need astronomical rates, generating enormous distortions. I’ve worked through the math before. When a tax base is narrow, you need sky-high rates to raise real revenue, and the deadweight loss grows with the square of the rate. That’s bad enough for tariffs, where imports are about 10% of consumption. For compute, the base is even smaller.

And let’s not forget those pesky elasticities, always causing problems for central planners. Compute infrastructure can relocate (unlike land, unlike most labor), a unilateral U.S. compute tax pushes training runs to Canada, the Gulf states, or wherever electricity is cheap and taxes are lower.

So what are we to do?

It’s not like we are starting from some optimal tax code. So can we fix it? Erik Brynjolfsson at Stanford makes the sharpest point. The current U.S. tax code already implicitly penalizes labor relative to machines. A company with 1,000 workers pays more in total taxes, including payroll taxes, than a company making the same revenue with 1,000 machines. If the worry is that the tax system tilts toward automation, fix that asymmetry before inventing a new tax on the machines.