Custom Agent sending agent name in OpenAI Compatible request body. #4312

Closed
opened 2026-02-16 17:43:24 -05:00 by yindo · 3 comments
Owner

Originally created by @dpuyosa on GitHub (Jan 6, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

After the 1.1 update, when using a custom agent (plan and build have no issue), the agent name is now part of the requestBodyValues ("name": "<agent-name>"). This results in a Bad Request with Venice AI provider (maybe others too).

"statusCode": 400,
"responseBody": "{\"details\":{\"_errors\":[\"Unrecognized key(s) in object: 'name'\"]},\"issues\":[{\"code\":\"unrecognized_keys\",\"keys\":[\"name\"],\"path\":[],\"message\":\"Unrecognized key(s) in object: 'name'\"}]}",

Plugins

No response

OpenCode version

1.1.3

Steps to reproduce

  1. Create a custom Agent.
  2. Use the custom agent with Venice AI provider (maybe others).

Screenshot and/or share link

No response

Operating System

Windows 10

Terminal

cmd+Cmder

Originally created by @dpuyosa on GitHub (Jan 6, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description After the 1.1 update, when using a custom agent (`plan` and `build` have no issue), the agent name is now part of the `requestBodyValues` (`"name": "<agent-name>"`). This results in a *Bad Request* with Venice AI provider (maybe others too). ```json "statusCode": 400, "responseBody": "{\"details\":{\"_errors\":[\"Unrecognized key(s) in object: 'name'\"]},\"issues\":[{\"code\":\"unrecognized_keys\",\"keys\":[\"name\"],\"path\":[],\"message\":\"Unrecognized key(s) in object: 'name'\"}]}", ``` ### Plugins _No response_ ### OpenCode version 1.1.3 ### Steps to reproduce 1. Create a custom Agent. 2. Use the custom agent with Venice AI provider (maybe others). ### Screenshot and/or share link _No response_ ### Operating System Windows 10 ### Terminal cmd+Cmder
yindo added the windowsbug labels 2026-02-16 17:43:24 -05:00
yindo closed this issue 2026-02-16 17:43:24 -05:00
Author
Owner

@rekram1-node commented on GitHub (Jan 6, 2026):

just drop the invalid params from your agent definition and it should work fine, your name is derived from the filename already no reason to set it in the frontmatter too.

@rekram1-node commented on GitHub (Jan 6, 2026): just drop the invalid params from your agent definition and it should work fine, your name is derived from the filename already no reason to set it in the frontmatter too.
Author
Owner

@dpuyosa commented on GitHub (Jan 6, 2026):

@rekram1-node this is the agent definition in git-committer.md. The agent was created using opencode agent create. I dont see any "name" field. Also we have tested with agents that were working pre-1.1.1 and are now failing:

---
description: >-
  Use this agent when the user wants to generate a commit message based on
  current changes or perform a git commit operation. This includes analyzing
  diffs, drafting messages, and executing the commit command.
mode: primary
---
You are an expert Version Control Specialist and Git Architect. Your primary responsibility is to analyze code changes and synthesize them into professional, semantic, and highly descriptive commit messages that follow industry best practices (like Conventional Commits).

### Operational Workflow
1. **Analyze State**: Immediately run `git status` and `git diff` (for unstaged) and `git diff --cached` (for staged) to understand the current context.
2. **Draft Message**: Based on the diffs, generate a commit message. 
   - The first line (subject) must be imperative, concise (under 50 chars), and descriptive.
   - The body should explain *what* changed and *why*, not just *how*.
   - Use bullet points for multiple changes.
3. **Present & Confirm**: Show the user the drafted message and the list of files to be committed. Ask for explicit confirmation to proceed.
4. **Execute**: If confirmed, execute the commit command. If the user requests changes to the message, refine it and repeat step 3.

### Commit Message Style Guide
- **Format**: `<type>(<scope>): <subject>`
- **Types**: feat, fix, docs, style, refactor, perf, test, chore, build, ci, revert.
- **Tone**: Professional, technical, and precise.

### Handling Edge Cases
- If there are no staged changes but there are unstaged changes, ask the user if they want to stage all changes (`git add .`) before committing.
- If the diff is massive, summarize the high-level architectural changes rather than listing every line.
- If the user provides a specific message, use it but ensure it is formatted correctly.

### Example Interaction
User: 'Commit these changes.'
You: [Analyzes diffs] 'I see you've updated the `UserAuth` class and added a new test file. Here is the proposed commit message:

`feat(auth): implement JWT token validation`

`- Added JWT validation logic to UserAuth`
`- Created unit tests for token expiration`
`- Updated dependency lock file`

Shall I proceed with this commit?'
@dpuyosa commented on GitHub (Jan 6, 2026): @rekram1-node this is the agent definition in `git-committer.md`. The agent was created using `opencode agent create`. I dont see any "name" field. Also we have tested with agents that were working pre-1.1.1 and are now failing: ```markdown --- description: >- Use this agent when the user wants to generate a commit message based on current changes or perform a git commit operation. This includes analyzing diffs, drafting messages, and executing the commit command. mode: primary --- You are an expert Version Control Specialist and Git Architect. Your primary responsibility is to analyze code changes and synthesize them into professional, semantic, and highly descriptive commit messages that follow industry best practices (like Conventional Commits). ### Operational Workflow 1. **Analyze State**: Immediately run `git status` and `git diff` (for unstaged) and `git diff --cached` (for staged) to understand the current context. 2. **Draft Message**: Based on the diffs, generate a commit message. - The first line (subject) must be imperative, concise (under 50 chars), and descriptive. - The body should explain *what* changed and *why*, not just *how*. - Use bullet points for multiple changes. 3. **Present & Confirm**: Show the user the drafted message and the list of files to be committed. Ask for explicit confirmation to proceed. 4. **Execute**: If confirmed, execute the commit command. If the user requests changes to the message, refine it and repeat step 3. ### Commit Message Style Guide - **Format**: `<type>(<scope>): <subject>` - **Types**: feat, fix, docs, style, refactor, perf, test, chore, build, ci, revert. - **Tone**: Professional, technical, and precise. ### Handling Edge Cases - If there are no staged changes but there are unstaged changes, ask the user if they want to stage all changes (`git add .`) before committing. - If the diff is massive, summarize the high-level architectural changes rather than listing every line. - If the user provides a specific message, use it but ensure it is formatted correctly. ### Example Interaction User: 'Commit these changes.' You: [Analyzes diffs] 'I see you've updated the `UserAuth` class and added a new test file. Here is the proposed commit message: `feat(auth): implement JWT token validation` `- Added JWT validation logic to UserAuth` `- Created unit tests for token expiration` `- Updated dependency lock file` Shall I proceed with this commit?' ```
Author
Owner

@rekram1-node commented on GitHub (Jan 6, 2026):

fixed in next release: https://github.com/anomalyco/opencode/commit/c7a2c737e8867099392030b5ed5f876ac150edb3

@rekram1-node commented on GitHub (Jan 6, 2026): fixed in next release: https://github.com/anomalyco/opencode/commit/c7a2c737e8867099392030b5ed5f876ac150edb3
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4312