anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[Feature Request]: plugin hook allowing modification of request body before it is sent #1755

New Issue
Open
opened 2026-02-16 17:32:29 -05:00 by yindo · 7 comments
yindo commented 2026-02-16 17:32:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @Zim-Inn on GitHub (Sep 18, 2025).

Originally assigned to: @thdxr on GitHub.

Is your feature request related to a problem? Please describe.
When integrating custom model providers with opencode, some APIs do not support optional fields like "functions": {} or "images": [] in the request payload. These fields, while valid for certain providers (e.g., OpenAI or Anthropic), may cause 400 Bad Request errors when sent to stricter or minimalistic endpoints. Currently, opencode automatically includes these fields based on internal logic, and users have no way to override or customize the payload structure.

Describe the solution you'd like
I propose introducing a configuration option that allows users to define a custom request payload template—either via a JSON schema, a templating system, or a declarative list of enabled/disabled fields. This would give users full control over the shape of the outgoing request, ensuring compatibility with diverse model APIs. Ideally, this could be set per model provider or per model name.

Describe alternatives you've considered

  • Manually modifying the source code to remove unsupported fields (not scalable across upgrades)
  • Using a proxy server to rewrite requests before forwarding (adds complexity and latency)
  • Relying on the provider to ignore unknown fields (not always possible)

Additional context
This feature would greatly improve opencode’s flexibility when working with:

  • Internal LLM gateways with strict schemas
  • Lightweight or experimental model APIs
  • Self-hosted endpoints that reject unknown fields
Originally created by @Zim-Inn on GitHub (Sep 18, 2025). Originally assigned to: @thdxr on GitHub. > **Is your feature request related to a problem? Please describe.** When integrating custom model providers with opencode, some APIs do not support optional fields like `"functions": {}` or `"images": []` in the request payload. These fields, while valid for certain providers (e.g., OpenAI or Anthropic), may cause `400 Bad Request` errors when sent to stricter or minimalistic endpoints. Currently, opencode automatically includes these fields based on internal logic, and users have no way to override or customize the payload structure. > **Describe the solution you'd like** I propose introducing a configuration option that allows users to define a custom request payload template—either via a JSON schema, a templating system, or a declarative list of enabled/disabled fields. This would give users full control over the shape of the outgoing request, ensuring compatibility with diverse model APIs. Ideally, this could be set per model provider or per model name. > **Describe alternatives you've considered** - Manually modifying the source code to remove unsupported fields (not scalable across upgrades) - Using a proxy server to rewrite requests before forwarding (adds complexity and latency) - Relying on the provider to ignore unknown fields (not always possible) > **Additional context** This feature would greatly improve opencode’s flexibility when working with: - Internal LLM gateways with strict schemas - Lightweight or experimental model APIs - Self-hosted endpoints that reject unknown fields
yindo commented 2026-02-16 17:32:29 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Sep 18, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #1735: max_tokens defaults to 32000 when using a custom provider - discusses similar API compatibility issues with custom providers where default parameters cause errors with strict endpoints
  • #971: Model options are not forwarded for openai-compatible providers unless provider.name option is given - addresses payload/parameter forwarding issues with custom providers
  • #930: Make using any model with any provider easier - requests better support for custom providers and any OpenAI-compatible endpoint

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Sep 18, 2025): This issue might be a duplicate of existing issues. Please check: - #1735: max_tokens defaults to 32000 when using a custom provider - discusses similar API compatibility issues with custom providers where default parameters cause errors with strict endpoints - #971: Model options are not forwarded for openai-compatible providers unless provider.name option is given - addresses payload/parameter forwarding issues with custom providers - #930: Make using any model with any provider easier - requests better support for custom providers and any OpenAI-compatible endpoint Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:32:29 -05:00
Author
Owner
Copy Link
Copy Source

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

We have a plugin system we should just add addition hooks / expanding existing if current ones dont suffice and that would allow you to manipulate things before requests are sent

@rekram1-node commented on GitHub (Sep 18, 2025): We have a plugin system we should just add addition hooks / expanding existing if current ones dont suffice and that would allow you to manipulate things before requests are sent
yindo commented 2026-02-16 17:32:29 -05:00
Author
Owner
Copy Link
Copy Source

@Zim-Inn commented on GitHub (Sep 18, 2025):

We have a plugin system we should just add addition hooks / expanding existing if current ones dont suffice and that would allow you to manipulate things before requests are sent

Fine. I see that plugin doc., but how to create a request body decorator plugin? That doc in your website is too crude.

@Zim-Inn commented on GitHub (Sep 18, 2025): > We have a plugin system we should just add addition hooks / expanding existing if current ones dont suffice and that would allow you to manipulate things before requests are sent Fine. I see that `plugin` doc., but how to create a request body decorator plugin? That doc in your website is too crude.
yindo commented 2026-02-16 17:32:29 -05:00
Author
Owner
Copy Link
Copy Source

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

Sorry I was just kinda saying how support for this would work didn't mean to sound dismissive of your ask.

Would something like the following work for you:

ability to intercept request bodies to the LLM provider before they are sent and edit them and then the edited version be sent to server?

@rekram1-node commented on GitHub (Sep 18, 2025): Sorry I was just kinda saying how support for this would work didn't mean to sound dismissive of your ask. Would something like the following work for you: ability to intercept request bodies to the LLM provider before they are sent and edit them and then the edited version be sent to server?
yindo commented 2026-02-16 17:32:29 -05:00
Author
Owner
Copy Link
Copy Source

@Zim-Inn commented on GitHub (Sep 18, 2025):

Would something like the following work for you:

ability to intercept request bodies to the LLM provider before they are sent and edit them and then the edited version be sent to server?

Yes, it is what I need.

BTW, you are so polite.

@Zim-Inn commented on GitHub (Sep 18, 2025): > Would something like the following work for you: > > ability to intercept request bodies to the LLM provider before they are sent and edit them and then the edited version be sent to server? Yes, it is what I need. --- BTW, you are so polite.
yindo commented 2026-02-16 17:32:29 -05:00
Author
Owner
Copy Link
Copy Source

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

Happy to help, perfect yeah that sounds like something we can do for you

@rekram1-node commented on GitHub (Sep 18, 2025): Happy to help, perfect yeah that sounds like something we can do for you
yindo commented 2026-02-16 17:32:30 -05:00
Author
Owner
Copy Link
Copy Source

@NightRare commented on GitHub (Nov 27, 2025):

Just wondering is there any update on this one? @rekram1-node thanks

@NightRare commented on GitHub (Nov 27, 2025): Just wondering is there any update on this one? @rekram1-node thanks
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1755
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?