Support developer role for GPT-compatible Claude translations

[hudson-s]

Goal

Update the OpenAI Claude translator to use a top-level developer role for GPT-5, Codex, and o-series model names, while keeping system for other compatible models.

Rationale

Some newer GPT-compatible chat models reject top-level system messages and expect developer instructions instead. The Claude-to-OpenAI translator currently always emits system for Anthropic top-level system content, which can break those models. This change preserves generic compatibility by only switching known model families that expect developer.

Intended implementation

• Add topLevelSystemRoleForOpenAI(modelName string) string.
• Normalize model names by trimming space, lowercasing, and stripping provider prefixes before matching.
• Return developer for gpt, gpt-5*, codex*, o1*, o3*, and o4*.
• Return system otherwise.
• Use the helper when constructing the top-level system/developer message.
• Add tests for matching model families and update affected conversion assertions.

func topLevelSystemRoleForOpenAI(modelName string) string {
    model := strings.ToLower(strings.TrimSpace(modelName))
    if slash := strings.LastIndex(model, /); slash >= 0 {
        model = model[slash+1:]
    }

    if model == gpt ||
        strings.HasPrefix(model, gpt-5) ||
        strings.HasPrefix(model, codex) ||
        strings.HasPrefix(model, o1) ||
        strings.HasPrefix(model, o3) ||
        strings.HasPrefix(model, o4) {
        return developer
    }

    return system
}

Local verification status

[hudson-s]

$ docker run --rm -v ${PWD}:/src -w /src golang:1.26 go test ./internal/translator/openai/claude
ok   github.com/router-for-me/CLIProxyAPI/v7/internal/translator/openai/claude 0.085s

$ docker run --rm -v ${PWD}:/src -w /src golang:1.26 go build -o /tmp/cli-proxy-api-test ./cmd/server
# succeeded

[luispater]

Thanks for the detailed report and proposed implementation.

I reviewed the current translator and model metadata paths. The Claude-to-OpenAI translator only receives the resolved model name, raw request body, and stream flag. The existing ModelInfo/config metadata covers things like modalities, thinking support, supported parameters, and web search, but there is no explicit capability that says whether a top-level instruction should be emitted as system or developer.

Because of that, the proposed implementation would have to infer protocol behavior from model-name prefixes. That would be brittle for aliases, third-party OpenAI-compatible providers, and future model families, so we do not want to add that heuristic as the generic Claude-to-OpenAI behavior.

A cleaner future change would need an explicit provider/model capability or config option for the preferred top-level instruction role, then pass that capability into the translation step. Since that is a broader design change and this issue proposes name-based inference, I am closing this as not planned.