Keeping Marketers Away From Fable, or: How I Learned to Stop Worrying and Love AI Gateways
Model access control in Tetrate Agent Router Enterprise: route the desktop app through your gateway, find out who is spending the money, before capping the wrong people
This continues a series I’ve been writing on AI cost control. Token optimization for engineering leaders was about getting developer spend under control; reporting AI ROI to leadership was about proving the investment paid off. The people who made it work for engineering are now being asked to make it work for everyone else, and citizen AI builders such as marketers have to be part of the regime.
By David Wang, Head of Product, Tetrate
Strange week. I talked to three different companies, and all three described their problem in almost the same words: don’t let my marketers use Fable, it’s too expensive.
Happy to oblige, under protest. I like marketers, and I think they deserve Fable too. But the request keeps arriving, so here’s how Agent Router Enterprise meets it, and how the same setup works for every other group in your company.
Before we punish the innocent, get the data right first. Get the traffic onto your gateway, put people into teams, read the numbers, then change what the numbers tell you to change. Most people want to start at the last step. That’s how you cap the wrong team.
Instead, follow these steps to manage citizen AI builder cost on Tetrate Agent Router Enterprise.
Step 1: Understand Current Usage by Routing Claude Cowork Through Tetrate Agent Router Enterprise
Cowork sends model inference to whatever gateway Claude Desktop is configured for. You don’t want twenty marketers each pasting a base URL and a key into a settings dialog, so we built a command line tool that configures local clients such as Claude Desktop for them. Your users log in once and run a couple of commands. The tool writes the gateway entry, your Agent Router inference key, and the flag that makes the whole thing active on next launch. It checks the key against your catalog before it finishes, so a bad paste fails at setup instead of on someone’s first prompt. Commands and file paths are in the Claude Cowork guide.
If someone’s machine can’t run the CLI, they can enter the gateway URL, key, and headers into Claude Desktop’s third-party inference dialog by hand, using the values in that same guide.
Two constraints before you promise anyone a rollout date.
Cowork runs in gateway mode only. Your Agent Router inference key authenticates every request, and inference bills through Agent Router. Passthrough mode keeps a Claude Max or Pro subscription as the billing path while your gateway routes and watches the traffic. It works for Claude Code and not for Cowork. Anyone hoping to keep a personal subscription and still look compliant is out of luck.
Claude Desktop has to have launched once on the machine. The CLI writes into a user-data directory the app creates on first run, and it reports auto-config unavailable when that directory is missing.
Step 2: Create Teams So Every Dollar Has an Owner
In the Admin Console, go to Directory → Teams and select Add team. The New Team wizard asks for a name, an optional description, and your initial members.
The name is the only required value, and it’s the label that shows up in every cost report you run later.
Name each team after the unit that owns the budget. Marketing and Platform mean something to the finance owner reading your cost report. Your internal abbreviations don’t, and renaming a team later changes how its historical usage is labeled.
Eight teams, each with its user count. Compare that count against the team’s share of spend once you get to Step 3.
Membership is exclusive. A person belongs to one team at a time, and selecting someone who already belongs elsewhere moves them out of their old team, along with any access that team granted them. The Review step counts those moves before it applies them, and that count is the number to read carefully.
Then go look at whoever belongs to no team. That’s where your contractors and service accounts sit, and their spend has no owner until you map them.
Teams group people for access and reporting. Your boundary for models, keys, and policy is the project.
Step 3: Read Usage Analytics Before You Cap Anything
Open Usage → Analytics, pick a range, and open the Team filter. It’s multi-select, so two or more teams sit side by side with one color each. Select No team assigned at least once while you’re in there.
Your selections stay pinned at the top while you search, so you can find a team in a directory of hundreds.
This is the part of the conversation I like.
I don’t know how those three companies’ charts came out. I do know what these charts usually show. Your marketing team is small and runs a handful of sessions a day. Your engineering team is large and runs coding agents, and one agent request fans out into dozens of model calls before it comes back. The group spending the money is rarely the group anyone names in the first meeting. Go look at yours before you touch anything.
| What your chart shows | What it means | What to do next |
|---|---|---|
| A team at 40% of spend and 40% of headcount | Proportional consumption | Nothing. This team isn’t your finding |
| A team at 40% of spend and 8% of headcount | The conversation you thought you were having | Move to Step 4 on that team’s keys |
| High cost on low tokens for one model | A premium model serving small volume | Your candidate for substitution |
| A large No team assigned row | Contractors or service accounts nobody mapped | Fix your directory before you set any limit |
Pick a second selection and the chart splits into one series each. This one compares two users; the Team filter works the same way.
You can separate Cowork traffic from everything else the same person runs. The integration sends X-Title: Claude-Cowork and X-Provider: Tetrate AgentRouter on every request, and both show up in Request Logs. That settles the next question your chart raises: did a team’s spend come from the desktop app, or from a coding agent on the same key?
Cowork requests carry their own headers, so desktop usage and coding-agent usage stay separable in one view.
Two cautions before you take the numbers to anyone. Your filters live in the page URL, so a link reproduces your exact view for whoever asked the question. A filter you forgot about from an earlier session also lands in your CSV export. Second, spend is calculated from tokens and published model prices, not read off your provider invoice. For a baseline and a direction that’s fine. For chargeback that moves real money, your negotiated rates and committed-spend agreements pull the two figures apart.
Step 4: Four Ways to Control What One Team Spends
Once your chart names a group, you have four controls, running from watching to acting. Three are budget actions and one is a routing rule, and they work together on the same key.
| Watch spend | Hard stop | Model substitution | Degrade gracefully | |
|---|---|---|---|---|
| What triggers it | Spend passing your monthly amount | Spend hitting the cap | Every request on the key, always | Spend reaching your amount |
| What happens then | You get an alert. Nothing is blocked | Requests are rejected until the month resets | The expensive model is swapped for a cheaper one | Requests keep serving on a cheaper model |
| Scope | A team, each teammate, one person, a project, or an API key tag | Same | One API key | Same as the other budget actions |
| Caps your spend | No | Yes | No | No |
| Where you set it | Policies → Budget | Policies → Budget | Traffic splitting on the API key | Policies → Budget |
Watch spend alerts you when a team passes its monthly amount and blocks nothing. Start here. It costs a team nothing and it tells you the size of the argument you are about to have before you have it.
Hard stop rejects requests once the cap is hit, until the month resets. It is the only one of the four that caps your spend, and it is also the one that stops someone mid-campaign. Keep it behind the softer controls. Pair it with a rate limit on the same key, which the gateway enforces inline on tokens, requests, and parallel calls. The budget answers how much this team spent this month. The rate limit answers how fast this key may consume right now.
Model substitution swaps one model for another on a key, whatever you have spent. You set it with traffic splitting, putting 100% of the weight on the cheaper model. It changes what each request costs without setting any ceiling.
This is the one almost everyone I talk to is actually asking for, so the rest of this section double-clicks on it before covering the budget action.
Degrade gracefully is the more sophisticated version of model substitution. Instead of taking the expensive model away on day one, you let the team spend up to a budget first, and the swap happens only once they reach it. Requests keep serving on the cheaper model, so nobody hits a wall.
Most deployments end up with a mix. Production keys sit on watching and degrading, because a sudden block cascade is the wrong failure mode for an application customers depend on. Research, evaluation, and CI keys get the hard controls, because a runaway there is more annoying than a rejection.
Model Substitution: Send 100% of the Weight to a Cheaper Model
You configure model substitution through traffic splitting, which is its own section on an API key. Turn on the toggle, pick the model your users call, and set a weight for each model you want serving it. Your weights have to total 100.
Fable stays as the name the calling code asks for, at a weight of zero. Sonnet 5 takes every request.
Substitution is a split with the weights pushed to one end: 100% on the cheaper model, zero on the expensive one. Cowork keeps asking for Fable, Fable sits at zero, and Sonnet 5 serves the traffic. Nobody edits a Cowork setting, and nobody files a ticket with you.
Weight changes reach your gateway in under a minute and apply to every request after that. Turning the split off is one toggle. This is the easy thing to reverse when the team pushes back on you.
Two limits. A substitution covers every request on that key, so you can’t route only the routine requests to the cheaper model. And it lowers what each request costs you while setting no ceiling on your total.
Degrade Gracefully to a Cheaper Model When the Budget Is Spent
A budget is an amount of money for one calendar month, a scope whose spend that amount covers, and what happens when the spend reaches it. You set all three in Policies → Budget.
| Part | Values |
|---|---|
| Amount | US dollars per month, with presets from $100 to $10,000 |
| Scope | A whole team on one shared pool, each teammate on the same individual limit, one person, a project, or an API key tag |
| When the limit is hit | Watch spend, hard stop, or degrade gracefully |
Degrade gracefully keeps serving over the cap and reroutes to a cheaper model. A team reaches keys in several projects, so each project gets its own target.
This is model substitution with a condition attached. Substitution swaps the model on every request from the day you set it. Degrading waits until the team has spent the amount you agreed, then makes the same swap. Marketing keeps Fable while the budget lasts and keeps working on a cheaper model after it runs out, and nobody loses access in the middle of a campaign.
Start on watch spend. It alerts you when the team passes the amount and blocks nothing, which tells you the size of the argument you’re about to have before you have it.
The Nuclear Option: Leave the Model Out of the Project Catalog
Models are granted per project. If Fable isn’t in your marketing project’s catalog, no key in that project can call it. There’s no weight to tune, no budget to keep in step, and no fallback list to reason about.
Two models linked to this project, both enabled. Fable is not among them, so no key here can call it.
Use this when your decision is settled and not coming back up. Substitution and degrading are for when it isn’t.
Give the Model Back When Your Chart Says So
With analytics and monitoring, you can find the right source before deciding whether to take the best models away from a team.
And when marketing turns up at 3% of your organization’s spend, keeping them off Fable stops being an argument about money. Take that one up with your CFO. I’m on marketing’s side.
Availability and How to Get Started
The Claude Cowork integration, teams, Usage Analytics, traffic splitting, and budget policies are available today in Tetrate Agent Router Enterprise.
Start with the Claude Cowork guide, or request an enterprise trial.
Frequently Asked Questions
How do I stop one team from using an expensive model?
Three controls, in increasing order of bluntness. Model substitution on that team’s API keys, a traffic split weighted 100% to the cheaper model, which changes the model on every request. A budget set to degrade gracefully, which changes the model once that team’s spend reaches your number. Or leaving the expensive model out of the project catalog, which removes access entirely.
Does Claude Cowork work with a Claude Max or Pro subscription through the gateway?
No. Cowork through Agent Router runs in gateway mode only, and inference bills through Agent Router. Passthrough mode, which keeps a Claude Max or Pro subscription as the billing path while your gateway routes and observes the traffic, is supported for Claude Code and not for Claude Cowork.
Can I tell Claude Cowork traffic apart from Claude Code traffic?
Yes. The Cowork integration sends X-Title: Claude-Cowork and X-Provider: Tetrate AgentRouter on every request, and both appear in Request Logs next to the resolved model and the cost of the call.
What’s the difference between model substitution and a budget set to degrade gracefully?
Model substitution decides which backend serves each request regardless of what you’ve spent, and it is set on one API key. A budget set to degrade gracefully changes the model once the month’s spend reaches your amount, and it can cover a whole team. Use substitution for traffic that should sit on a cheaper model all month. Use degrade for traffic that can stay on the expensive model until the money runs out.
Does degrading gracefully stop spending when the budget is exhausted?
No. Degrade gracefully switches the model and keeps serving. The spend after the switch is still spend, and it still counts against the same scope. A hard stop behind it is what gives you an actual ceiling.
Can I give one agent more room than the rest of its team?
A budget on that agent’s API key gives it its own amount. The agent’s spend still counts toward its owner’s allowance, so the owner’s other keys stop once the agent has used up that owner’s share. Raise the owner’s amount alongside it to keep their other work running.
Related: Announcing token brokering in Tetrate Agent Router Enterprise, on enforcing spend policy in the request path across a distributed fleet.