anomalyco / anomalyco/opencode

[FEATURE]: General Bedrock retouch

Open
#49,953 0 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Feature hasn't been suggested before.
  • I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request

I have been transitioning my workflows to opencode over Bedrock. In the process I have identified several pieces that could be better and altogether would bring greater quality of life to users like our team.

The main motivation is that in many environments, platforms like Bedrock are the only way to access AI models, enforce zero data retention, and measure costs effectively for one's entire team. In this kind of environments, static credentials are generally frowned upon as an auth method, SSO is the default, and usually, we apply fine grained access controls to pretty much everything.

I understand that Bedrock can be moving fast, and it's not the easiest of targets to pursue, I also understand that the contributing team must be under an immense wave of human or AI generated PRs. That's why I can definitely volunteer the work, but I would also require some PR reviews. Let me know if there is interest around this.

Some examples:

  • Bedrock API key should probably not be the only option when hitting /connect. Sigv4 with some sort of reconnect, should be the defacto model, with IAM User key pair and Bedrock API key coming in second
  • Bedrock models, their cost, and available variants should ideally be fetched from the API instead of being hardcoded in the app. Kimi K3 arrived yesterday and although I could make it work, I really shouldn't have to hand patch it via opencode.jsonc. Moreover, as I say above, fine-grained access controls usually apply so it may not be prudent to display all bedrock models, and we should instead display the ones actually available to the user.
  • ZDR should be an obvious flag next to models, the API can provide that. Possibly tied to the above bullet as even in a roundabout way you can centrally block non-ZDR models at the account level.

Bonus

  • This might be a long shot but some central configuration management would be grand.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the Bedrock integration and the /connect flow mentioned in the issue. Break the request into separately scoped work for authentication, model and cost discovery, and ZDR visibility; done should be defined for each piece before implementation begins.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
authentication, backend-api-design, cloud
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.