Claude Code Alternatives: change the model, the harness, or the vendor.

Claude Code introduced a lot of developers to agentic coding. Before it, AI coding mostly meant code generation: a completion, a suggested edit, a function scaffolded from a comment. Claude Code, and Opus in particular, showed that a developer could lean back, give instructions, and let the model do the hard work across files, tests, and tools.

Since then, three problems have surfaced for enterprises. Cost: the flat subscription stops at 150 seats on the Team plan, and above that usage is billed at API rates, so the bill scales with token volume rather than headcount. (Claude plans) Access: for nearly three weeks in June 2026, every customer lost Claude Fable 5 when a US export-control directive forced Anthropic to suspend it, a reminder that a single-vendor pipeline can stop without notice. Exposure: engineering leaders are increasingly uneasy sending their codebase to a vendor that may one day compete with them.

This article reviews three alternatives. Each uses the same published rates, checked September 5, 2026, so the cost arguments are comparable. Option 1: keep Claude Code, change the model behind it. Option 2: change the harness, keep choosing models. Option 3: add a second vendor and budget both.

Option 1: keep Claude Code, change the model behind it

Claude Code is a harness on top of a model. The terminal tool, the permission system, the tool loop, and the context management are the harness; the model is whatever answers the Messages API call. Anthropic supports bring-your-own-key, so the model can be served from somewhere other than Anthropic’s own API. (Claude Code enterprise deployment)

Route through AWS when AWS is where the money is

The simplest swap keeps the model Anthropic and moves the billing. Claude Code supports Bedrock deployments, so a team with AWS credits or an Enterprise Discount Program commitment to exhaust can run the same Claude models with inference, access controls, procurement, and billing inside AWS. Using AWS does not require replacing the developer’s coding tool.

Bedrock also offers supported OpenAI models. AWS lists GPT-5.6 Sol, with in-region availability through its Mantle endpoint in Northern Virginia and Ohio. For short-context Sol requests, AWS lists $4.40 per million input tokens and $22 per million output tokens for in-region or geographic cross-region inference; its global cross-region rates are $4 and $20. Model availability and capabilities vary by endpoint and region. (AWS GPT-5.6 Sol model card)

Check the API features your agent actually uses. Direct OpenAI and Bedrock have different feature coverage, even when they expose the same model family. If your requirement covers the entire coding workflow, place its gateway, execution environment, and logs on AWS too. (OpenAI’s Bedrock deployment guide)

Put a router in front and change the model entirely

The larger move is an LLM gateway: a service that speaks the Anthropic Messages API to Claude Code and translates each request to a different provider behind it. Claude Code believes it is talking to Fable or Opus; the gateway is talking to GLM-5.3 on Nebius. The harness does not change. The developer’s configuration does not change. What changes is the model, the bill, and where the code is processed.

This works because open-weight models have closed most of the gap on agentic coding. GLM-5.3 has posted benchmark results close to Anthropic’s flagship on coding tasks; DeepSeek-V4-Pro and Kimi-K3 cover similar ground. Nebius Token Factory makes these models accessible through managed inference with an OpenAI-compatible API and dedicated deployment options, and adds releases to its catalog as they ship, so a team can evaluate newer models without rebuilding a GPU serving platform each time.

The current catalog includes GLM-5.3-Flash, Kimi-K3, DeepSeek-V4-Pro, and DeepSeek-V4-Flash-0731. The precise GLM name matters: the verified entry is GLM-5.3-Flash, rather than an unsuffixed GLM-5.3. (Nebius model catalog) The catalog should move quickly; production upgrades should remain deliberate. Pin the selected model, evaluate replacements on your own repositories, and roll them out to a small cohort before changing the default. Nebius documents that public endpoints have no guaranteed processing region; use a dedicated endpoint when a fixed region is a requirement. (Nebius inference documentation)

Compatibility is the implementation work. Anthropic Messages, OpenAI Responses, and Chat Completions have different semantics. Validate tool calls, streaming, conversation state, and error handling for each supported client. Keep a session on a tested model configuration; make any escalation explicit and account for the additional calls.

Open weights against Anthropic: the price gap

The reason to go through this trouble is the price gap. This comparison uses 50 requests, each with 20,000 input tokens and 4,000 billable output tokens: one million input tokens and 200,000 output tokens in total. It compares API token charges, not subscriptions or equivalent completed coding tasks.

Read the Anthropic rows against the Nebius rows. Claude Opus 5 costs $10.00 for the workload. DeepSeek-V4-Pro costs $2.45, about a quarter. GLM-5.3-Flash costs $0.25 and DeepSeek-V4-Flash-0731 $0.196, a fortieth to a fiftieth. Models that now post results close to Opus on coding tasks sit at a quarter of its token bill, and the Flash tiers well under a tenth. Kimi-K3 at $6.00 is the exception: it costs more than Sonnet 5, so an open model does not automatically mean a lower token bill. Claude Sonnet 5’s $2/$10 rates are now its standard prices. (Current Anthropic pricing, Nebius catalog)

The calculation is input price + 0.2 × output price. It assumes uncached input and standard processing, with no cache writes, tools, hosting, platform fees, discounts, or taxes. OpenAI requests exceeding 272,000 input tokens have different rates; the individual requests here stay below that threshold. Billable reasoning tokens belong in output usage. Actual tasks can tokenize differently and require different numbers of calls.

Option 2: change the harness, keep choosing the model

The second option separates the two purchases. Harnesses are now a category of their own: OpenCode is open source; Cursor is licensed; Codex and Claude Code are vendor-bundled. Choosing a harness on its own merits, its permission model, its sandboxing, its IDE and CI integration, its audit trail, lets an organization procure and roll out the tool once, then adopt models as they ship. (Harness engineering)

This also needs a router. Cursor lets you configure which models sit behind it. An internal gateway does the same for any harness, and adds what a single product cannot: budgets per model tier, per team, per repository, with usage attributed to the engineer and the actual target model.

A large enterprise we work with runs it this way. They define three aliases, an Opus-equivalent, a Sonnet-equivalent, and a Haiku-equivalent, and every team’s harness points at the alias, not the model. When a new state-of-the-art model ships, the platform team evaluates it on representative repository tasks, re-points the alias, and rolls it out by cohort. No developer touches a configuration file.

The diagram is the decision in one line: a coding platform is a harness times a model. The harness sets the security features, the workflow, and some of the intelligence: context handling, tool loops, how it recovers from a failed test. The model sets the rest of the intelligence and the completion rate. Buy them separately; couple them through the gateway.

Option 3: add a second vendor and budget both

OpenAI lagged Anthropic on agentic coding for a while. It no longer does. Codex, now shipped inside ChatGPT with a CLI, a desktop app, and IDE integrations, is a capable harness, and the current model line is state of the art:

• GPT-6 Astra is OpenAI’s most capable model, positioned for difficult work spanning reasoning, coding, and tool use. It is a candidate for complex debugging and changes that require substantial investigation. (Astra model documentation)
• GPT-5.6 Sol is the flagship GPT-5.6 tier. The API alias gpt-5.6 resolves to Sol. It is a useful candidate for a team’s general coding workload. (Sol model documentation)
• GPT-5.6 Terra targets a balance of capability and cost. Evaluate it where a lower inference bill could justify a different performance profile. (Terra model documentation)
• GPT-5.6 Luna targets high-volume, cost-sensitive work. Consider it for tightly scoped tasks with clear acceptance checks. (Luna model documentation)

Instead of standardizing every developer on one tool, give them two and set a budget on each. The large vendors compete with each other on features and price at a pace no internal platform team can match; a two-vendor policy lets an organization collect that competition instead of betting against it. The gateway attributes spend to the engineer and the target model, so the budget is enforceable rather than aspirational.

Two pricing details belong in the budget. Sol’s current $4 input / $20 output pricing is promotional and available at least through November 21, 2026; projections should carry that date. (Sol pricing details) And Sol is also available through Bedrock at the in-region rates above, so the AWS route from Option 1 applies to OpenAI models as well.

What a routed mix actually costs

Consider an illustrative month with 10,000 calls, each containing 20,000 input tokens and 4,000 billable output tokens. Route 70% to DeepSeek-V4-Pro on Nebius, 20% to direct GPT-5.6 Sol, and 10% to direct GPT-6 Astra.

That mix costs $1,063 in API token charges: $343 for DeepSeek, $320 for Sol, and $400 for Astra. The same token volumes would cost $2,000 on Claude Opus 5 or $800 on Claude Sonnet 5.

The mixed deployment is therefore 46.85% below the Opus baseline and 32.875% above the Sonnet baseline, before gateway operation, implementation, retries, tool execution, and developer review. This is a calculation from published rates, not a measured TensorOps customer result or a claim of equal task quality.

Use a repository evaluation to measure cost per accepted change: total model, platform, execution, and review cost divided by accepted changes. Compare acceptance rate and completion time alongside spend. A routing mix earns its place when it improves those outcomes for your workload.

How to decide

The right option depends less on the models than on the organization. Four questions settle most of it:

1. Infrastructure readiness. Can you run a gateway, attribute usage, and evaluate models on your own repositories? If the answer is yes, and the volumes are large, the next question is whether to self-host the models rather than rent them.
2. Buy or build. A buy organization takes Option 3 and lets the vendors compete. A build organization takes Option 1 or 2 and owns the routing layer, because it is the part that compounds.
3. Privacy and security needs. Where can code be processed, which vendors are approved, and what audit trail is required? An AWS-only requirement points at Bedrock; a no-external-vendor requirement points at self-hosting.
4. Willingness to use open-weight models. The strongest open-weight coding models today are mostly Chinese: GLM, DeepSeek, Kimi. Regulation in some sectors rules them out, which pushes toward Option 1 via Bedrock or Option 3.

TensorOps builds this infrastructure for customers: the gateway, the routing policy, the evaluation loop, and the attribution behind the budgets. Start with Option 1 when the team is already on Claude Code and the goal is the bill. Start with Option 2 when procurement wants to separate the harness from the model. Start with Option 3 when two vendors and two budgets is the fastest way to stop depending on one. (TensorOps coding infrastructure)