Three developers, one AI budget line. The obvious solution is three consumer subscriptions — everyone gets their own seat, everyone gets their own quota, nobody argues. The less obvious problem is that a subscription seat and a shared API key solve different problems, and only one of them survives contact with a team.
This is the arithmetic I did when I moved a three-person team off seat-based plans onto a single gateway key.
What a seat actually buys
A consumer subscription for an AI coding tool is a per-person product. Seat, account, session history, quota. When three people each buy one, you pay three times for three private pools of capacity, and the pools do not talk to each other.
That last part is the issue. Work does not distribute evenly. On any given Tuesday one developer is running a refactor agent across 60 files while the other two are writing tests. Seat A's ceiling fires at 11am; seats B and C are at 20% utilisation. You can see the waste on the invoice and you cannot move it.
Published seat prices for the mainstream coding plans land anywhere from $20 to $200 per person per month depending on tier. Three seats is therefore somewhere between $60 and $600 a month — call it $60 for the cheap tier and $300 for the tier where the agent actually works.
The same team, metered per request
Here is the measurement side. Over a month, the three of us generated these weighted daily averages from gateway logs — one row per API request, weighted by model (Claude Sonnet class counts 2, Opus and GPT-6 Sol class count 3, DeepSeek 1):
| Developer | Weighted requests/day | What they do |
|---|---|---|
| A | 120 | agent-driven refactors, Sonnet class |
| B | 95 | test generation and review |
| C | 85 | scripts and docs, DeepSeek for cheap work |
| Total | 300 | 9,000 weighted requests/month |
Now price that against a request-metered gateway. APIClaw's tiers are monthly with a daily request quota that resets at 00:00 UTC, and the one relevant to this workload is Max at $59 for 1,500 requests a day — 20% utilisation, 80% headroom.
| Option | Monthly cost | Aggregate quota |
|---|---|---|
| 3 × cheap seat ($20) | $60 | 3 private pools, none shared |
| 3 × working seat ($100) | $300 | 3 private pools, none shared |
| 1 × shared key, Max tier | $59 | 1,500 weighted requests/day, pooled |
The shared key costs less than the cheap tier and one fifth of the working tier, and the quota is pooled rather than partitioned. When developer A needs 360 requests on refactor day — three times their average, which is a realistic spike and not a pathological one — they draw from a pool of 1,500 instead of hitting a personal ceiling at 500 that nobody else can top up.
$59 split three ways is $19.67 a person. That is the honest number, and it is the one to put in the budget spreadsheet.
The catch: a shared key is a shared blast radius
The pooling argument is easy. The operational cost of one key is real and it is not small, so here is what you have to build before you share anything.
Name the key after the human, not the team. One key per developer, all on the same account. That gives you per-person revocation — when someone leaves, you revoke one key and their gpt-6-sol access is gone by the next request, without rotating anything for the other two. A single shared secret string means everyone rotates in a bad hour.
# one key per person, same account, so per-person revocation is a one-click
export APICLAW_KEY_ALICE=...
export APICLAW_KEY_BOB=...
Attribute before you optimise. A gateway that logs per-request model and outcome answers "who used 40% of the pool" in week three. A seat-based tool usually will not.
Set the ceiling below the pool, not at it. If the pool is 1,500, agree a soft 900. The ceiling's job is to catch a runaway loop, not to enforce fairness between humans.
Keep the model choice in the code, not in a mood. A shared pool means one person's frontier-model habit is visible to everyone. Routing cheap work — summarising, docstrings, lint fixes — to a weight-1 model and reserving weight-3 models for planning is a two-line client change and the biggest lever on how long the pool lasts.
Where the single key genuinely wins beyond price
The argument that convinced my colleagues was not the invoice. It was that a gateway key is a plumbing decision, and a seat is a product decision.
With one key you can point any OpenAI-compatible tool at the same endpoint and get the same models without a new purchase: Continue in VS Code, Cline, Kilo Code, a shell script, a CI job that summarises a diff. Seat-based plans cover the tool they ship. If your team's work is spread across three editors and a couple of scripts, the seat model sends you shopping; the gateway model does not.
APIClaw is the flat-rate version of that: one key at https://apiclaw.biz/v1 covering Claude, GPT, Gemini, DeepSeek, Qwen, Kimi, GLM and the rest, request-metered rather than token-metered, and it also speaks Anthropic Messages for tools that expect that shape. The practical point for a small team is that the quota is an account-level pool with published request weights, so the "who is using the shared budget" question has a factual answer — see how the weights and tiers work before you size anything.
Payment is crypto via NOWPayments, which is worth naming early rather than discovering at checkout, and support is on Telegram rather than a ticket queue.
When a seat is the better buy
Three cases, honestly:
- One person, one tool, heavy use. A single $100 seat beats a $59 pool if that person alone would use 1,400 requests a day. The pool only wins when it is shared.
- You need the tool's own agent features. Seat plans bundle vendor-specific completions and agent modes that bring-your-own-key does not reproduce.
- You need zero ops. A shared key is one more thing to revoke, rotate and attribute. Sometimes that is not worth $241 a month.
But if the team is three people with varied workloads, spread across more than one editor, and one of you is regularly hitting a ceiling while the others are not, a request-metered gateway key is the structurally correct shape. Pooled capacity, one line on the invoice, one endpoint to point everything at. The one-key setup covers what the endpoint accepts and how to lay out keys per person without sharing a secret.
Run the numbers against your own logs first: sum your team's weighted requests per day, pick the tier that leaves 50–80% headroom, and compare that to seats × price. If the pool wins by less than 20%, stay on seats — the operational overhead is not free.
Top comments (0)