Repository navigation
Bedrock Exception: name: Extra inputs are not permitted #2038
Description
Activity
can you share your agent config
--- 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.
when you say:
reproducible with the "Docs" agent in the opencode codebase.
wdym? I can talk with it just fine:
https://opencode.ai/s/7uCw4GEvwith 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.
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.
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
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.
perfect, I will look into this more for you
Reacted by William Reedthanks so much!
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 } } } } },
will be fixed in next release
Wow thanks! @rekram1-node , do you know when that'll be?
later today most likely, I would say within next 4-8 hrs probably? I dont take liberty of releasing I let team handle it
you guys are awesome. thanks!
Reacted by Aiden Clinehappy to help!
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.
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-80Step-by-step process:
File Discovery (
config.ts:46-49):Searches for
*.mdfiles inagent/and.opencode/agent/directoriesYAML Frontmatter Parsing (
config.ts:51-53):Uses the
matterlibrary to extract YAML frontmatter from markdown filesAgent Name Extraction (
config.ts:55-68):Derives agent name from file path and handles nested folders
Config Object Creation (
config.ts:70-74):Processing in Agent Module (
agent.ts:103-107):The Issue
The config parsing adds a
namefield (config.ts:71) that gets included in the...extraspread along with yourreasoningEffortfield. Both of these end up inagent.optionsand 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?