An engineering team does not buy a room because it wants one. It buys a room because two things happened in the same year: the price of its coding tools stopped being a seat and became a meter, and the contract with its largest client turned out to forbid the meter's other end. This note takes the two in order, says what a pod actually serves, is plain about the model it serves it with, and answers the payback question in words rather than in numbers we cannot yet cite.
The bill became visible
For three years a coding assistant cost what a seat cost. On 27 April 2026 GitHub announced that from 1 June every Copilot plan would bill on usage: credits consumed by tokens, input, output and cached, at the published API rate of the model chosen. A Business seat stayed at $19 a month with $19 of credits; beyond that an administrator sets a budget or the work stops, and the fallback to a cheaper model when the allowance ran out was withdrawn. The Information reported that Cursor's gross margin was negative 23% in the quarter ended January 2026, at a company approaching $2 billion of annualised revenue: the frontier models underneath cost more than the subscriptions above them.
What usage pricing makes visible is how much a working engineer consumes. Forbes reported in May that Uber, having put Claude Code in front of about 5,000 engineers, had spent its 2026 AI budget in four months, with heavy users running $500 to $2,000 a month each. Microsoft's Experiences and Devices division, at roughly the same scale and per-engineer range, told its teams by internal memo that licences would end on 30 June; under flat seat licensing the token cost had been invisible, and under usage billing it became visible at once. McKinsey's August 2026 survey of 1,719 organisations found one in five already naming operating cost as a constraint on further AI use.
The self-hosted answer
The market's first response was the one it always gives to a volatile bill: bring the machine home. Tabnine's July 2026 price list is instructive less for the numbers, $39 a user a month for the assistant and $59 for the agentic platform on annual terms, than for what sits beside them: SaaS, VPC, on-premises or fully air-gapped, you choose where your code lives, and the compute is customer-provided unless you pay the vendor to host it. The software vendor sells the seat; the customer brings the accelerators. That line, customer-provided compute, is what we sell: a pod in the building the team already occupies, on the board that already feeds the floor, with the weights and the index inside it.
Why the MSA, not the statute, drives the Indian buyer
In India the reason is contractual, and a buyer who expects a statute to fence code will look for one and not find it. The Digital Personal Data Protection Act defines personal data as data about an identifiable individual; source code is not that, and section 16 restricts transfers only to countries the Centre notifies, of which as of mid-2026 there are none. Nothing in the statute stops a developer in India sending a client's repository to an assistant hosted abroad.
The client's master services agreement does. A bank's or a hospital group's MSA with an engineering-services firm typically forbids processing client code by any third party not on the approved sub-processor list, requires SOC 2 evidence and, for anything touching card systems, PCI DSS, and reserves the client's right to audit. Where the client is a bank or an NBFC, the Reserve Bank's Directions on Outsourcing of Information Technology Services of 2023 flow down through that MSA: their scope names application development, maintenance and testing; they require storage of data in India as applicable, a right to audit the provider and its sub-contractors, and unrestricted access to the data and the relevant business premises. A vendor whose engineers pipe the bank's code through an assistant in another country has created an outsourcing the bank never approved. So the security team blocks the tool and the engineers lose it. The room gives it back with an address the MSA can carry: this model, this index, on this machine, in this building.
What a pod serves
A pod for an engineering organisation has the same two shifts as any other room.
| Day | Night | |
|---|---|---|
| Work | Completions, chat, codebase questions, review, test generation | Batch review of the day's merges, test generation, migrations, re-indexing |
| Bound by | Latency per keystroke and per question | Throughput of long agent jobs |
| Model class | A small fast model for completions; a larger open-weight coder for review and answers | The largest open-weight coder the pod holds, at large batch |
By day the pod serves completions, which are latency-bound and want a small fast model; chat and codebase question-answering, which are retrieval-bound and want an index of the whole repository, not the sanitised part that cleared a legal review, updated as commits land; review; and test generation. By night it takes the batch work a usage meter makes expensive: a review pass over everything merged that day, test generation across untouched modules, migrations and refactors run as long agent jobs, and the re-indexing that keeps the day's answers fresh. A codebase index and the models that read it fit comfortably in 1,536 GB, and a job whose parts talk to each other mid-step must never cross a building boundary; the pod is the unit of contiguity. A room that serves only the day is a room half used, and the modelled utilisation our unit economics rest on assumes the night is real.
The model tier, said plainly
The models that fit on eight accelerators and serve a team at interactive latency are a tier below the frontier on the long agentic tasks that generate the largest bills, and developers will notice. We would rather say that here than have it discovered in an evaluation.
The consequence is a division of labour. The long agent task a frontier model does better stays with the cloud tool the team already has, on the code the client has agreed may leave the building, and the meter for that lane stays visible. The gap between the tiers has narrowed every quarter we have watched it, and we pin every model version and index snapshot so an auditor can reproduce what the pod did on the day.
The payback question, in words
A buyer's bill today has two parts: seats, which are predictable, and usage above the seat, which is not, and which the reporting above suggests can be many times the seat. A room can carry the work behind both under one proposal, based on the team's workload and deployment, with a separate usage line for the frontier lane that stays with the cloud tool. Whether that comes out ahead depends on two things the buyer controls and we do not. The first is how many engineers share the pod: a pod is sized for one engineering organisation, and a team too small to fill it pays more per seat than it should, which is why we sell to organisations of the size that fills one. The second is how full the night is: a pod that runs the batch shift earns the modelled utilisation; a pod that sleeps at seven does not. We will not print a payback period, because the only honest inputs are the buyer's own headcount and the buyer's own night. What we offer instead is a comparison of quality and total cost on the team's own repository, against what the team pays today, before anyone decides.
What we will measure before quoting
Before a quote we will run the team's own repository through a pod and measure token consumption by task class; completion and codebase-answer latency at the team's concurrency; batch throughput on the night jobs; retrieval quality on the team's own questions; and the energy the work draws at the meter. Then the proposal is based on the team's workload and deployment, night shift included, with quality and total cost set beside what the team pays today.
That is why an engineering team buys a room. The meter made the bill visible, the contract forbade the meter's other end, and the room is the only place where the code, the index and the model can all sit in the building the MSA names.