feat: add session thinking effort flag - #2610
Conversation
🦋 Changeset detectedLatest commit: 1266d3c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f390596f1f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const createSessionOptions: MutableCreateSessionOptions = { | ||
| workDir, | ||
| model: startup.model, | ||
| thinking: startup.effort, |
There was a problem hiding this comment.
Preserve the effort override through OAuth login
When a fresh interactive startup reaches auth.login_required, this initial creation is abandoned and AuthFlowController.refreshConfigAfterLogin() later creates the session using thinkingEffortFromConfig(config.thinking) rather than startup.effort. Consequently, kimi --effort low silently loses the requested override whenever the user must log in first; forward the startup effort into the post-login creation path as is already done for the startup model.
Useful? React with 👍 / 👎.
| const session = await harness.createSession({ | ||
| workDir, | ||
| model, | ||
| thinking: opts.effort, |
There was a problem hiding this comment.
Strictly validate effort on fresh sessions
For a fresh session, forwarding the value through createSession does not provide the model-specific validation promised by this flag: the v1 create path calls resolveThinkingEffort without strict Kimi-protocol validation, while the fresh v2 binding likewise omits strictThinking, so an unsupported value can be retained for a later upstream failure or silently normalized instead of rejecting the invocation. Resumed sessions do call setThinking and reject the same input, making behavior depend on whether the session already exists; fresh prompt, TUI, and native-v2 creation should use the strict setter/binding semantics too.
Useful? React with 👍 / 👎.
f390596 to
1266d3c
Compare
Related Issue
Resolves #2535
Problem
Kimi Code users could not override the thinking effort when starting or resuming a session without changing
config.toml. This made it inconvenient to select different effort levels for interactive use, one-shot prompts,scripts, and CI workflows.
What changed
--effort <effort>support to the interactive TUI,--promptmode, resumed sessions, and the v2 print path.--modelbefore--effortso agent-core validates the effort against the target model.agent-core.
config.toml.mode, and TUI startup.
Validation completed:
pnpm --filter @moonshot-ai/kimi-code typecheckpnpm --filter @moonshot-ai/kimi-code buildpnpm lintChecklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.