cloudwego / cloudwego/eino-ext

feat: first-class support for mainstream OpenAI-compatible ChatModel providers (GLM, Kimi, Minimax, Grok)

Open
#718 0 comments 1 reaction 0 assignees View on GitHub
C-feature-request D-chatmodel-impl
Dominant language
Go
Stars
811
Forks
368
Avg merge
16h 22m
Merged PRs (30d)
13

Description

## Summary

Add dedicated `components/model/{glm,kimi,minimax,grok}` modules for four mainstream OpenAI-compatible ChatModel providers, following the established pattern of `components/model/qwen` and `components/model/deepseek`.

## Why first-class support, rather than pointing `components/model/openai` at a custom BaseURL?

### 1. Reasoning content is silently dropped

Several of these providers have reasoning/thinking models that return `reasoning_content` (or equivalent) in their responses:

| Provider | Model | Field |
|---|---|---|
| Zhipu AI | GLM-Z1 series | `reasoning_content` |
| Moonshot | kimi-k1.5, kimi-thinking | `reasoning_content` |
| xAI | grok-3-mini (thinking mode) | `reasoning_content` |

When users use `components/model/openai` with a custom `BaseURL`, the component has no dedicated extraction path for `reasoning_content` from these providers. The thinking output is silently lost, breaking multi-turn reasoning workflows.

A dedicated module can wire up the correct extraction path via `libs/acl/openai`'s existing `ReasoningContent` support — exactly as `components/model/deepseek` does.

### 2. Provider-specific parameters and defaults are undiscoverable

Each provider has its own:
- `BaseURL` (must be hardcoded correctly by the user today)
- Supported model names
- Supported features (e.g., GLM web search tool, Kimi file context, Minimax audio)
- Quirks (e.g., parameter names, rate limit headers, error formats)

Without a dedicated module, users must read provider documentation separately and remember to configure everything manually. A dedicated module encapsulates correct defaults and exposes provider-specific options in a typed, discoverable way.

### 3. Consistency with the established pattern

The codebase already establishes the right abstraction:
- `libs/acl/openai` — generic OpenAI-compatible transport (handles `reasoning_content`, `ExtraFields`, etc.)
- `components/model/qwen` — thin module wrapping the ACL with Qwen-specific config
- `components/model/deepseek` — same, with DeepSeek-specific `reasoning_content` extraction

GLM, Kimi, Minimax, and Grok are equally mainstream and deserve the same treatment.

### 4. Users are already asking for it

Users currently work around the gap by pointing `components/model/openai` at non-OpenAI endpoints. This works for basic generation but fails silently for reasoning content and offers no guidance on provider-specific features.

## Scope

Each module should follow the `components/model/qwen` structure:
- Separate `go.mod` under `components/model/{provider}/`
- `ChatModelConfig` with typed fields for BaseURL, APIKey, Model, timeout, etc.
- Correct `BaseURL` default for the provider
- `reasoning_content` extraction wired up where the provider supports it
- Provider-specific options (e.g., GLM web search, Kimi file context) exposed via `option.go`
- `examples/` with basic generate/stream/tool usage

## Providers

- **GLM** (Zhipu AI) — `https://open.bigmodel.cn/api/paas/v4/` — GLM-4, GLM-Z1 (reasoning)
- **Kimi** (Moonshot AI) — `https://api.moonshot.cn/v1` — moonshot-v1 series, kimi-k1.5/thinking (reasoning)
- **Minimax** — `https://api.minimax.chat/v1` — MiniMax-Text-01, abab series
- **Grok** (xAI) — `https://api.x.ai/v1` — grok-2, grok-3, grok-3-mini (reasoning)

Good first-contribution candidates — each is a relatively small, self-contained module.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.