Bedrock Exception: name: Extra inputs are not permitted #1358

Closed
opened 2026-02-16 17:30:36 -05:00 by yindo · 15 comments
Owner

Originally created by @wreed4 on GitHub (Aug 18, 2025).

Originally assigned to: @thdxr on GitHub.

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?

Originally created by @wreed4 on GitHub (Aug 18, 2025). Originally assigned to: @thdxr on GitHub. 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`): ```typescript 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`): ```typescript 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`): ```typescript 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`): ```typescript 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?
yindo closed this issue 2026-02-16 17:30:36 -05:00
Author
Owner

@rekram1-node commented on GitHub (Aug 18, 2025):

can you share your agent config

@rekram1-node commented on GitHub (Aug 18, 2025): can you share your agent config
Author
Owner

@wreed4 commented on GitHub (Aug 18, 2025):

---
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.

@wreed4 commented on GitHub (Aug 18, 2025): ```markdown --- 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.
Author
Owner

@rekram1-node commented on GitHub (Aug 18, 2025):

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

@rekram1-node commented on GitHub (Aug 18, 2025): 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
Author
Owner

@wreed4 commented on GitHub (Aug 18, 2025):

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 commented on GitHub (Aug 18, 2025): 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.
Author
Owner

@wreed4 commented on GitHub (Aug 18, 2025):

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.

@wreed4 commented on GitHub (Aug 18, 2025): 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.
Author
Owner

@rekram1-node commented on GitHub (Aug 18, 2025):

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

@rekram1-node commented on GitHub (Aug 18, 2025): 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
Author
Owner

@wreed4 commented on GitHub (Aug 18, 2025):

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.

@wreed4 commented on GitHub (Aug 18, 2025): 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.
Author
Owner

@rekram1-node commented on GitHub (Aug 18, 2025):

perfect, I will look into this more for you

@rekram1-node commented on GitHub (Aug 18, 2025): perfect, I will look into this more for you
Author
Owner

@wreed4 commented on GitHub (Aug 18, 2025):

thanks so much!

@wreed4 commented on GitHub (Aug 18, 2025): thanks so much!
Author
Owner

@wreed4 commented on GitHub (Aug 18, 2025):

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
          }
        }
      }
    }
  },
@wreed4 commented on GitHub (Aug 18, 2025): here's my provider config as well (should be pretty vanilla, and I did try removing the reasoning, temperature, attachement fields as well. ) ```json "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 } } } } }, ```
Author
Owner

@rekram1-node commented on GitHub (Aug 18, 2025):

will be fixed in next release

@rekram1-node commented on GitHub (Aug 18, 2025): will be fixed in next release
Author
Owner

@wreed4 commented on GitHub (Aug 19, 2025):

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

@wreed4 commented on GitHub (Aug 19, 2025): Wow thanks! @rekram1-node , do you know when that'll be?
Author
Owner

@rekram1-node commented on GitHub (Aug 19, 2025):

later today most likely, I would say within next 4-8 hrs probably? I dont take liberty of releasing I let team handle it

@rekram1-node commented on GitHub (Aug 19, 2025): later today most likely, I would say within next 4-8 hrs probably? I dont take liberty of releasing I let team handle it
Author
Owner

@wreed4 commented on GitHub (Aug 19, 2025):

you guys are awesome. thanks!

@wreed4 commented on GitHub (Aug 19, 2025): you guys are awesome. thanks!
Author
Owner

@rekram1-node commented on GitHub (Aug 19, 2025):

happy to help!

@rekram1-node commented on GitHub (Aug 19, 2025): happy to help!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1358