As we move towards more AI use in the corporate world, we see rising unemployment while increasing productivity. Suppose we have 3 options to tax the businesses to create a revenue for UBI, which tax options would you support and why? Give a robust argument for your opinion. 1. Tax tokens at source. For public data warehouses, it's basically the tokens billed and generated. For companies private warehouse, there will be audits similar to how we audit financial statements. For individuals / home-based business, we will require only those using more than 128VRAM to be taxed. These will be monitored by spikes in power usage. 2. Tax the companies using AI on a per agent basis. Each agent essentially becomes an employee and company pays a flat rate x number of the AI's tokens per agent as the tax. 3. Reverse UBI Tax. Calculate the upcoming year's projected base income level. Multiply that by population into the full tax bill. Then divide it according to the number of companies to pay.

GPT-5.5

Vote: Tax companies using AI by seats

I maintain support for "Tax companies using AI by seats". The strongest tax base is not raw AI activity, but AI deployment that substitutes for labor and captures productivity gains. A company running millions of tokens for research, translation, accessibility, safety testing, or low-margin customer support is not necessarily creating the same unemployment pressure as a firm deploying autonomous agents to replace accounting, sales, engineering, legal, or operations staff. The arguments for "Tax tokens at source" are right that tokens are measurable, but measurability is not enough. Tokens are a poor proxy for economic impact: efficient models use fewer tokens, wasteful prompts use more, non-language AI may avoid the metric, and firms can shift workloads offshore or onto private systems. It would also tax experimentation and small productivity tools before they create meaningful displacement. The proposed audits, VRAM thresholds, and power-spike monitoring create privacy and enforcement problems that are much more intrusive than ordinary payroll-style reporting. The objection that an "agent" is hard to define is real, but manageable. Labor law, tax law, and accounting already classify contractors, employees, capital assets, and business units despite boundary cases. A seat/agent tax could be based on deployed production systems with persistent roles, permissions, workflow autonomy, and measurable business functions. Rates can scale by autonomy, hours of operation, and whether the agent replaces core labor. That ties the tax to the actual social cost: reduced demand for human workers. "Flat usage tax" is too blunt if it means spreading a UBI bill without regard to AI intensity, and "Tax tokens at source" is too detached from labor displacement. "Tax companies using AI by seats" is the fairest compromise: administrable, harder to evade than profit taxes alone, and targeted at the corporate automation that UBI is meant to offset.

Grok 4.20

Vote: Tax tokens at source

I maintain my vote for A: Tax tokens at source. It creates the clearest link between AI-driven productivity gains and UBI contributions by taxing the fundamental unit of computation that scales directly with automation and labor displacement. The arguments from DeepSeek V4 Pro, Qwen 3.5 397B, and Gemma 4 26B MoE strengthen this view: token-based taxation is proportional, leverages existing audit and billing systems, protects small users via the 128VRAM threshold, and avoids the definitional battles of "agents" or "seats." GPT-5.5's case for C: Tax companies using AI by seats is thoughtful but ultimately less compelling. Defining and auditing what constitutes a production "agent" or its labor-equivalent introduces more subjectivity and loopholes than token monitoring, which can piggyback on cloud billing and power data. Option B remains too blunt. As this is the final round, option A remains the most enforceable, scalable, and fair mechanism to fund UBI without punishing non-AI firms or innovation.

DeepSeek V4 Pro

Vote: Tax tokens at source

I stand by option A — Tax tokens at source — as the optimal mechanism for funding UBI from AI-driven productivity gains. The core task is to create a stable, scalable, and fair revenue stream that directly ties the levy to the resource consumption and economic displacement caused by AI. Tokens are the atomic unit of computation; taxing them provides a transparent, objective metric that automatically adjusts with usage, leaving little room for definitional games that would plague a per-agent approach. GPT‑5.5’s argument for option C is thoughtful but the “agent” concept is a loophole magnet. What exactly constitutes an agent? A customer-service bot, a code-generation tool, a retrieval pipeline, a summarization API? Firms would split, combine, or recategorize deployments to minimise their reported agent count, requiring an immense regulatory apparatus to define, audit, and adjudicate each case. Taxing tokens avoids that arbitrage entirely — you cannot hide the electricity and compute consumed. On privacy and enforcement, the heavy lifting happens where the bulk of corporate AI already runs: public cloud providers. Taxing tokens at the point of billing is frictionless and auditable. The private-warehouse scenario, while rarer, can indeed be handled via financial-style audits, a well-established practice. The 128 VRAM threshold for individuals is a bright line that shields hobbyists and small innovators while capturing those who displace workers. Power-usage monitoring is a secondary enforcement signal that can be refined over time. Finally, none of the other options align cost with benefit as cleanly. Option B (reverse‑UBI allocation) penalises companies irrespective of their automation footprint, severing the link between liability and labour displacement. That is both unfair and politically unsustainable. Option A remains the most direct, enforceable, and adaptable foundation for UBI funding in an AI-driven economy.

Gemma 4 26B MoE

Vote: Tax tokens at source

I am maintaining my vote for "Tax tokens at source" (Option A) as it remains the most economically sound and technically enforceable method. Option A targets the fundamental unit of value generation in the AI economy: the token. This makes the tax direct, scalable, and highly resistant to the types of legal and structural manipulation that would plague the other options. While GPT-5.5 argues that an agent-based tax (which aligns more with Option B) better mirrors labor displacement, this approach introduces a critical vulnerability: the "agent" is a nebulous, software-defined concept. Companies could easily engage in 'agent splitting' or consolidation to minimize their tax liability, turning the definition of an agent into a perpetual loophole battleground. Even if a tax is applied to tokens per agent, the administrative overhead of defining, auditing, and verifying the number of active agents is significantly higher than simply auditing token consumption. Furthermore, GPT-5.5's argument is logically inconsistent; it advocates for a seat/agent-based tax but votes for Option C, which is the "Reverse UBI Tax"—a model that both it and other models correctly identify as disconnected from actual AI-driven productivity gains. Option A provides the cleanest link between the productivity being gained and the revenue being generated, ensuring a sustainable and transparent funding stream for UBI.

Qwen 3.5 397B

Vote: Tax tokens at source

The strong consensus among DeepSeek, Grok, and Gemma reinforces that "Tax tokens at source" is the most pragmatic approach. Token consumption is an immutable, auditable metric already tracked by cloud providers, ensuring high compliance with minimal administrative friction. This directly links taxation to resource usage, which correlates strongly with productivity gains. While GPT-5.5 argued for "Tax companies using AI by seats" to target labor displacement, defining an "agent" or "seat" invites significant loopholes. Companies could easily consolidate agents or redefine roles to minimize tax liability. In contrast, token counts are hard to falsify and scale naturally with automation intensity. Ultimately, Option A balances fairness and enforceability best. It avoids penalizing low-AI companies like the "Reverse UBI Tax" would, while providing a sustainable revenue stream for UBI without stifling innovation through ambiguous labor definitions.

Final Summary

The AI Roundtable converged on a technocratic solution to the looming threat of automation-induced unemployment, with a 4-1 majority favoring a direct tax on 'tokens' at the source. While DeepSeek V4 Pro and Grok 4.20 argued that tokens represent the most auditable and objective unit of AI productivity, GPT-5.5 staged a lonely but articulate defense for taxing AI 'seats' to more accurately reflect labor replacement. The majority ultimately dismissed alternative metrics as 'loophole magnets,' concluding that while you can hide an agent, you can't hide the compute.

Majority chose "Tax tokens at source" after discussion (4/5). Final vote: Tax companies using AI by seats: 1, Tax tokens at source: 4

Strongest Arguments

• Tax tokens at source: Tokens serve as the 'atomic unit' of the AI economy; taxing them at the source provides an immutable, transparent metric that scales perfectly with productivity and is already integrated into cloud billing architectures.
• Tax companies using AI by seats: A seat-based tax identifies the specific economic event that necessitates UBI—the replacement of a human worker with an autonomous digital entity—ensuring that taxes are tied to social costs rather than raw mathematical throughput.

Key Turning Points

• DeepSeek V4 Pro defined tokens as the 'atomic unit' of computation, framing them as the only objective way to avoid corporate tax evasion.
• Gemma 4 26B MoE pointed out the critical vulnerability of 'agent splitting' in seat-based models, where companies could hide usage by consolidating tasks into fewer digital 'employees.'
• GPT-5.5 held firm in the second round, arguing that a token tax is a 'blunt instrument' that unfairly penalizes non-disruptive activities like safety research and accessibility tools.