AI coding agents have become a core part of how developers write, debug, and refactor software. Open weight models on Amazon Bedrock now make these agents practical to run privately and cost-effectively. But most options require you to send your proprietary data to a third-party API, lock you into a single model provider, or charge per-seat subscriptions regardless of how much you use them. If you have data residency requirements, cost-sensitive workloads, or a need for model flexibility, these constraints create real friction.
What if you could run an AI coding agent that keeps your data in your own AWS account, switches between frontier open weight models on demand, and charges only for what you consume?
OpenCode is an open source, terminal-native AI coding agent built in Go. It reads and edits files, runs shell commands, and understands project structure through Language Server Protocol (LSP) diagnostics. It connects to over 75 large language model (LLM) providers including Amazon Bedrock. When you pair OpenCode with open weight models on Bedrock, you get a coding assistant that runs locally while inference happens securely within your AWS account. There’s no infrastructure to manage and no per-seat fees.
In this post, we show you how to set up OpenCode with open weight models on Amazon Bedrock, configure multi-model workflows that match the right model to each task, and walk through practical coding examples using Moonshot AI Kimi K3, OpenAI GPT-OSS 120B, and NVIDIA Nemotron 3 Super 120B. We also share how Ethara.AI deploys this architecture in production with multi-agent orchestration to power AI engineering and research workflows at scale.
Why open weight models for AI-assisted coding
The industry is shifting toward open weight models. According to McKinsey’s Open-source technology in the age of AI report (2025), 76 percent of organizations expect to increase open source AI usage, and leading AI adopters are 40 percent more likely to use open weight models. For coding workloads, five factors drive this shift:
Performance parity: Fine-tuned open weight models can outperform proprietary alternatives on domain-specific tasks. CrowdStrike’s fine-tuned NVIDIA Nemotron achieved 96% valid query accuracy, outperforming GPT-4o (61%) and Claude Sonnet 4.5 (94%).
Cost efficiency: According to Gartner’s 2026 analysis, agentic workflows multiply token consumption 5–30x, making cost-per-token critical. At scale, on the order of multimillion conversations per month, switching to open weight models on Bedrock can reduce annualized costs.
Customization and control: Open weights support fine-tuning, distillation, and domain adaptation. Smaller models can replace expensive general-purpose ones while maintaining quality.
Model flexibility: With open weights, you can adopt the right model for each task and evolve as new ones emerge. Switching models is a single API parameter change on Amazon Bedrock.
Transparency: Inspectable model architecture and behavior supports regulated industries with AI governance requirements.
Why Amazon Bedrock as the backend
Amazon Bedrock provides fully managed, serverless access to open weight models. There’s no GPU provisioning or inference infrastructure to manage. For enterprise coding workflows, Bedrock offers several advantages over self-hosting or direct model providers:
Data residency and compliance: Code, prompts, and responses stay in your AWS account. Models accessed through an in-Region or geographic profile run in that Region or geography. You can invoke Kimi K3 through a cross-Region inference profile. For workloads without regional restrictions, we recommend using the global profile, global.moonshotai.kimi-k3, which routes each request to any supported commercial AWS Region worldwide. Global cross-Region inference costs approximately 10% less than a geographic profile. The US geographic profile, us.moonshotai.kimi-k3, keeps processing within the US geography for data residency requirements. Amazon Bedrock is in scope for common compliance programs including HIPAA, SOC 2, ISO 27001, FedRAMP, and GDPR. For the full list, see AWS services in scope by compliance program.
Enterprise security controls: Open weight models inherit the same AWS Identity and Access Management (IAM) policies, AWS CloudTrail logging, AWS PrivateLink connectivity, and encryption controls as proprietary models. No separate security stack required.
Flexible pricing: Three tiers match cost to workload: Priority for latency-sensitive production, Standard for on-demand inference (pay per token), and Flex at 50 percent lower cost for variable-latency workloads.
No model training on your data: Bedrock doesn’t use your inputs or outputs to train or improve foundation models (FMs).
High default capacity: Default limits of 100M tokens per minute and 10K requests per minute help reduce throughput bottlenecks as teams scale.
Choose the right model for the task
Not every coding task needs the same model. One of the key advantages of using OpenCode with Bedrock is the ability to select and switch between models based on what you’re doing.
Where to evaluate models: The Artificial Analysis Coding Index provides a composite benchmark across real-world software engineering tasks (SWE-Bench, Terminal-Bench, SWE-Atlas). Use it to compare model performance, cost per task, and latency. For evaluations against your own prompts and data, you can use Amazon Bedrock Evaluations to run side-by-side comparisons with automatic scoring, LLM-as-a-judge, or human review.
Considerations beyond raw performance
- Reasoning depth: For complex debugging, architecture decisions, or plan generation, reasoning models trace through problems step by step. Kimi K3 reasons before answering. You set the depth with
reasoning_config(low, high, or max). You trade latency for correctness on hard problems. - Generation speed and latency: For code completion, boilerplate generation, and interactive pair programming, lower latency matters more than peak reasoning. NVIDIA reports that Nemotron 3 Super 120B delivers up to 7x higher throughput thanks to its Mixture-of-Experts architecture that activates only 12B of 120B total parameters per token.
- Cost per token: For high-volume workflows (batch refactoring, large codebases), cost compounds. Open weight models on Bedrock offer lower per-token pricing than proprietary alternatives.
- Context window: Kimi K3 supports a 1M-token context, roughly tens of thousands of lines of code. You can load a whole repository rather than a handful of files for cross-file reasoning.
- Regional availability: Check which models are available in your target Region. This matters for data sovereignty and latency requirements.
For this post, we feature three models that cover the spectrum:
| Model | Strength | Best for |
| Moonshot AI Kimi K3 | Always-on reasoning with a 1M-token context | Debugging, architecture analysis, complex logic |
| OpenAI GPT-OSS 120B | Frontier code generation (120B parameters) | Full-service generation, multi-file implementations |
| NVIDIA Nemotron 3 Super 120B | Optimized throughput, enterprise-validated | High-volume generating workloads |
Solution overview
The architecture has two parts: OpenCode runs as a terminal user interface (TUI) on your local machine and calls the Amazon Bedrock Converse API for inference. Bedrock hosts the models as fully managed, serverless endpoints.
Figure 1: Solution architecture for OpenCode with open weight models on Amazon Bedrock. The developer interacts with OpenCode in the terminal, which sends requests through the Bedrock Converse API to open weight models. AWS IAM authenticates each request, and AWS CloudTrail logs API activity
OpenCode’s agent architecture supports assigning different models to different roles: a reasoning model for planning and a faster model for code generation. This creates a multi-model workflow within a single session.
Prerequisites
Before you start, make sure you have:
- An active AWS account with Amazon Bedrock access enabled.
- Model access granted for Kimi K3, GPT-OSS 120B, and NVIDIA Nemotron 3 Super 120B in the Amazon Bedrock console.
- AWS credentials configured (IAM access keys, AWS IAM Identity Center, or a Bedrock API key).
- Node.js 18+ (for the npm install method) or Homebrew (for macOS/Linux).
Install and configure OpenCode
This section walks through installing the OpenCode CLI and configuring it to authenticate with Amazon Bedrock.
Install OpenCode
Choose one of the following methods:
Verify the installation:
Configure AWS credentials
OpenCode’s Bedrock provider uses the standard AWS credential chain. Configure one of the following options:
Option A: AWS IAM Identity Center (recommended for enterprise)
Option B: IAM access keys
Replace these with your own credentials. For production use, prefer IAM Identity Center or IAM roles over long-lived access keys.
Option C: Bedrock API key
You can also store these in a .env file in your project root for persistent configuration.
Configure a multi-model workflow
With OpenCode’s agent system, you can assign different models to different roles. Create or edit opencode.json in your project root:
This configuration routes planning and architecture tasks (which benefit from deep reasoning) to Kimi K3, while code generation and implementation go to Nemotron 3 Super 120B for optimized throughput. The top-level model field sets GPT-OSS 120B as the default for other context.
To browse available Bedrock models interactively, launch OpenCode and enter /models.
Code with open weight models
The following examples show how to match each model to the kind of task it handles best.
Generate an event-sourced order service with GPT-OSS 120B
GPT-OSS 120B is OpenAI’s 120-billion parameter open weight model. It combines strong reasoning with code generation, making it well-suited for architecturally complex implementations that span multiple files. With the multi-model configuration from the previous section, you can override the default model inline or use /model to switch explicitly:
OpenCode routes this to GPT-OSS 120B through the Bedrock Converse API with IAM authentication. The model generates the full service structure, including handlers, event store, projections, and CDK stack, directly into your local file system. CloudTrail logs the invocation, and your prompts and responses remain within your AWS account.
Diagnose a distributed deadlock with Kimi K3
Kimi K3 excels at reasoning tasks that require tracing through multiple execution paths. It reasons on every turn, and the reasoning_config field sets how deep the reasoning goes: low for quick passes, max for the hard ones. If you configured Kimi K3 as your plan agent, it’s already the default for analysis tasks. You can also switch explicitly with /model:
The @file references inject your local code as context without manual copy-paste. Kimi K3’s Mixture-of-Experts architecture activates only 104B of its 2.8T total parameters per token, delivering frontier reasoning at efficient throughput. You watch the model trace through the concurrency paths live. Because the reasoning is visible, you can judge whether the analysis holds before accepting the proposed fix.
Switch models mid-session
You don’t need to commit to a single model. Enter /models during a session to switch. A practical pattern: use Nemotron 3 Super 120B or GPT-OSS 120B for fast code generation and boilerplate, then switch to Kimi K3 when you hit a complex debugging problem or need to reason about architectural trade-offs.
With the multi-model opencode.json configuration shown earlier, this routing happens automatically. The plan agent uses Kimi K3 for reasoning, while the build agent uses Nemotron for implementation.
Reduce costs on batch coding tasks with Flex tier
Some coding work is interactive. Batch refactoring across a large codebase, generating test suites for existing modules, or producing documentation from code. These tasks are latency-tolerant and can run asynchronously. The Amazon Bedrock Flex tier offers 50% lower cost than Standard for these workloads.
You can combine this with OpenCode’s CLI mode to script batch operations:
Stack your tiers: Standard for interactive sessions, Flex for batch processing, and Priority for latency-sensitive production use.
Scale to multi-model routing architectures
The OpenCode + Bedrock pattern shown in this post is a single-developer workflow. For teams and production systems, the same multi-model principle extends to a routing architecture where an orchestrator directs each sub-task to the optimal model:
Figure 3: Multi-model routing architecture using open weight models on Amazon Bedrock. A router analyzes incoming requests and dispatches sub-tasks to the optimal model tier to help reduce total cost of ownership compared to routing all tasks through a single model
In this pattern:
- Intent classification routes to a low-cost model (small, fast inference).
- Code generation routes to a mid-tier open weight model optimized for throughput.
- Complex reasoning (architecture decisions, security analysis) routes to a premium reasoning model.
This routing can help reduce overall total cost of ownership (TCO) compared to sending everything through a single expensive model without degrading quality. The Amazon Bedrock unified API makes this practical: switching models is a parameter change, and the models share the same authentication, logging, and guardrails infrastructure.
For teams ready to go beyond single-developer use, combine OpenCode’s local agent routing with a server-side orchestration layer (Amazon Bedrock Agents or AWS Step Functions) to create a full multi-model coding pipeline.
Production deployment: Multi-agent orchestration at scale
Ethara.AI, an AWS customer, deploys this architecture in production, using OpenCode as the foundational runtime for AI engineering and research workflows. Oh-My-OpenAgent serves as the orchestration layer for working with specialized AI agents. Rather than relying on a single coding assistant, Ethara.AI operates a fleet of agents optimized for different tasks such as planning, execution, code review, architecture analysis, knowledge retrieval, multimodal understanding, and benchmarking. Through Oh-My-OpenAgent’s category-based routing system, engineers request a capability (such as deep reasoning, rapid execution, visual engineering, or writing assistance), and the system delegates the work to the most suitable agent. This abstraction helps teams focus on outcomes rather than model management, while maintaining flexibility across evolving AI frameworks.
Amazon Bedrock and OpenCode’s provider-agnostic architecture powers Ethara.AI’s model selection strategy. OpenCode supports access to a broad range of foundation models, while Amazon Bedrock provides secure access to frontier models. Instead of a single model, they dynamically route workloads based on factors such as reasoning complexity, latency requirements, cost efficiency, and task type. The combination of Amazon Bedrock, OpenCode, and Oh-My-OpenAgent helps them separate agent capabilities from the underlying model layer. This helps make sure that the most appropriate agent-model combination executes each task, while retaining the ability to evaluate and adopt new models as the model landscape evolves.
Looking ahead, Ethara.AI is investing in self-improving agent systems that draw on research such as SkillClaw. They are developing mechanisms that help skills and agent behaviors evolve based on successful and unsuccessful execution trajectories, creating an infrastructure where agents continuously improve through real-world usage. This vision builds on OpenCode’s extensible architecture, Oh-My-OpenAgent’s delegation framework, and the Amazon Bedrock model catalog to create AI systems that become more capable, adaptive, and efficient over time.
Security considerations for enterprise use
Open weight models on Bedrock inherit identical enterprise controls as proprietary models. The provenance of the weights doesn’t change your security posture. Restrict which models users can invoke with IAM policies that follow least-privilege:
You can further layer Amazon Bedrock Guardrails for content filtering and personally identifiable information (PII) redaction across invocations. CloudTrail records every InvokeModel call for audit, and Bedrock does not use your inputs or outputs to train models.
Clean up
This walkthrough doesn’t create persistent AWS infrastructure beyond model access enablement. If you enabled model access solely for testing, you can disable it in the Amazon Bedrock console under Model catalog. No other resources require cleanup, and you incur no charges when you’re not making API calls.
Conclusion
We showed how to configure OpenCode with open weight models on Amazon Bedrock to build a secure, flexible, pay-per-use AI coding workflow. You get the cost efficiency and customization potential of open weight models, the enterprise security and managed infrastructure of Bedrock, and a terminal-native experience that fits into existing developer workflows with the ability to route different tasks to different models automatically.
To get started, install OpenCode, configure your AWS credentials, and set up a multi-model configuration. Explore the full Amazon Bedrock model catalog to find models suited to your workloads, and use the Artificial Analysis Coding Index to compare model performance on coding tasks.
For more information about Amazon Bedrock security and compliance, refer to the Amazon Bedrock User Guide. If you’d like to discuss how Amazon Bedrock can support AI-assisted development in your organization, contact an AWS Representative.
About the authors
from Artificial Intelligence https://ift.tt/w3FKYpr
