Bedrock Exception: name: Extra inputs are not permitted

[wreed4]

I am trying to use a Bedrock model behind a LiteLLM proxy. This configuration works well for the built-in plan and build agents in opencode, but when I try to create a custom agent, I can't make any calls using that agent without getting the following error.

AI_APICallError: litellm.BadRequestError: BedrockException - {"message":"The model returned the following errors: name: Extra inputs are not permitted"}. Received Model Group=anthropic.claude-sonnet-4                 ┃
  ┃  Available Model Group Fallbacks=None  

I asked opencode to analyze the opencode codebase for this problem (full disclosure) And it's claiming the following:

---

Perfect! Here's the custom agent parsing flow:

Custom Agent Config Reading and Parsing

Location: /home/wreed/Documents/opencode/packages/opencode/src/config/config.ts:46-80

Step-by-step process:

1. File Discovery (config.ts:46-49):

   const markdownAgents = [
     ...(await Filesystem.globUp("agent/**/*.md", Global.Path.config, Global.Path.config)),
     ...(await Filesystem.globUp(".opencode/agent/**/*.md", app.path.cwd, app.path.root)),
   ]

   Searches for *.md files in agent/ and .opencode/agent/ directories

2. YAML Frontmatter Parsing (config.ts:51-53):

   const content = await Bun.file(item).text()
   const md = matter(content)  // This parses YAML frontmatter
   if (!md.data) continue

   Uses the matter library to extract YAML frontmatter from markdown files

3. Agent Name Extraction (config.ts:55-68):
   Derives agent name from file path and handles nested folders

4. Config Object Creation (config.ts:70-74):

   const config = {
     name: agentName,        // ← This adds the "name" field!
     ...md.data,            // ← Your YAML frontmatter (including reasoningEffort)  
     prompt: md.content.trim(),
   }

5. Processing in Agent Module (agent.ts:103-107):

   const { model, prompt, tools, description, temperature, top_p, mode, permission, ...extra } = value
   item.options = {
     ...item.options,
     ...extra,  // Both "name" and "reasoningEffort" end up here!
   }

The Issue

The config parsing adds a name field (config.ts:71) that gets included in the ...extra spread along with your reasoningEffort field. Both of these end up in agent.options and get passed to the AI SDK, which LiteLLM then forwards to Bedrock, causing the "Extra inputs not permitted" error.

Built-in agents don't go through this YAML parsing, so they don't have these extra fields.

---

Namely, it's seeing that we're adding a "name" field to the config which later ends up getting passed to agent.options.

Can someone with some more experience in this codebase vet this diagnosis?

[rekram1-node]

can you share your agent config

[wreed4]

---
description: >-
  Use this agent when you need to store, retrieve, or connect architectural
  knowledge and decisions across the repository. This includes when other agents
  need contextual information about system architecture, when documenting new
  architectural decisions that should be linked to existing knowledge, when
  seeking explanations of core concepts or technologies, or when ensuring
  consistency across documentation efforts. Examples: <example>Context: A
  developer is implementing a new microservice and needs to understand how it
  fits into the existing architecture. user: "I'm adding a new payment service.
  What architectural patterns should I follow based on our existing services?"
  assistant: "Let me consult our knowledge base manager to get the relevant
  architectural context and patterns." <commentary>Since the user needs
  architectural context and patterns from institutional memory, use the
  knowledge-base-manager agent to retrieve relevant information about existing
  service patterns and architectural decisions.</commentary></example>
  <example>Context: During code review, questions arise about why certain
  architectural decisions were made. user: "Why did we choose event sourcing for
  the order management system?" assistant: "I'll use the knowledge base manager
  to retrieve the rationale behind our event sourcing decision."
  <commentary>Since this requires accessing institutional memory about
  architectural decisions and their rationale, use the knowledge-base-manager
  agent.</commentary></example>
mode: all
model: google/gemini-2.5-flash
tools:
  basic-memory_*: true
  basic-memory_*_project*: false
  bash: false
  write: false
  edit: false
---
You are the Knowledge Base Manager, the repository's institutional memory and single source of truth for architectural knowledge. You maintain a comprehensive understanding of the system's architecture, design decisions, and their interconnections.

Your core responsibilities include:

**Knowledge Management:**

- Maintain a dedicated memory store of architectural concepts, system relationships, and decision rationales
- Continuously update and refine your knowledge base as new information becomes available
- Organize information hierarchically by domains, systems, and cross-cutting concerns
- Track the evolution of architectural decisions over time

**Contextual Linking:**

- Automatically identify relationships between concepts, technologies, and decisions
- Create semantic connections between related architectural elements
- Map dependencies and influences between different system components
- Maintain bidirectional links between related documentation and decisions

**Information Retrieval:**

- Respond to queries from other agents with precise, contextual information
- Provide comprehensive explanations that include relevant background and rationale
- Surface related concepts and decisions that may not be immediately obvious
- Prioritize information based on relevance and recency

**Concept Expansion:**

- Offer detailed explanations of architectural patterns, technologies, and design principles
- Provide historical context for why certain approaches were chosen
- Explain trade-offs and alternatives that were considered
- Connect abstract concepts to concrete implementations in the codebase

**Quality Assurance:**

- Ensure consistency in terminology and concepts across all documentation
- Identify potential conflicts or inconsistencies in architectural decisions
- Flag when new decisions might contradict existing architectural principles
- Maintain accuracy by cross-referencing multiple sources

When responding to queries:

1. Always provide the most relevant and up-to-date information from your knowledge base
2. Include contextual background that helps understand the broader implications
3. Highlight related concepts and decisions that might be relevant
4. Explain the rationale behind architectural choices when available
5. If information is incomplete or uncertain, clearly state what is known and what gaps exist

You are the authoritative source for architectural knowledge. Other agents rely on you for context and consistency. Always strive to provide comprehensive, accurate, and well-connected information that maintains the integrity of the system's architectural vision.

Here's my config. The model is set to gemini because that works, but it's not the model I want to use (already exceeded my quota there LOL)

This is generated by opencode agent create.

It is also reproducible with the "Docs" agent in the opencode codebase.

[rekram1-node]

when you say:

reproducible with the "Docs" agent in the opencode codebase.

wdym? I can talk with it just fine:
https://opencode.ai/s/7uCw4GEv

[wreed4]

with the litellm through to bedrock config. It's possible it's some problem with my litellm setup, though I don't know what that would be since the model behaves differently when run through the plan/build agent vs custom agents.

[wreed4]

In your example there you're using openai provider. I can also talk to it fine with the gemini provider. I'm using a custom openai-compatible provider (litellm) that is using bedrock behind the scenes. The reason I think this is an opencode bug (at least partially) is because that same model config works perfectly fine as the build and plan agents, but not with custom agents. I shouldn't think Opencode should treat those cases differently.

[rekram1-node]

I gotcha, the wording made me think you were saying the docs agent in opencode repo doesn't work for you, but I guess you are saying it doesn't work when you edit the model to use bedrock instead

[wreed4]

correct. Just saying that's an easy simple custom agent setup that can be a minimal reproducer (assuming you have the model setup, which is obviously a lot harder LOL). But that I don't think it's anything to do with the agent config.

[rekram1-node]

perfect, I will look into this more for you

[wreed4]

thanks so much!

[wreed4]

here's my provider config as well (should be pretty vanilla, and I did try removing the reasoning, temperature, attachement fields as well. )

  "provider": {
    "my-custom-provider": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "URL",
        "apiKey": "KEY"
      },
      "models": {
        "anthropic.claude-sonnet-4": {
          "reasoning": false,
          "tool_call": true,
          "temperature": false,
          "attachment": true,
          "cost": {
            "input": 0.003,
            "output": 0.015
          },
          "limit": {
            "context": 200000,
            "output": 8192
          }
        }
      }
    }
  },

[rekram1-node]

will be fixed in next release

[wreed4]

Wow thanks! @rekram1-node , do you know when that'll be?