refactor(model): remove OpenAIConfig and simplify OpenAIChatModel API

[AlbumenJ]

Fix. #423

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR simplifies the OpenAI model API by removing the OpenAIConfig class and its deprecation markers from OpenAIChatModel, consolidating configuration management into GenerateOptions and the existing OpenAIChatModel.Builder pattern.

Key Changes:

• Removed the entire OpenAIConfig class that provided a separate configuration context
• Removed @Deprecated annotations from OpenAIChatModel.builder() method and Builder class
• Simplified class-level documentation in OpenAIChatModel and GenerateOptions to remove references to the removed OpenAIConfig

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
OpenAIConfig.java	Complete removal of the configuration class that wrapped OpenAI connection settings
OpenAIChatModel.java	Removed deprecation annotations from builder API and simplified documentation by removing OpenAIConfig usage examples
GenerateOptions.java	Removed documentation references to the deleted OpenAIConfig class

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The removed documentation references to OpenAIConfig are appropriate since that class has been deleted. However, it might be helpful to add guidance on how to reuse common configuration across multiple requests now that OpenAIConfig is removed. Users previously relied on OpenAIConfig for this purpose, and the documentation should clarify the recommended pattern (e.g., creating a base GenerateOptions and using GenerateOptions.builder() to customize per request).

Suggested change

	* and connection-level configuration (apiKey, baseUrl, modelName, stream).
	* and connection-level configuration (apiKey, baseUrl, modelName, stream).
	*
	* <p>Connection-level configuration is typically shared across many requests, while
	* generation parameters may vary per request. A common pattern is to create a reusable
	* "base" {@code GenerateOptions} instance that captures all shared configuration (such as
	* API key, base URL, model name, and provider capability) and then derive per-request
	* variants via the builder when needed.
	*
	* <p>For example, you can:
	* <ul>
	* <li>Create a base instance once at application startup with the connection-level
	* settings that apply to most calls.</li>
	* <li>For each request, use the builder to construct a new {@code GenerateOptions}
	* instance that reuses the shared settings and overrides only the request-specific
	* generation parameters (such as temperature or max tokens).</li>
	* </ul>
	*
	* <p>This approach replaces the need for a separate configuration object and keeps
	* all configuration in a single, immutable value type that can safely be reused.

[Copilot]

The class-level documentation has been simplified but now lacks important usage guidance. The removed example showed how to use the stateless API with GenerateOptions, which is crucial for users migrating from the deprecated OpenAIConfig approach. Consider adding a brief usage example showing how to construct GenerateOptions and pass them to the model methods.

[Copilot]

The deprecation annotations have been removed from the builder() method and Builder class, but the Builder class documentation still mentions "backward compatibility with the old API" and "wraps the configuration so that calls without explicit options use the builder-provided values." This suggests the Builder is still meant for backward compatibility. If this is no longer deprecated, the documentation should be updated to clarify when to use the Builder versus the stateless approach with GenerateOptions directly, or if it's now the recommended approach, remove the backward compatibility language.