What feature would you like to see?
Summary
kimi --print --output-format stream-json buffers each assistant
turn into one whole-message JSONL line, instead of emitting
incremental token deltas. This makes the print-mode JSONL output
unsuitable for downstream tooling that expects token-level streaming.
Requesting an opt-in flag to emit incremental deltas, mirroring
similar flags in other agent CLIs.
Current Behavior
kimi --print --output-format stream-json emits each assistant turn
as a single JSONL line carrying the full content, only after the
turn completes:
{"role":"assistant","content":[{"type":"text","text":"<entire response>"}]}
The print-mode docs confirm this ("Stream-JSON Output Mode:
Whole Messages Per Turn"), and the FAQ mentions output-being-buffered
as expected.
For consumers that render the JSONL into a UI, this means nothing
shows until the full turn lands, then the whole reply appears at once.
Comparison with Other Agent CLIs
Other agent CLIs already expose incremental deltas in their print /
JSONL output mode:
claude -p --output-format stream-json --include-partial-messages
cursor-agent --print --output-format stream-json --stream-partial-output
codex exec --json
PR #1598 added incremental rendering to the interactive shell, but
that only affects the terminal Rich Live UI. Programmatic consumers
of the JSONL output get no benefit.
Proposed Solution
An opt-in flag (mirroring cursor's --stream-partial-output, or
claude's --include-partial-messages) that emits incremental delta
events on the JSONL stream, e.g.:
{"role":"assistant","content":[{"type":"text","text":"Hel"}]}
{"role":"assistant","content":[{"type":"text","text":"lo"}]}
{"role":"assistant","content":[{"type":"text","text":" world"}]}
{"role":"assistant","content":[{"type":"text","text":"Hello world"}]}
A trailing duplicate event carrying the cumulative content (as
cursor does) is fine. Exact schema is up to maintainers.
Additional Context
The model's token stream is already available internally (PR #1598
relies on it for the interactive shell). This request is to expose
the same stream through the JSONL output path so that headless /
programmatic consumers can reach it too.
Additional information
No response
What feature would you like to see?
Summary
kimi --print --output-format stream-jsonbuffers each assistantturn into one whole-message JSONL line, instead of emitting
incremental token deltas. This makes the print-mode JSONL output
unsuitable for downstream tooling that expects token-level streaming.
Requesting an opt-in flag to emit incremental deltas, mirroring
similar flags in other agent CLIs.
Current Behavior
kimi --print --output-format stream-jsonemits each assistant turnas a single JSONL line carrying the full content, only after the
turn completes:
{"role":"assistant","content":[{"type":"text","text":"<entire response>"}]}The print-mode docs confirm this ("Stream-JSON Output Mode:
Whole Messages Per Turn"), and the FAQ mentions output-being-buffered
as expected.
For consumers that render the JSONL into a UI, this means nothing
shows until the full turn lands, then the whole reply appears at once.
Comparison with Other Agent CLIs
Other agent CLIs already expose incremental deltas in their print /
JSONL output mode:
claude -p --output-format stream-json --include-partial-messagescursor-agent --print --output-format stream-json --stream-partial-outputcodex exec --jsonPR #1598 added incremental rendering to the interactive shell, but
that only affects the terminal Rich Live UI. Programmatic consumers
of the JSONL output get no benefit.
Proposed Solution
An opt-in flag (mirroring cursor's
--stream-partial-output, orclaude's
--include-partial-messages) that emits incremental deltaevents on the JSONL stream, e.g.:
{"role":"assistant","content":[{"type":"text","text":"Hel"}]} {"role":"assistant","content":[{"type":"text","text":"lo"}]} {"role":"assistant","content":[{"type":"text","text":" world"}]} {"role":"assistant","content":[{"type":"text","text":"Hello world"}]}A trailing duplicate event carrying the cumulative content (as
cursor does) is fine. Exact schema is up to maintainers.
Additional Context
The model's token stream is already available internally (PR #1598
relies on it for the interactive shell). This request is to expose
the same stream through the JSONL output path so that headless /
programmatic consumers can reach it too.
Additional information
No response