feat(kimi-code): add a tps slot to the status line - #3668
Conversation
Show the decode rate of the most recent measurable step in the footer, placed after cwd in the default layout and reorderable through `[status_line].items`. Custom status line commands receive the same number as `decodeTps` in their stdin payload. Steps too short to time leave the previous reading in place instead of clearing the slot, and the rate is computed by a helper shared with the debug timing line so both report the same number.
🦋 Changeset detectedLatest commit: 8c85284 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 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 289c498d35
ℹ️ 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".
`/new` and session switching go through resetSessionRuntime, which cleared every other per-session readout but left decodeTps in place. The rate is not persisted, so a resumed session could not overwrite it either, and the footer and the status line command payload kept reporting the previous session's number until the next measurable step.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c68892b0c7
ℹ️ 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".
The stdin snapshot field list in the configuration guide did not mention decodeTps or that it stays null until a step has been measured, so a script author could neither discover the field nor guard against the null.
1 participant
Related Issue
Resolve #3666
Problem
There is no way to see how fast the model is generating while working. The status line already carries the persistent, at-a-glance session state —
mode,goal,model,tasks,cwd,git,tips— but nothing reports throughput, so generation speed can only be judged by feel.Custom status lines have a narrower version of the same gap:
[status_line].commandtakes over the first footer line outright, and the stdin snapshot carries no rate, so a script cannot render one even if it wanted to.What changed
tpsbuilt-in slot. Renders the decode rate of the most recent measurable step, e.g.42.3 tok/s, placed aftercwdin the default layout. Like every other slot it can be reordered or dropped through[status_line].itemsintui.toml.decodeTpsadded to the status line command payload. A custom command now receives the same number on stdin (number | null, null until a step has been measured), keeping it at parity with the built-in slot instead of losing the readout.stepDecodeTps()is extracted from the existing debug timing line and used by both, so both always report the same number over the same decode window — including the existing 50 ms floor, below which the duration is dominated byDate.now()quantization and the ratio would be meaningless. The extraction is behavior-preserving: the existing timing tests are unchanged and still pass.Two behavior notes:
The rate is output tokens over the client-observed stream duration, so it reflects the speed actually perceived, including when the TUI itself is the bottleneck. #3666 discusses using the server-side decode window as an alternative.
Docs updated in both locales: the slot list and the commented example in
config-files.mdnow includetps.Checklist
/approve).gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.