Hello, this is Ryuta Hamamoto from TIMEWELL. Claude Code, Codex, Grok Build. Over the past year, coding agents that write code autonomously inside a terminal, run the tests and tidy the documentation have become standard equipment in development teams. We use several of them every day ourselves. But as they became more useful, they also became heavier. Hand one a task and it calls the model dozens of times behind the scenes, reads the codebase and iterates. The result is that token bills are turning up on management agendas at month-end in a growing number of companies.
This piece is about how to bring that cost down. To state the conclusion first, there are five levers. Switch the model the agent connects to. Use an open-source agent. Use open-weight models. Use a domestic serverless inference service. And put GPUs inside the company. Each comes with facts you can confirm in official documentation and pitfalls you only discover by trying. Honestly, no single one solves everything. That is why the piece ends with the idea that ties them together, an AI gateway that "cuts cost while keeping data in-country", explained for readers coming to it fresh. If you would like to check where your company's AI adoption stands first, our AI readiness assessment is a good place to start.
Why agents are expensive: how tokens are counted
First, why coding agents cost more than chat, from the mechanics. AI model usage is billed in "tokens". Think of roughly one token per Japanese character, or about four English characters per token. Both what you send the model (input) and what it returns (output) carry a unit price, and on most models output is priced around five times higher.
A single chat question uses a few thousand tokens in and out. Agents are different. Say "fix this bug" and the agent reads the relevant files, runs the tests, reads the results, writes a fix and tries again. Each time, it resends the conversation so far and the file contents as input. Hundreds of thousands of tokens are routine; a large job can run into the millions.
Let me confirm unit prices from the official price lists. Anthropic's Claude Opus 5 is 5 dollars per million input tokens and 25 dollars per million output tokens. Claude Sonnet 5 is 2 and 10 dollars. Claude Haiku 4.5 is 1 and 5 dollars. The top-end Claude Fable 5.1 is 10 and 50 dollars1. xAI's Grok 4.6 is 2 dollars in and 6 dollars out, and its coding-specific grok-build-0.1 is 1 dollar in and 2 dollars out2. Suppose ten developers each use five million input tokens and half a million output tokens a day on Opus 5: 25 dollars of input plus 12.5 dollars of output, times ten, is 375 dollars a day, 7,500 dollars over twenty working days, roughly 1.12 million yen a month at 150 yen to the dollar. That is what "token bills on the management agenda" looks like.
The same price list also describes the discounts. With prompt caching, the input price for repeated content drops to one tenth of the base rate, and routing work that can wait through the Batch API halves both input and output1. Before changing models, the first question is whether you have used up the discounts on the model you already have. For Claude Code specifically, see our guide to optimising Claude Code enterprise pricing.
Lever 1: switch the model the agent connects to
The first lever is to keep using the agent while changing the model it calls behind the scenes. Here it matters to separate "technically possible" from "officially supported".
OpenAI's Codex CLI supports switching officially. Add a model_providers.<id> entry to the config file with base_url pointing at the API and env_key naming the environment variable that holds the API key, and it connects to any compatible API. There is also an --oss flag: set oss_provider to ollama or lmstudio and it switches to a local model running on your own machine3. Codex CLI, in other words, was built from the start to run on models other than OpenAI's.
xAI's Grok Build also documents custom models officially. Create a [model.my-model] section in ~/.grok/config.toml, give it model (the model ID), base_url and env_key, and set it under [models] as default, and that model becomes the default4. Grok Build itself is relatively new, released in May 2026, and is characterised by running up to eight sub-agents in parallel and by this freedom in where it connects.
Anthropic's Claude Code is a somewhat different case. Its documentation has a section titled "Other LLM gateways" describing how to route through a gateway your organisation runs via the ANTHROPIC_BASE_URL environment variable. The benefits listed are keeping credentials off developer machines, tracking usage per developer, managing budgets and rate limits in one place, audit logging, and switching providers without touching developer machines. But the same page says this in plain terms: "Anthropic doesn't endorse, maintain, or audit third-party gateway products, and doesn't support routing Claude Code to non-Claude models through any gateway"5. Connecting, on the far side of a gateway, to a different model that speaks an Anthropic-compatible API is technically workable, but it is unsupported territory.
My summary: switching the connection is an official feature in Codex CLI and Grok Build, and an unofficial use of an official gateway feature in Claude Code. Either way, if the model you switch to does not support the tool-calling format the agent uses internally, behaviour becomes unstable. "I connected a cheaper model and it stopped editing files" is a common complaint, and the cause is almost always tool-call compatibility rather than model capability.
Struggling with AI adoption?
We have prepared materials covering ZEROCK case studies and implementation methods.
Lever 2: use an open-source agent
The second lever is to replace the agent itself with an open-source one. Two stand out.
OpenCode is an open-source coding agent available as a terminal interface, desktop app or IDE extension, and its documentation states that "you can use any LLM provider by configuring their API keys"6. It is not tied to any model vendor, so switching models is the premise rather than an afterthought.
Hermes Agent, published by Nous Research under the MIT licence, has gathered more than 240,000 stars on GitHub. Its README says "Use any model you want — Nous Portal, OpenRouter, OpenAI, your own endpoint, and many others", switchable with a hermes model command and no code changes7.
Open-source agents used to carry the worry of "who is responsible?" Agents rewrite files and execute commands, so the damage from a runaway is large. Here, Hermes Agent's official security documentation goes quite far. It isolates agent commands from the host in sandboxes such as Docker, Modal or Daytona, dropping privileges in Docker with --cap-drop ALL. Writes to ~/.ssh, ~/.aws, ~/.kube, /etc/sudoers, ~/.netrc and to the agent's own credentials and .env files are blocked unconditionally, and writes can be confined to specified directories. Dangerous commands are risk-assessed by an auxiliary LLM in the default "smart" mode, and even in the prompt-skipping YOLO mode, catastrophic operations such as rm -rf / remain hard-blocked. URL-handling tools carry SSRF protection that blocks internal networks and cloud metadata endpoints. Environment variables passed to MCP child processes are kept to a minimum, and API keys in error messages are redacted automatically8. Responsibility still sits with the user, but "what is protected" has reached the point where you can verify it in writing.
The practical reason to choose an open-source agent, I think, is less the cost itself than keeping the choice of model in your own hands. When the agent vendor is also the model vendor, there is no room to negotiate over price rises or spec changes. Separate the agent from the model, and you benefit immediately when the market price of models falls.
Lever 3: use open-weight models
The third lever is to make the model itself an open-weight one. An open-weight model is one whose internals (weights) are published, so anyone can download it and run it in their own environment. By 2026 the major sources are all present: Kimi, GLM, MiniMax, Qwen and DeepSeek from Chinese labs and companies, NVIDIA's Nemotron, Google's Gemma, OpenAI's gpt-oss.
The advantage of open weights is that the model's origin and the place it runs can be separated. A model built by a Chinese company running on a Japanese provider's servers, with the data never leaving Japan. Or running on your own GPUs so the traffic never leaves the building. Both configurations work. Conversely, if you use an open-weight model through its maker's own API, it is no different from any other cloud model as far as data destination goes. Not "open weights, therefore safe", but "open weights, therefore you can choose where it runs". That is the accurate framing.
A second advantage is resilience against the supplier's decisions. Cloud models can change in performance at the provider's discretion, and older models get retired. With the weights in hand, you at least avoid "what worked yesterday does not work today". I wrote about this in silently downgrading a model is a matter of trust.
Cost, though, is not set by the model's price alone. With open weights it is set by the price of wherever you run them. The next two levers are about that "where".
Lever 4: use domestic serverless inference
The fourth lever is to use so-called serverless inference services, where a domestic provider offers open-weight models as an API. In the United States, companies such as Fireworks AI and Together AI built this category; the same type of service is now appearing in Japan.
The leading example is "Sakura AI Engine", which Sakura Internet made generally available in September 2025. Its official site says everything completes inside domestic cloud with no data sent outside, and it offers OpenAI-compatible Chat Completions and Responses APIs as well as an Anthropic-compatible Messages API. Models include OpenAI's gpt-oss-120b and the Japanese llm-jp-3.1, with Qwen3, Phi-4, Kimi-K2 and gemma-4-31B-it among others in preview. Pricing for gpt-oss-120b is 0.15 yen per 10,000 input tokens and 0.75 yen per 10,000 output tokens, and the free plan allows 3,000 Chat Completions requests a month9.
Set these figures beside Claude Opus 5. Per million tokens, gpt-oss-120b costs 15 yen in and 75 yen out. Opus 5 costs 750 yen in and 3,750 yen out at 150 yen to the dollar. On unit price alone the gap is fiftyfold. The models are of course not equally capable; for complex design decisions or large refactors the top model can end up cheaper overall. But routine code generation, test scaffolding, log summaries and commit messages do not need the top model every time. Routing by type of work alone changes the shape of the invoice.
That Sakura AI Engine offers an Anthropic-compatible Messages API matters when combined with lever 1. It makes it technically possible to point Claude Code's ANTHROPIC_BASE_URL at a gateway and have the gateway route certain kinds of work to a domestic open-weight model. To repeat: this is a use Anthropic does not support5. Even so, as a path to cutting cost while keeping data inside Japan, it belongs on the list of options. For the overall picture of which models run in Japanese regions, see our guide to whether LLMs can run in domestic regions.
Lever 5: put GPUs inside the company. The reality of on-prem and local LLMs
The fifth lever is to own GPUs and run models inside the company. In the past year this has become realistic. NVIDIA's DGX Spark has 128 GB of unified memory, runs inference for models up to 200 billion parameters on a desktop and supports fine-tuning up to 70 billion parameters, according to its official page, which positions it as a machine that lets "agents and large models run locally, reducing the need for cloud-based token generation resources"10. More developers are running open-weight models on Mac Studio machines with large memory, and some companies go further and install servers with several data-centre GPUs on site.
The advantages of on-prem are clear: the per-token price goes to zero, and data physically never leaves the building. For teams handling drawings or customer data, the second is usually decisive.
But three weaknesses show up in practice. First, web search and integration with external tools. Cloud agents come with the whole flow, including search and document lookup, optimised by the provider; locally you assemble it yourself, and the quality gap there is what users feel. Second, speed. The same model produces output more slowly on one machine on your desk than on thousands of GPUs in parallel in the cloud, and because an agent calls the model dozens of times, each delay compounds. Third, operations. Model updates, driver and runtime management and hardware failures become somebody's job. Tokens may be free; staff time and electricity are not.
My view is that on-prem is not "do everything here" but "bring the work that cannot leave the building here". Work that needs the newest model goes to the cloud; confidential work stays inside. Doing that routing by hand always leaks, so you need a mechanism. That is the next section.
The AI gateway that ties the five levers together and keeps data in-country
Each of the five levers is incomplete on its own. Switching models saves money, but the best model differs by task. Open weights are free to move, but mean nothing until you decide where to run them. Domestic serverless is cheap and stays in-country, but does not deliver top-tier capability. On-prem is safe, but slow and heavy to operate. What pulls these into a single policy is an AI gateway.
An AI gateway is a relay server placed between agents or applications and models. Listing Anthropic's documented benefits again: centralised credentials, usage tracking per developer, budgets and rate limits in one place, audit logging, and switching providers without touching developer machines5. For a company, the real value is that this is where rules live. A rule that requests containing drawings go only to domestic models. A rule that commit message generation goes to the cheapest model. A rule that overnight batch work flows through the half-price Batch API, and that a given department may use the newest model until it exceeds its monthly budget, then switches to a domestic one. Rules like these are set once, company-wide, rather than in each developer's settings.
This is exactly the state we call "AI with data sovereignty": the company decides for itself which data is computed where and stored where, and can explain it. Cost optimisation and data control look like separate problems, but they are solved in the same place, the gateway. We run our enterprise product ZEROCK in AWS's Japan region, with models pinned to the domestic region through Amazon Bedrock. Some of the newest models infer in global regions, but customer data is never used for retraining. As an extension of that design, we are also developing a gateway for companies that want to run internal AI agents continuously and keep automation going, one that cuts cost while keeping data in-country. Companies moving from "trying" agents to "running them every day" are the ones that need this component. For a secure Bedrock-based configuration, our piece on gateway design for Claude Code Enterprise via Bedrock and Vertex is a useful companion.
Closing: decide the routing before you cut the price
Cutting the cost of coding agents is not as simple as swapping in one cheaper model. Have you used up the discounts on the model you have? Can you switch the agent's connection through an official method? Do you take the choice of model back into your own hands with an open-source agent? Where do you run open-weight models? Which tasks do you assign to domestic serverless and to in-house GPUs? Putting these in one place as company policy, rather than as individual workarounds, is what a gateway does.
The facts confirmed in this piece, in brief: Codex CLI and Grok Build offer connection switching officially, while Claude Code documents gateway routing officially but states that non-Claude models are unsupported. Open-source agents such as Hermes Agent now document their sandboxing and blocked write paths. Providers such as Sakura AI Engine offer both OpenAI-compatible and Anthropic-compatible APIs inside Japan, with gpt-oss-120b output at 75 yen per million tokens. And machines like DGX Spark run 200-billion-parameter models on a desk. The ingredients are there.
If you do one thing this week, split your agent usage into three buckets, work on data that cannot leave the building, work that needs the newest model, and work where a cheap model is enough, and estimate the share of each. That alone shows which lever to pull first. If you would like to discuss routing rules or the foundation for running agents continuously inside your company, reach out through our consultation form. We will listen first, then design the setup together.
References
Prices and specifications are from official documentation as of 12 September 2026. Yen conversions use a rough rate of 150 yen to the dollar.
Footnotes
-
Pricing — Claude Platform (Anthropic official documentation) ↩ ↩2
-
Introducing Grok 4.6 — xAI (grok-build-0.1 pricing: Grok Build 0.1 on API — xAI) ↩
-
Configuration Reference — Codex (OpenAI official documentation) ↩
-
Grok Build: overview — xAI Docs (launch: Introducing Grok Build — xAI) ↩
-
Other LLM gateways — Claude Code (Anthropic official documentation) ↩ ↩2 ↩3
-
Sakura AI Engine — Sakura Internet (Japanese) (general availability: press release of 24 September 2025 (Japanese)) ↩
