AI costs are exploding in teams that adopt it without governance. Request proxying, internal model deployment, automatic token optimisation: three concrete levers to regain control.
What AI providers present as accessible pricing hides a more complex reality. In 2025 and 2026, Anthropic, OpenAI and Mistral API prices have risen regularly β often quietly, masked behind offer restructurings or context window changes. Pricing models are evolving: fixed-credit subscriptions are giving way to more granular pay-per-use models, and developer "unlimited plans" are progressively tightening. What few teams realise: current pricing remains largely subsidised by venture capital. Providers are still burning billions to gain market share β the real inference cost price is significantly higher than today's bills. When valuations need to justify themselves, pricing will follow.
In this context, the 30 to 60% of tokens needlessly consumed in poorly governed teams β through verbose outputs, overly long contexts or wrong model choices β represents a tolerable waste today, and a real competitive handicap tomorrow. In 2026, the maturity of AI adoption requires a governance discipline that few teams have yet put in place.
Proxying: taking back control of API calls
The first step toward sound governance is visibility. Without an intermediary proxy, calls to Anthropic, OpenAI or Mistral APIs leave directly from tools β without centralised logging, without per-team measurement, without any possibility of caching or rerouting. Deploying an AI API proxy (LiteLLM, Kong, or an in-house gateway) in front of all AI consumption changes everything:
- Observability: every request is logged with its token cost, model, and initiator
- Semantic caching: similar requests return a cached result rather than querying the model
- Dynamic rerouting: a simple reformatting task goes to Haiku (5Γ cheaper than Opus), complex analysis to Sonnet or Opus
- Quotas per project or developer: prevent a single intensive use from consuming the team's monthly budget
The measured gain for teams that have deployed this type of gateway regularly exceeds 40% billing reduction, with no perceptible degradation in response quality.
Internal models: the local alternative for routine tasks
Not every AI use case justifies calling a cloud model. Simple code completion, reformatting, comment generation, technical translation β these repetitive tasks often represent the majority of token volume consumed, for a marginal return on investment compared to a local model.
Solutions like Ollama with open source models (Qwen3-Coder, CodeLlama, Mistral) allow deploying an internal AI in a few hours, without sending a single token externally. For an organisation subject to confidentiality constraints (client data, intellectual property), this is no longer an option β it's a necessity. The combination of local model for routine tasks / cloud API for complex ones halves the external bill in documented cases.
Platforms like OpenClaw or self-hosted stacks (Ollama + Open WebUI + specialised model) allow sharing this internal model across multiple teams, connecting the same tools (Claude Code via an alternative endpoint configuration, Cursor, Codeium) and controlling access. The initial investment β a few days of infrastructure and model validation β pays for itself quickly.
RTK: automatic CLI-level optimisation
Even with a proxy and an internal model, each Claude Code development session consumes tokens in CLI exchanges: outputs
from git, grep, docker or npm commands are often sent to the model in their entirety, including unnecessary
verbosity.
RTK (Rust Token Killer) inserts itself as a transparent shell-level proxy. All commands automatically pass through RTK, which filters outputs, truncates redundant logs and only transmits genuinely relevant information to the model. Depending on the initial verbosity of commands:
| Command | Measured gain |
|---|---|
Verbose git log / git diff |
β32% to β70% |
docker compose outputs / logs |
β60% to β97% |
| Maven/Gradle build results | β70% to β99% |
Installation is transparent: RTK configures itself as a hook in Claude Code (rtk gain to visualise savings achieved)
and requires no modification to existing prompts or workflows. Over a long session, cumulative savings are substantial
β and measurable in real time.
A discipline, not a tool list
AI usage rationalisation is not just a matter of tooling β it's a team discipline. Measure before optimising, choose the model suited to the task's complexity, avoid contexts that grow uncontrolled, restart a session rather than letting it drift: these habits save more than any plugin. The tools β proxy, RTK, local models β automate and reinforce these habits, but do not replace them.
Maintaining technical skills and codebase quality
The most insidious risk of AI-driven acceleration is not financial: it is the silent erosion of skills. A team that massively delegates code writing without cultivating a deep understanding of what it produces accumulates cognitive debt that is hard to measure β and expensive to repay. Skills management must become an indicator tracked as closely as velocity or test coverage: which architectural patterns does the team truly master? Which technical decisions can it justify without a model's help?
On the code quality front, AI-assisted acceleration demands more rigour, not less. Generated code bypasses the natural filters that manual writing imposes β searching through documentation, reading line by line, thinking through edge cases. It is therefore essential to:
- Maintain systematic code reviews, including β especially β on AI-assisted code
- Keep objective metrics on the codebase: test coverage, cyclomatic complexity, technical debt measured by static analysis tools
- Run collective understanding sessions (code walkthroughs, architecture reviews) so knowledge stays in people's heads, not just in prompt history
- Practice coding without an assistant on certain critical features, to maintain the technical muscle
AI can multiply a team's production capacity. It cannot replace the craftsperson's judgement about why one solution is preferable to another, nor the expertise that detects a security flaw in syntactically correct code. In 2026, the competitive advantage no longer goes to teams that use AI β almost everyone does. It goes to those who simultaneously maintain non-negotiable technical standards.
β See also: AI risks: data security Β· AI risks: capitalisation Β· AI in software development