Repository navigation
Effort picked on a chat with no model pinned is not applied when cli.json is over 1 MiB #22819
Description
Problem
#14528 reads a work directory's .kiro/settings/cli.json only up to 1 MiB (_CLI_JSON_MAX_BYTES in providers/acp_cli_overlay.py). A larger file is left unchanged, and the effort overlay write raises.
On a chat with no model pinned, _bind_unbound_effort applies the chat's level once the session names its model. On kiro-cli it does that through change_effort, which writes the overlay before it pushes /effort. Over 1 MiB the write is refused, so change_effort rolls back and raises before the push. _bind_unbound_effort logs ACP unpinned effort apply failed, and _reassert_projected_effort then resolves no chat level for the served model. The session runs whatever the file or a workspace default gives that model, while the picker shows the chat's level.
A chat with a pinned model keeps its level through the same refusal: the refused pre-spawn projection leaves the level stored for its model, and _reassert_projected_effort pushes it after the spawn.
The GPT review lane found this on #14528 at c640ad3 (providers/acp_model_effort.py#L854), and the lane's adjudication rated it non-blocking. The 1 MiB row of #14528's description states both cases.
Proposal
When the bind's overlay write is refused, keep the level stored for the served model and push it with /effort, as the pinned path does.
kiro-cli drops a pushed level on session/set_model and session/set_mode when the file holds none (measured on kiro-cli 2.29.0, in #14528's Not-a-goal list). So the fix needs a re-push on any live path that sends either call.
Tests: with nothing pinned and a valid cli.json over 1 MiB, the picked level is pushed after the spawn and the file stays byte-for-byte unchanged; a pinned chat behaves as it does today.
#22496 removes this path for good by carrying a session's effort per session instead of through the shared file.
Activity
KiroCrewCaptain commentedon Oct 21, 2026
Thanks for the report. This issue has been triaged by Crew Captain and will be assigned to a maintainer, who will follow up here.
chenmingwei23 commentedon Oct 21, 2026
On current
mainthe picked effort is applied with acli.jsonover 1 MiB, so this does not reproduce there.I drove the real no-model-pinned bind path (
_bind_unbound_effort→change_effort→ the overlay write) against a valid.kiro/settings/cli.jsonof ~1.3 MiB with nothing pinned and an effort-capable served model. The level was stored for the served model,/effortwas pushed live, and the overlay write landed in the >1 MiB file (its existing content preserved). Onmainthe overlay writer readscli.jsonwith an unboundedread_text, so there is no 1 MiB read ceiling on that path.The 1 MiB read limit that causes the reported behaviour (
_CLI_JSON_MAX_BYTESinproviders/acp_cli_overlay.py) exists only on the open PR #14528, not onmain. So there is nothing onmainto change here — the fix belongs in #14528 (or a follow-up once it merges), where the proposal to keep the level stored for the served model and push it with/efforton the refused-write path applies.Leaving this open and marked
needs-infopending #14528.KiroCrewCaptain commentedon Oct 21, 2026
Please reply here by 2026-10-28. Until then, this issue waits for your answer.
unstablebrainiac commentedon Oct 21, 2026
@chenmingwei23 Right, the 1 MiB ceiling comes with #14528, so nothing on main changes before it merges. This issue is the follow-up for after that merge: the case reproduces on #14528's head, and its description's 1 MiB row states it.