[Bug]: Kimi Code export omits support_efforts and default_effort from declared model metadata

Open
  • Is something wrong?
#8,095 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
devtools

Research direction

Start in src/clients/config-export.ts: add the optional support_efforts and default_effort fields to KimiModelBlock, then update buildKimiClientConfig() to read reasoningEfforts and defaultReasoningEffort from ExportModel in src/clients/config-export/contracts.ts. Use src/clients/config-export/dsh.ts as the reference for how the ladder is mapped. Done when the generated block includes the filtered ladder and a default that belongs to it, an explicit empty ladder emits nothing, ultra is dropped, and the existing context and image_in tests still pass.

Written by the indexing model from the issue text.

Description

bug install
Client or integration

Other

Area

Installation or packaging

Summary

In ocx 2.96.0, the Kimi Code integration still drops declared reasoning-effort metadata when it writes ~/.kimi-code/config.toml. buildKimiClientConfig() does not read model.reasoningEfforts or model.defaultReasoningEffort, and KimiModelBlock has no support_efforts or default_effort fields. As a result, routed model entries lack the metadata Kimi Code uses to offer thinking-effort selection.

This is the same class of problem previously reported in #2688, but it is still present in the current 2.96.0 source. I am reporting the current source and live configuration rather than assuming the earlier issue's fix was released and later reverted.

The model data itself is complete. For example, /api/models returns this row:

{
  "id": "k3.1-pro",
  "provider": "kimi",
  "namespaced": "kimi/k3.1-pro",
  "reasoningEfforts": ["low", "high", "max"],
  "defaultReasoningEffort": "low",
  "supportsReasoningEffort": true
}

Kimi Code's documented model format supports support_efforts and default_effort. A routed selector such as kimi/k3.1-pro also cannot rely on provider-specific model-name-prefix inference, so omitting the explicit metadata loses the effort control even though the proxy already accepts reasoning_effort for that model.

Reproduction
  1. Enable a provider/model with a declared effort ladder, such as kimi/k3.1-pro above, and apply the Kimi Code integration.
  2. Inspect the generated block in ~/.kimi-code/config.toml:
[models."opencodex/kimi/k3.1-pro"]
provider = "opencodex"
model = "kimi/k3.1-pro"
max_context_size = 1048576
display_name = "K3.1 Pro"
capabilities = ["image_in"]
# support_efforts is absent
# default_effort is absent
  1. Compare with Kimi Code's managed entry for a related model, which contains:
support_efforts = ["low", "high", "max"]
default_effort = "high"
  1. Compare with the DSH exporter for the same ocx catalog: src/clients/config-export/dsh.ts reads the ladder and emits reasoningEfforts, so the effort metadata is available there but missing from Kimi Code.

Current source evidence in 2.96.0:

  • src/clients/config-export.ts:978-984: KimiModelBlock declares only provider, model, max_context_size, display_name, and an optional capabilities tuple containing only image_in.
  • src/clients/config-export.ts:1171-1185: buildKimiClientConfig() uses only the context window, display name, and image modality; it never reads the declared effort fields.
  • src/clients/config-export/contracts.ts:99-104: ExportModel already carries reasoningEfforts and defaultReasoningEffort.
  • src/clients/config-export/dsh.ts:53-72,106-114: DSH explicitly maps and writes the same metadata.

Expected: emit support_efforts from the effective declared ladder and emit default_effort when a declared default belongs to that ladder. Do not invent a ladder for an explicit empty/unknown effort declaration, and filter values the client cannot accept (for example, ocx's orchestration-only ultra must not become a Kimi Code effort). A suitable implementation can reuse the canonical effort projection rather than adding a separate provider-specific fact table.

A focused regression test should cover a declared ladder/default, an explicit empty ladder, and filtering of unsupported values. It should also preserve the existing context/modality behavior and cover the related thinking capability evidence discussed in #2688.

Version

2.96.0 (@bitkyc08/opencodex, npm global); Kimi Code CLI 2.3.3

Operating system

Windows 11 (build 26300)

Provider and model

kimi / k3.1-pro (also applicable to other routed providers and custom model rows)

Logs or error output

There is no write-time error. The integration reports "applied" successfully, but the generated model block omits the fields:

# ocx model metadata
reasoningEfforts = ["low", "high", "max"]
defaultReasoningEffort = "low"
supportsReasoningEffort = true

# generated Kimi Code block
provider = "opencodex"
model = "kimi/k3.1-pro"
max_context_size = 1048576
display_name = "K3.1 Pro"
capabilities = ["image_in"]
# no support_efforts / default_effort

As a local confirmation, I added support_efforts to the 14 generated ocx model entries using their actual declared ladders, filtering out ultra. kimi doctor config then completed with:

OK config.toml C:\Users\<user>\.kimi-code\config.toml
All checked config files are valid.

That manual edit is only local evidence. Reapplying the integration would overwrite it because the writer still omits the fields.

Screenshots and supporting files

The Integrations page shows Kimi Code as applied to ~/.kimi-code/config.toml. Kimi Code's managed model entries contain effort fields, while the ocx-generated entries do not.

Redacted configuration
{
  "id": "k3.1-pro",
  "provider": "kimi",
  "namespaced": "kimi/k3.1-pro",
  "reasoningEfforts": ["low", "high", "max"],
  "defaultReasoningEffort": "low",
  "supportsReasoningEffort": true
}
Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
16h 51m
Merged PRs (30d)
681

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.