AWS has published a practical guide to running the open-source, terminal-native OpenCode coding agent with open-weight models through Amazon Bedrock. The useful bit is not another model launch, but a workable setup for developers who want local file and shell access while keeping inference inside their AWS environment.
AWS AI Watch analysis
What happened
OpenCode runs on a developer’s machine, reads and edits files, executes shell commands and uses Language Server Protocol diagnostics to understand a project. AWS’s guide connects it to Bedrock’s Converse API, where teams can choose among models including Moonshot AI’s Kimi K3, OpenAI’s GPT-OSS 120B and NVIDIA Nemotron 3 Super 120B.
The guide describes a multi-model configuration: Kimi K3 handles planning and architecture work, Nemotron handles code generation, and GPT-OSS 120B acts as the default model. Switching models is presented as a configuration change rather than a wholesale tooling migration. The article also gives installation steps, AWS authentication options and a sample project configuration.
AWS says code, prompts and responses stay within the customer’s AWS account, with IAM, CloudTrail, PrivateLink and encryption controls. It also says Bedrock does not use inputs or outputs to train or improve foundation models. Those are AWS’s service claims, not independent testing.
The practical constraints are equally important. Customers need Bedrock access and model permissions, must check regional availability, and still pay for inference. AWS lists Priority, Standard and Flex pricing tiers, with Flex described as 50% cheaper for workloads that can tolerate variable latency.
Why it matters
Coding agents are hungry little beasts. AWS cites Gartner’s estimate that agentic workflows can multiply token consumption by 5 to 30 times, making the cost of each completed task more useful than a neat per-token headline. The guide’s central pitch is that open-weight models can offer model choice, customisation and potentially lower costs without asking a team to operate its own GPU fleet.
That trade is particularly relevant to organisations with data-residency requirements or large codebases. AWS says Kimi K3 supports a 1-million-token context window, which could allow a developer to work across tens of thousands of lines of code, subject to the model and workload behaving as advertised.
Our read
This is a proper infrastructure story disguised as a tutorial. The interesting change is the combination of a local terminal interface, managed inference and model switching. It gives developers more control than a single hosted coding assistant, without handing them a weekend of GPU provisioning and a suspiciously cheerful incident rota.
Use the guide as a starting point, not a performance certificate. Test cost per successful change, latency, tool-call failures and human review on your own repositories. Also check exactly where requests are processed before assuming that “inside AWS” automatically satisfies every residency or compliance requirement.
What to watch
- Real task economics
Whether open-weight models reduce the cost of completed coding tasks after retries, long contexts and review time. - Regional coverage
Which Bedrock models and inference profiles are available where regulated teams need them. - Agent safety
How teams constrain shell commands, credentials and file changes when the agent can operate locally. - Model switching
Whether developers actually benefit from assigning different models to planning, generation and debugging. Source: AWS Machine Learning Blog, “Use open weight models as your AI coding agent with Amazon Bedrock.”
Discussion spark: Should coding agents be judged mainly by cost per successful change, even if that makes model comparisons slower and less tidy than a per-token price table?
Sources and evidence
- Use open weight models as your AI coding agent with Amazon Bedrock (23 September 2026, 18:17 UTC)
not affiliated with or endorsed by Amazon Web Services (AWS)