Prompt-mode run generated 1,057 chat completions with only ~18 visible tool events

What version of Kimi Code is running?

kimi-code-cli/0.14.3

Observed from the HTTP User-Agent on the model requests.

Which open platform/subscription were you using?

Custom/private OpenAI-compatible gateway in front of a Kimi-compatible coding model route.

No API keys or private URLs are included here.

Which model were you using?

A Kimi coding model route exposed through the gateway.

The gateway forwards to a Fireworks-hosted Kimi code route. I can share more exact routing details privately if useful, but I am avoiding posting account-specific config in a public issue.

What platform is your computer?

Linux sandbox/runtime.

What issue are you seeing?

A single non-interactive prompt-mode Kimi Code CLI run appeared to generate an unexpectedly large number of upstream chat completion requests.

Command shape:

kimi -p '<prompt>' --output-format stream-json

Observed gateway/request-log data for one run:

successful chat completion requests: 1,057
unique request IDs: 1,057
duplicate request IDs: 0
attempted retries reported by gateway: 0
cache hits: 0
total prompt tokens: 41,107,785
total completion tokens: 119,989
median gap between request start times: ~1 second
994 / 1,056 inter-request gaps were under 3 seconds

The CLI stream output did not show anything close to 1,057 visible tool events. The saved stream-json trace was small: about 46 JSONL lines, with roughly 18 visible tool steps.

There were no gateway-level retries explaining this. The paid requests were successful, unique upstream requests.

What steps can reproduce the bug?

I do not yet have a minimal reproduction, but the rough setup was:

1. Configure Kimi Code CLI with a custom provider/gateway.
2. Run one prompt-mode task with:

kimi -p '<browser/content extraction style task>' --output-format stream-json

3. Allow Kimi Code to use normal tools such as shell/browser/screenshot/media-read helpers.
4. Compare:
   • visible stream-json tool events from stdout
   • upstream /chat/completions request logs from the gateway

The outlier run involved a large screenshot/media read from a webpage, but I do not think screenshot size alone explains it. Other similar concurrent Kimi Code runs had larger media payloads and only around 18-64 upstream requests.

What is the expected behavior?

For one prompt-mode CLI run, I would expect one of these behaviors:

• upstream model calls roughly track visible planning/tool progress, or
• if Kimi Code is intentionally making many internal calls, expose that clearly in telemetry/output, and
• provide a hard max-call / max-token / max-spend guardrail so the CLI cannot silently generate hundreds or thousands of model calls from one prompt.

At minimum, it would be useful to know whether this pattern is expected behavior, a known failure mode, or a bug in the agent loop/provider integration.

Additional information

This does not look like gateway duplicate accounting:

request IDs were unique
one request_id lookup returned exactly one log row
all paid rows reported attempted_retries = 0
all paid rows had status = success

This also does not look like gateway retry amplification:

attempted_retries = 0 on all 1,057 successful requests

The concerning part is the mismatch:

visible CLI stream-json events: small / normal-sized trace
upstream model calls: 1,057 successful chat completions

Happy to provide sanitized logs or run a smaller reproduction if maintainers can suggest what internal debug flags would help.

Start with the prompt-mode kimi -p ... --output-format stream-json entry point and provider/agent-loop behavior, then compare visible stream-json events with the gateway's chat-completion logs. Reproduce the request-count mismatch if possible; done means identifying whether the calls are expected or a failure mode and defining the needed telemetry or call guardrail.