LLMParams and Responses API

[devcrocod]

KG-220 Ability to pass custom LLM params

• add Responses API
• remove deprecation models (o1Mini, Moderation.Text)
• add openrouter models (gpt5, gpt5-mini, gpt5-nano, gpt-oss-120b)
• refactor code
• fix responseFormat

Breaking Changes

---

Type of the changes

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tests improvement
• Refactoring

Checklist

• The pull request has a description of the proposed change
• I read the Contributing Guidelines before opening the pull request
• The pull request uses develop as the base branch
• Tests for the changes have been added
• All new and existing tests passed

Additional steps for pull requests adding a new feature

• An issue describing the proposed change exists
• The pull request includes a link to the issue
• The change was discussed and approved in the issue
• Docs have been added / updated

[github-actions]

Qodana for JVM

855 new problems were found

Inspection name	Severity	Problems
Check Kotlin and Java source code coverage	🔶 Warning	798
Missing KDoc for public API declaration	🔶 Warning	50
Vulnerable imported dependency	🔶 Warning	6
String concatenation that can be converted to string template	◽️ Notice	1

@@ Code coverage @@
+ 65% total lines covered
10615 lines analyzed, 6973 lines covered
# Calculated according to the filters of your coverage tool

☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions

[Copilot]

Pull Request Overview

This PR introduces LLMParams and Responses API functionality to extend model parameter customization capabilities. The changes enable provider-specific parameter handling, add support for OpenAI's Responses API, and introduce new OpenRouter model definitions.

• Refactors LLMParams from data class to open class with custom equals/hashCode/toString methods
• Adds comprehensive OpenAI Responses API implementation with streaming support
• Introduces provider-specific parameter classes (OpenAIParams, OpenRouterParams) extending base LLMParams
• Adds new GPT-5 model variants and gpt-oss-120b model to OpenRouter definitions
• Refactors OpenAI client architecture to support multiple API endpoints via generics

Reviewed Changes

Copilot reviewed 19 out of 20 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
LLMParams.kt	Converts data class to open class with manual implementation of copy/equals/hashCode
LLMCapability.kt	Adds OpenAIEndpoint capability for Completions and Responses APIs
OpenRouterChatCompletion.kt	New OpenRouter-specific request/response models with provider preferences
OpenRouterParams.kt	OpenRouter parameter class with validation and provider-specific options
OpenRouterModels.kt	Adds GPT-5, GPT-5 Mini, GPT-5 Nano, and GPT-OSS-120b model definitions
OpenRouterLLMClient.kt	Refactors to use generic AbstractOpenAILLMClient with provider-specific serialization
OpenAIDataModels.kt	Refactors to extract base interfaces and move chat completion models to separate file
AbstractOpenAILLMClient.kt	Major refactor to generic class supporting multiple response types via abstract methods
OpenAIResponsesAPI.kt	Comprehensive OpenAI Responses API implementation with 2300+ lines of models
OpenAIChatCompletion.kt	Extracted chat completion models from main data models file
OpenAIParams.kt	New OpenAI-specific parameter classes for Chat and Responses APIs

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[tiginamaria]

Thank you! Everything looks great! Just a couple of small suggestions:

1. Please compare the OpenRouter params with the spec (or at least make sure all the ones we pass in the request are included in the params class)
2. I think the manual toString implementation comes from the fact that params isn’t a data class. But maybe there’s a way around this? For example, making them serializable and outputting JSON. Otherwise, we risk forgetting to update this method whenever the params list changes.

[devcrocod]

@tiginamaria thank you for your review

I think the manual toString implementation comes from the fact that params isn’t a data class. But maybe there’s a way around this? For example, making them serializable and outputting JSON. Otherwise, we risk forgetting to update this method whenever the params list changes.

Since this is a subclass, we cannot make it a data class
Also, Kotlin does not recommend using data classes for library api: https://kotlinlang.org/docs/api-guidelines-backward-compatibility.html#avoid-using-data-classes-in-your-api

[tiginamaria]

Thank you! I have just one clarification question caused by missing docs, except this all is fine!