By the time Deepgram moved to Claude Enterprise in mid-2026, its engineers had already made their own arrangements. Some were using personal API keys and others were paying for Claude Max subscriptions.
Now Anthropic offers administrators a lot more control over Claude Code. Think managed permissions, model access, and audit records. As you’d imagine a company using Claude Code alone can handle a lot of its administration there.
Add a background coding agent running in CI against the same repository with requests going to another model provider. The Claude admin console can still account for Claude usage despite finance needing the cost of the whole workflow.
Claude Enterprise already covers the basics
Claude Code doesn't need a gateway to stop an engineer connecting whichever MCP server they find useful. Anthropic's managed settings can restrict MCP connections, tool permissions and file access. Engineers can still have their own local configuration, but they can't override those managed restrictions.
The spending side is more developed than it used to be, too. When the platform team is working through a large migration while most application developers use Claude Code for smaller fixes, it wouldn't make much sense to give everyone the same allowance. Anthropic lets admins set consumption limits at organization, group and individual level, including pooled group budgets. Model availability and defaults can be managed centrally as well.
There's also the question of what happens once people are using it regularly. An admin might want to see which teams are consuming the most tokens, whether spending is increasing or how much a particular model is being used.
Anthropic provides usage analytics and enterprise audit and compliance capabilities, while Claude Code can export usage, cost and tool activity through OpenTelemetry.
We wouldn't add another gateway just to recreate these controls. If Claude Code is the main coding agent across the company, there's already quite a lot you can manage through Anthropic itself.
Limits of agent-specific controls
The same repository can be used by Claude Code, a CI agent, and an internal engineering tool all at once.
If source code from a particular repository is allowed to go to certain models or providers, it means that keeping that restriction inside Claude Code only covers one of those paths.
We always see teams finding themselves in situations where they aren’t entirely sure if the CI agent has its own API key or another internal tool got configured elsewhere.
Claude Code and other supported workloads can route their model requests through Orq.ai's Gateway instead of each keeping a separate provider connection. That only changes the model path and it's important to remember that Claude Code still runs shell commands, edits files, and uses local tools on the developer machine.
Those actions don't suddenly become part of the gateway just because the model traffic passes through it.
Connecting Claude Code to Orq.ai's Gateway
Claude Code can be started through Orq with:
orq launch claude
It still opens Claude Code on the developer’s machine. But for that run the Anthropic base URL points at the Orq.ai Gateway and Claude’s model slots are filled from the workspace. The setup is useful if you don’t want to leave the machine permanently configured that way.
You can see what Orq.ai is about to pass in before launching anything:
orq launch claude --dry-run
And the output you get includes the:
Command
Environment
Model mappings
MCP configuration path
ANTHROPIC_BASE_URL is one of the more useful lines to check because it shows where Claude’s model traffic is going.
In our experience, the model mappings are worth a look too. They come from the workspace so an old screenshot can easily show a different lineup from the one actually enabled now.
Workspace skills are linked for the run and removed again when Claude exits, yet the Orq.ai MCP server is attached by default. If the machine is supposed to stay connected rather than borrow that setup for one session, that’s what orq connect is for.
Claude Code’s own flags still work through the launcher:
orq launch claude -- -p "summarize yesterday's failed traces"
Anything after -- is passed on to Claude Code.
The same pattern works for headless use, and CI can authenticate with ORQ_API_KEY instead of an interactive login.
Economics of a Claude Code session
Claude Code can burn through a very different amount of tokens depending on what the session is doing.
A common predicament teams end up is thinking that a quick fix is the right choice because of how cheap it is.
Yet a long run that keeps reading files, calling tools and carrying a lot of context forward is a different story.
If we use Sonnet 5.5 as an example, the current API rates are $2 per million input tokens and $10 per million output tokens. The standard five-minute cache write costs $2.50 per million, while cache reads cost $0.10.
A session with 500,000 uncached input tokens, 500,000 cache-write tokens, 5 million cache reads and 100,000 output tokens would come to:
500K uncached input: $1.00
500K cache writes: $1.25
5M cache reads: $0.50
100K output: $1.00
Total: $3.75
That example is only there to show how the bill is built, and it says nothing useful about an “average” Claude Code session.
Caching starts to matter quickly in a longer agent run, because earlier context doesn't disappear after the first request. Anthropic gives the example of a 40-turn task where the first turn is effectively sent 40 times as the conversation grows. In its SWE-bench Pro measurements, repricing Sonnet 5.5 runs without the cache discount made them about 3.1 times as expensive.
On Anthropic's current usage-based Enterprise plan, the seat covers access and model usage is billed separately at API rates. API-based deployments can also be charged through the Anthropic or cloud account providing the model access.
Developer-level budgets miss the bigger picture
One engineer can generate Claude Code spend for several completely different things in the same week.
Monday might be incident work for one product, Tuesday a platform migration, then the rest of the week goes into a feature owned by another team. A monthly number against that engineer’s name doesn’t tell finance much about which work actually consumed it.
Claude Enterprise can already put limits around the organization, groups and individual users, including pooled group budgets. Anthropic has also started adding project tag attribution for supported project-scoped Enterprise usage.
It gets harder to fully understand and have a good overview of bigger picture once the same work produces model traffic outside Claude as well.
Orq.ai can attribute routed requests at scopes like project or provider which means the person making the request and the work paying for it don’t have to collapse into the same number.
Smartsheet took the reporting side a step further. Rather than leaving token consumption as its own metric, it connects usage with code written, pull requests merged and code deployed. More than 500 engineers there use Claude Code.
The hidden cost of switching models
You might find yourself in a situation where the Claude Code session is already 100,000 tokens deep on Opus.
The next step looks easy enough for Haiku. Moving that request to the cheaper model feels like the logical choice to take and the one that makes the most sense. As a session grows, earlier conversation, tool definitions, and other context can be reused at the much lower cache-read rate rather than processed again as fresh input.
Switch models halfway through and that cache doesn't simply move with the conversation.
The cheaper model might have to process a large amount of context again before it can answer the supposedly cheap request.
One study of roughly 10,000 coding-agent sessions even found cases where the highest-priced model became cheaper overall than the tier below it once long, tool-heavy sessions were repriced. Control the Harness, Control the Cost In a modeled 10,000-seat enterprise, the approach reduced model spend by 14–21% which is equivalent to 3.3 million - 5 million a year at the Anthropic prices used in the study.
Bear in mind those are modeled savings and not the results of an enterprise deployment.
For teams routing coding-agent traffic through a gateway, that puts an important constraint around model routing. The cheapest available model isn't automatically the cheapest place to send an active agent conversation.
Sometimes the useful routing decision happens before the session starts rather than halfway through it.
Reconstructing what happened after an agent run
A change has already merged when someone notices it shouldn’t have.
“Claude Code was involved” isn’t much of an audit trail.
Security wants to know who started the session and what they asked for.
Engineering needs the files and commands that followed.
The model route matters too if source code went to the wrong provider.
Claude Code exposes much of the session through OpenTelemetry. API request events include the model, token usage, cost and latency while other events record tool results, permission decisions and session identity. Prompts and tool details are available when the relevant telemetry settings are enabled.
But there’s a difference between recording that Claude asked to run a command and proving everything that command did on the machine. File changes, spawned processes, and network activity can sit in a different layer of telemetry altogether.
A tool event still doesn't prove what happened on the machine.
When Claude Code's model traffic runs through Orq.ai's Gateway, there is another record at the model layer. Routed requests are traced with details such as model, provider, token usage, cost and latency, alongside routing and policy information.
That trace records what happened at the model boundary, not everything that followed on the developer's machine.
Git and CI hold another part of the record: what changed, which checks ran, and what eventually made it into the build.
The rollout decision
Claude Code doesn’t need a separate control plane simply because it has reached the enterprise. If the deployment is mostly Claude Code, Anthropic already covers a lot of what teams used to build around it themselves.
The decision changes when the repository is no longer being touched by one agent through one provider. CI agents, internal tools and other coding systems can all generate model traffic around the same work.
That's also where the Software Factory model starts to matter. Multiple agents can contribute to the same delivery workflow, but their model traffic and audit records still need to be accounted for across the system.
We find that by then, keeping every tool inside its own budget, routing and audit boundary starts to make the engineering system harder to see as a whole.
You can start to consider a shared model layer if you find your enterprise at that situation not as a replacement for Claude Enterprise, but as infrastructure around the wider workload.
If your Claude Code rollout is reaching that point, book a demo to see what that shared layer can look like.
