在 Amazon Bedrock 上使用开放权重模型作为 AI 编程 Agent

AI 编程 Agent 已成为开发者编写、调试和重构软件的核心工具。Amazon Bedrock 上的开放权重模型如今使得这类 Agent 能够以私有且具成本效益的方式运行。但大多数方案仍要求你将专有数据发送至第三方 API、将你锁定在单一模型提供商，或无论实际使用量多少都按席位收取订阅费用。如果你有数据驻留要求、对成本敏感的工作负载，或需要模型灵活性，这些限制会带来切实的阻碍。

如果你能够运行一个 AI 编程 Agent，让数据保留在自己的 AWS 账户中、按需在前沿开放权重模型之间切换，并且只为实际消耗的资源付费，会怎样？

OpenCode 是一个使用 Go 构建的开源、终端原生 AI 编程 Agent。它可以读取和编辑文件、运行 Shell 命令，并通过 Language Server Protocol（LSP）诊断理解项目结构。它可连接包括 Amazon Bedrock 在内的 75 多家大语言模型（LLM）提供商。当你将 OpenCode 与 Bedrock 上的开放权重模型配对时，就能获得一个在本地运行、而推理在 AWS 账户内安全执行的编程助手。你无需管理基础设施，也无需支付按席位费用。

本文将介绍如何在 Amazon Bedrock 上使用开放权重模型设置 OpenCode，配置让合适模型匹配相应任务的多模型工作流，并通过 Moonshot AI Kimi K3、OpenAI GPT-OSS 120B 和 NVIDIA Nemotron 3 Super 120B 展示实际编程示例。我们还将分享 Ethara.AI 如何在生产环境部署这一架构，并借助多 Agent 编排大规模支持 AI 工程和研究工作流。

为什么为 AI 辅助编程选择开放权重模型

行业正转向开放权重模型。根据 McKinsey 的《AI 时代的开源技术》报告（2025），76% 的组织预计将增加开源 AI 的使用，而领先的 AI 采用者使用开放权重模型的可能性高出 40%。对于编程工作负载，五项因素推动了这一转变：

**性能可比性：**经过微调的开放权重模型可在特定领域任务上超越专有替代方案。CrowdStrike 微调的 NVIDIA Nemotron 实现了 96% 的有效查询准确率，超过 GPT-4o（61%）和 Claude Sonnet 4.5（94%）。

**成本效率：**根据 Gartner 的 2026 年分析，Agent 工作流会将 Token 消耗放大 5–30 倍，因此每 Token 成本至关重要。在每月数百万次对话量级的大规模场景下，切换到 Bedrock 上的开放权重模型可以降低年化成本。

**定制与控制：**开放权重支持微调、蒸馏和领域适配。在保持质量的同时，较小的模型可以替代昂贵的通用模型。

**模型灵活性：**借助开放权重模型，你可以为每项任务采用合适的模型，并随着新模型出现而持续演进。在 Amazon Bedrock 上切换模型只需更改一个 API 参数。

**透明度：**可检查的模型架构和行为有助于满足受监管行业的 AI 治理要求。

为什么选择 Amazon Bedrock 作为后端

Amazon Bedrock 提供对开放权重模型的全托管、无服务器访问。无需预置 GPU，也无需管理推理基础设施。对于企业级编程工作流，相较于自行托管或直接使用模型提供商，Bedrock 具有多项优势：

**数据驻留与合规：**代码、提示词和响应均保留在你的 AWS 账户中。通过区域内或地理配置文件访问的模型会在对应区域或地理范围内运行。你可以通过跨区域推理配置文件调用 Kimi K3。对于没有区域限制的工作负载，我们建议使用全局配置文件 global.moonshotai.kimi-k3，它会将每个请求路由至全球任何受支持的商业 AWS 区域。全局跨区域推理的成本大约比地理配置文件低 10%。美国地理配置文件 us.moonshotai.kimi-k3 会将处理限制在美国地理范围内，以满足数据驻留要求。Amazon Bedrock 已纳入 HIPAA、SOC 2、ISO 27001、FedRAMP 和 GDPR 等常见合规计划的适用范围。完整列表请参阅 按合规计划划分的 AWS 服务适用范围。

**企业安全控制：**开放权重模型与专有模型一样，继承相同的 AWS Identity and Access Management（IAM） 策略、AWS CloudTrail 日志记录、AWS PrivateLink 连接能力和加密控制。无需单独部署安全技术栈。

**灵活定价：**三种层级使成本与工作负载相匹配：面向延迟敏感型生产环境的 Priority、面向按需推理的 Standard（按 Token 付费），以及面向可变延迟工作负载、成本低 50% 的 Flex。

**不使用你的数据训练模型：**Bedrock 不会使用你的输入或输出训练或改进基础模型（FM）。

**较高的默认容量：**默认每分钟 1 亿 Token 和每分钟 1 万次请求的限额，有助于在团队规模扩大时减少吞吐瓶颈。

为任务选择合适的模型

并非每项编程任务都需要相同的模型。将 OpenCode 与 Bedrock 结合使用的一项关键优势，是能够根据当前任务选择和切换模型。

在哪里评估模型：Artificial Analysis Coding Index 针对真实软件工程任务（SWE-Bench、Terminal-Bench、SWE-Atlas）提供综合基准。你可以用它比较模型性能、单任务成本和延迟。若要针对自己的提示词和数据进行评估，可使用 Amazon Bedrock Evaluations 运行并排比较，并结合自动评分、LLM-as-a-judge 或人工审核。

除原始性能外的考量因素

• 推理深度：对于复杂调试、架构决策或计划生成，推理模型会逐步追踪问题。Kimi K3 会在回答前进行推理。你可通过 reasoning_config 设置推理深度（low、high 或 max）。对于困难问题，你需要以更高延迟换取更高正确性。
• 生成速度与延迟：对于代码补全、样板代码生成和交互式结对编程，较低延迟比峰值推理能力更重要。NVIDIA 表示，得益于其 Mixture-of-Experts 架构——每个 Token 仅激活总计 120B 参数中的 12B——Nemotron 3 Super 120B 可提供最高 7 倍的吞吐量。
• 每 Token 成本：对于高容量工作流（批量重构、大型代码库），成本会不断累积。Bedrock 上的开放权重模型提供比专有替代方案更低的每 Token 定价。
• 上下文窗口：Kimi K3 支持 100 万 Token 上下文，约相当于数万行代码。你可以加载整个代码仓库，而非仅加载少量文件，以实现跨文件推理。
• 区域可用性：请确认目标区域中可用的模型。这对于数据主权和延迟要求十分重要。

本文重点介绍覆盖不同能力范围的三种模型：

模型	优势	最适合的场景
Moonshot AI Kimi K3	始终启用的推理能力与 100 万 Token 上下文	调试、架构分析、复杂逻辑
OpenAI GPT-OSS 120B	前沿代码生成能力（120B 参数）	全面生成、多文件实现
NVIDIA Nemotron 3 Super 120B	优化吞吐量，经过企业验证	高容量生成工作负载

解决方案概览

该架构由两部分组成：OpenCode 作为终端用户界面（TUI）运行在本地机器上，并调用 Amazon Bedrock Converse API 进行推理。Bedrock 以全托管、无服务器端点的形式托管模型。

图 1：Amazon Bedrock 上 OpenCode 与开放权重模型的解决方案架构。开发者在终端中与 OpenCode 交互，OpenCode 通过 Bedrock Converse API 向开放权重模型发送请求。AWS IAM 对每项请求进行身份验证，AWS CloudTrail 记录 API 活动。

OpenCode 的 Agent 架构支持为不同角色分配不同模型：使用推理模型进行规划，使用更快的模型进行代码生成。这样便可在单个会话中建立多模型工作流。

前提条件

开始前，请确保你已具备：

安装并配置 OpenCode

本节将介绍如何安装 OpenCode CLI，并将其配置为通过 Amazon Bedrock 进行身份验证。

安装 OpenCode

选择以下任一种方法：

# 安装脚本（推荐）
curl -fsSL https://opencode.ai/install | bash

# 或通过 npm
npm install -g opencode-ai

# 或通过 Homebrew（macOS/Linux）
brew install sst/tap/opencode

验证安装：

$ opencode --version
1.18.20

配置 AWS 凭证

OpenCode 的 Bedrock 提供商使用标准 AWS 凭证链。请配置以下任一选项：

选项 A：AWS IAM Identity Center（推荐用于企业）

aws sso login --profile my-bedrock-profile
export AWS_PROFILE=my-bedrock-profile
export AWS_REGION=us-west-2

选项 B：IAM 访问密钥

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_REGION=us-west-2

请将这些内容替换为你自己的凭证。生产环境中，应优先使用 IAM Identity Center 或 IAM 角色，而不是长期有效的访问密钥。

选项 C：Bedrock API 密钥

export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key
export AWS_REGION= us-west-2

你也可以将这些内容存储在项目根目录的 .env 文件中，以实现持久化配置。

配置多模型工作流

借助 OpenCode 的 Agent 系统，你可以为不同角色分配不同模型。在项目根目录中创建或编辑 opencode.json：

{
  "$schema": "https://opencode.ai/config.json",
  "model": "amazon-bedrock/us.openai.gpt-oss-120b-1:0",
  "agent": {
    "plan": {
      "model": " amazon-bedrock/global.moonshotai.kimi-k3"
    },
    "build": {
      "model": "amazon-bedrock/us.nvidia.nemotron-super-3-120b"
    }
  }
}

该配置会将规划和架构任务（受益于深度推理）路由至 Kimi K3，同时将代码生成和实现任务交由 Nemotron 3 Super 120B，以获得优化后的吞吐量。顶层 model 字段将 GPT-OSS 120B 设为其他上下文的默认模型。

若要以交互方式浏览可用的 Bedrock 模型，请启动 OpenCode 并输入 /models。

使用开放权重模型编程

以下示例展示了如何将每种模型与其最擅长处理的任务相匹配。

使用 GPT-OSS 120B 生成事件溯源订单服务

GPT-OSS 120B 是 OpenAI 的 1200 亿参数开放权重模型。它将强大的推理能力与代码生成能力结合，适合跨多个文件、架构复杂的实现。使用上一节的多模型配置后，你可以内联覆盖默认模型，或使用 /model 显式切换：

$ opencode
> /model us.openai.gpt-oss-120b-1:0
> 使用 Python（FastAPI）构建一个事件溯源的 CQRS 订单服务，要求：
> - 命令端：DynamoDB 中的仅追加事件存储，以及幂等处理器
> - DynamoDB Streams 触发投影 Lambda，以构建读模型
> - 查询端：为“按客户查询订单”和“按状态查询订单”
>   访问模式优化的反规范化读模型
> - 用于从头重建投影的事件重放 CLI
> - 每个聚合每 50 个事件创建一次快照，以限制重放时间
> 请包含 CDK 基础设施。

图 2：OpenCode 使用 GPT-OSS 120B 生成事件溯源 CQRS 订单服务。

OpenCode 通过 Bedrock Converse API 将该任务路由至 GPT-OSS 120B，并使用 IAM 进行身份验证。模型会将包括处理器、事件存储、投影和 CDK Stack 在内的完整服务结构直接生成到本地文件系统中。CloudTrail 会记录调用，你的提示词和响应将保留在 AWS 账户内。

使用 Kimi K3 诊断分布式死锁

Kimi K3 擅长需要追踪多条执行路径的推理任务。它会在每轮交互中推理，reasoning_config 字段可设置推理深度：low 用于快速分析，max 用于处理困难问题。如果你已将 Kimi K3 配置为 plan Agent，它已是分析任务的默认模型。你也可以通过 /model 显式切换：

> /model amazon-bedrock/global.moonshotai.kimi-k3
> 此 Step Functions 工作流在负载下约有 2% 的时间会挂起。
> 模式：任务 A 执行一个 Dyn

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:

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:

# Install script (recommended)
curl -fsSL https://opencode.ai/install | bash

# Or via npm
npm install -g opencode-ai

# Or via Homebrew (macOS/Linux)
brew install sst/tap/opencode

Verify the installation:

$ opencode --version
1.18.20

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)

aws sso login --profile my-bedrock-profile
export AWS_PROFILE=my-bedrock-profile
export AWS_REGION=us-west-2

Option B: IAM access keys

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_REGION=us-west-2

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

export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key
export AWS_REGION= us-west-2

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:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "amazon-bedrock/us.openai.gpt-oss-120b-1:0",
  "agent": {
    "plan": {
      "model": " amazon-bedrock/global.moonshotai.kimi-k3"
    },
    "build": {
      "model": "amazon-bedrock/us.nvidia.nemotron-super-3-120b"
    }
  }
}

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
> /model us.openai.gpt-oss-120b-1:0
> Build an event-sourced CQRS order service in Python (FastAPI) with:
> - Command side: append-only event store in DynamoDB, idempotent handlers
> - DynamoDB Streams triggering a projection Lambda that builds a read-model
> - Query side: denormalized read-model optimized for "orders by customer"
>   and "orders by status" access patterns
> - Event replay CLI to rebuild projections from scratch
> - Snapshotting every 50 events per aggregate to bound replay time
> Include CDK infrastructure.

Figure 2: OpenCode generating the event-sourced CQRS order service with GPT-OSS 120B

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:

> /model amazon-bedrock/global.moonshotai.kimi-k3
> This Step Functions workflow hangs ~2% of the time under load.
> The pattern: Task A does a DynamoDB conditional put that expects
> status="PENDING", Task B (triggered by SQS) sets status="READY"
> but only after Task A's callback confirms receipt. Both tasks
> wait on each other. Trace the deadlock, explain why it only
> manifests under concurrency, and propose a fix that doesn't
> require redesigning the state machine.
> @order_workflow.asl.json @task_a_handler.py @task_b_handler.py

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:

# Process multiple files through GPT-OSS 120B for test generation
for file in src/**/*.py; do
  opencode run -m amazon-bedrock/us.openai.gpt-oss-120b-1:0 \
    "Generate comprehensive unit tests for @${file}. Use pytest with fixtures."
done

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:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-west-2::foundation-model/openai.gpt-oss-120b-1:0",
        "arn:aws:bedrock:us-west-2::foundation-model/nvidia.nemotron-super-3-120b",
        "arn:aws:bedrock:us-west-2:{account-id}:inference-profile/global.moonshotai.kimi-k3",
        "arn:aws:bedrock:*::foundation-model/moonshotai.kimi-k3"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["bedrock:CallWithBearerToken"],
      "Resource": ["*"]
    }
  ]
}

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

Aris Tsakpinis

Aris is a Senior Specialist Solutions Architect for Generative AI focusing on open source models on Amazon Bedrock and the broader generative AI open source community. Alongside his professional role, he is pursuing a PhD in Machine Learning Engineering at the University of Regensburg, where his research focuses on applied natural language processing in scientific domains.

Sainath Miriyala

Sainath is a Senior Technical Account Manager at AWS, where he partners with automotive enterprises to accelerate autonomous driving initiatives that advance road safety at scale. He specializes in architecting large-scale distributed systems powered by AI/ML — helping customers translate complex technical requirements into production-ready solutions. Outside of work, Sainath enjoys spending time with family and friends.

Saurabh Trikande

Saurabh is a Senior Product Manager for Amazon Bedrock and Amazon SageMaker Inference. He is passionate about working with customers and partners, motivated by the goal of democratizing AI. He focuses on core challenges related to deploying complex AI applications, inference with multi-tenant models, cost optimizations, and making the deployment of generative AI models more accessible. In his spare time, Saurabh enjoys hiking, learning about innovative technologies, following TechCrunch, and spending time with his family.

Suryansh Rana

Suryansh is the Co-Founder and CEO of Ethara.AI, where he leads the company’s work in reinforcement learning and training increasingly capable AI systems. A UCLA-trained engineer, he previously developed electric vehicle power electronics and battery systems at Canoo and Romeo Power. He brings a hands-on engineering mindset to building reinforcement learning environments that help AI models reason, use tools and complete complex tasks. His focus is on closing the gap between what AI can generate and what it can reliably accomplish.