State the missing idle gate for automatic llama unload #54

Merged

Breadway merged 3 commits from fix/ram-79-honest-llama-capability into main 2026-10-20 11:55:20 +08:00

Conversation 2 Commits 3 Files changed 4 +81 -14

Breadway commented 2026-10-20 08:46:06 +08:00

Owner

Copy link

Closes RAM-79

Choose the explicitly permitted documented-limitation resolution, not fabricated idleness. Loaded llama router models remain Unknown activity and cannot pass daemon planner/executor idle gates. The low-level unload API and conformance implementation remain intact, as does native sleep observation.

Correct registry runtime notes and docs to distinguish protocol API availability from safe automatic relief. Gateway in-flight leases alone do not establish complete idleness. No existing safety gate is weakened or functional surface removed.

Tests pin that automation-enabled loaded residency remains Unknown after multiple idle periods, while low-level operation construction remains available. A registry test verifies diagnostics explicitly say automatic loaded-model unload is unavailable. Full workspace tests, clippy -D warnings and fmt pass. RAM-30 must record automatic llama policy efficacy as unsupported, not a pass.

Closes RAM-79 Choose the explicitly permitted documented-limitation resolution, not fabricated idleness. Loaded llama router models remain Unknown activity and cannot pass daemon planner/executor idle gates. The low-level unload API and conformance implementation remain intact, as does native sleep observation. Correct registry runtime notes and docs to distinguish protocol API availability from safe automatic relief. Gateway in-flight leases alone do not establish complete idleness. No existing safety gate is weakened or functional surface removed. Tests pin that automation-enabled loaded residency remains Unknown after multiple idle periods, while low-level operation construction remains available. A registry test verifies diagnostics explicitly say automatic loaded-model unload is unavailable. Full workspace tests, clippy -D warnings and fmt pass. RAM-30 must record automatic llama policy efficacy as unsupported, not a pass.

Breadway added 1 commit 2026-10-20 08:46:06 +08:00

fix: state the missing idle gate for automatic llama model unload 8816d98960

Breadway reviewed 2026-10-20 11:33:38 +08:00

Breadway left a comment

Copy link

Reviewed head 8816d98960. Verdict: changes requested. Not merged.

Forgejo refused a formal REQUEST_CHANGES review because this token is the PR author ("reject your own pull is not allowed"). This comment is the persisted review.

The permitted documented-limitation path is implemented for the canonical adapter doc and the registry note, and the safety gates are intact. One operator-facing doc still states the unreachable automatic unload as if it works.

Acceptance mapping:

• Docs state llama unload is manual/API only and RAM-30 must record the limitation: fail. docs/LLAMACPP.md:3-8 and :34-45, and the registry note in crates/breadram-core/src/adapter/mod.rs:545-549, correctly say daemon-driven unload of a loaded model is unavailable and that gateway leases do not prove idleness. docs/AGENT-HANDOFF.md:79-84 still says the llama.cpp adapter, when automation is enabled, can unload one loaded router model. That is the same claim this card exists to remove. The handoff is the starting point for the next agent, so the wording is not coherent.
• No misleading may-unload left for this provider: fail for the handoff sentence above. The old registry phrase "may unload a router model" is gone and pinned by adapter::tests::llama_automation_note_does_not_claim_loaded_model_relief. The breadsearch "may unload the breadmill model" note is a different provider and is not this card.
• Every safety gate preserved: pass. LlamaCppAdapter::activity still returns Unknown when holding_anything (llamacpp.rs:473-495, holding_anything at :553-562). Planner still skips UnloadIdleModel without is_confirmed_idle (planner.rs:187-196). AdapterExecutor::resolve still denies Unknown (executor.rs:266-268). Daemon folds gateway leases only as Active (daemon.rs:1441-1451). Native sleep observation is unchanged.
• Low-level API not removed: pass. operation() still builds POST /models/unload for one loaded router model (llamacpp.rs:498-543). Existing confirmation tests remain.
• Tests pin the behavior: pass. automation_never_turns_loaded_residency_into_confirmed_idleness observes loaded status at 1s, 61s, and 121s, asserts ActivityEvidence::Unknown and not confirmed idle at 30s, and still asserts operation() is Some (llamacpp.rs:822-850). Registry note test asserts the unavailable sentence and rejects "may unload a router model" (mod.rs:841-861).
• Runtime behavior, not just the diff: pass for the unit pins. Independent isolated run at this SHA: cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked. All passed, including the two new tests (424 breadram-core unit tests). Required workflow "CPU checks / check (push)" is success on this exact SHA (actions run 126).

Requested changes:

1. docs/AGENT-HANDOFF.md:79-84: replace the claim that automation can unload one loaded router model. State that the low-level POST /models/unload operation remains for conformance, daemon policy cannot unload a loaded model because activity stays Unknown, and automatic relief stays unavailable until trustworthy request tracking exists. Point at docs/LLAMACPP.md. Keep the real-server verification as evidence of the protocol, not of daemon policy.
2. Re-scan docs for any remaining sentence that says enabling automation unloads a loaded llama router model. README.md:91 is a pointer only and can stay if the linked doc remains the honest one.

Do not weaken planner or executor idle gates, and do not delete the low-level unload operation, to clear this review.

Reviewed head 8816d98960e68e131a43d3f04e6d0d9d7637ee69. Verdict: changes requested. Not merged. Forgejo refused a formal REQUEST_CHANGES review because this token is the PR author ("reject your own pull is not allowed"). This comment is the persisted review. The permitted documented-limitation path is implemented for the canonical adapter doc and the registry note, and the safety gates are intact. One operator-facing doc still states the unreachable automatic unload as if it works. Acceptance mapping: - Docs state llama unload is manual/API only and RAM-30 must record the limitation: fail. docs/LLAMACPP.md:3-8 and :34-45, and the registry note in crates/breadram-core/src/adapter/mod.rs:545-549, correctly say daemon-driven unload of a loaded model is unavailable and that gateway leases do not prove idleness. docs/AGENT-HANDOFF.md:79-84 still says the llama.cpp adapter, when automation is enabled, can unload one loaded router model. That is the same claim this card exists to remove. The handoff is the starting point for the next agent, so the wording is not coherent. - No misleading may-unload left for this provider: fail for the handoff sentence above. The old registry phrase "may unload a router model" is gone and pinned by adapter::tests::llama_automation_note_does_not_claim_loaded_model_relief. The breadsearch "may unload the breadmill model" note is a different provider and is not this card. - Every safety gate preserved: pass. LlamaCppAdapter::activity still returns Unknown when holding_anything (llamacpp.rs:473-495, holding_anything at :553-562). Planner still skips UnloadIdleModel without is_confirmed_idle (planner.rs:187-196). AdapterExecutor::resolve still denies Unknown (executor.rs:266-268). Daemon folds gateway leases only as Active (daemon.rs:1441-1451). Native sleep observation is unchanged. - Low-level API not removed: pass. operation() still builds POST /models/unload for one loaded router model (llamacpp.rs:498-543). Existing confirmation tests remain. - Tests pin the behavior: pass. automation_never_turns_loaded_residency_into_confirmed_idleness observes loaded status at 1s, 61s, and 121s, asserts ActivityEvidence::Unknown and not confirmed idle at 30s, and still asserts operation() is Some (llamacpp.rs:822-850). Registry note test asserts the unavailable sentence and rejects "may unload a router model" (mod.rs:841-861). - Runtime behavior, not just the diff: pass for the unit pins. Independent isolated run at this SHA: cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked. All passed, including the two new tests (424 breadram-core unit tests). Required workflow "CPU checks / check (push)" is success on this exact SHA (actions run 126). Requested changes: 1. docs/AGENT-HANDOFF.md:79-84: replace the claim that automation can unload one loaded router model. State that the low-level POST /models/unload operation remains for conformance, daemon policy cannot unload a loaded model because activity stays Unknown, and automatic relief stays unavailable until trustworthy request tracking exists. Point at docs/LLAMACPP.md. Keep the real-server verification as evidence of the protocol, not of daemon policy. 2. Re-scan docs for any remaining sentence that says enabling automation unloads a loaded llama router model. README.md:91 is a pointer only and can stay if the linked doc remains the honest one. Do not weaken planner or executor idle gates, and do not delete the low-level unload operation, to clear this review.

docs/AGENT-HANDOFF.md Outdated

Show outdated Hide outdated

Breadway commented 2026-10-20 11:33:38 +08:00

Author

Owner

Copy link

This still says enabling automation can unload one loaded router model. That is the claim RAM-79 exists to retire. docs/LLAMACPP.md now says daemon-driven unload is unavailable because loaded residency is Unknown and the idle gate is not bypassed. Rewrite this paragraph to match: low-level POST /models/unload stays for conformance, daemon policy cannot unload a loaded model, and the real-server numbers are protocol evidence, not automatic-policy evidence.

This still says enabling automation can unload one loaded router model. That is the claim RAM-79 exists to retire. docs/LLAMACPP.md now says daemon-driven unload is unavailable because loaded residency is Unknown and the idle gate is not bypassed. Rewrite this paragraph to match: low-level POST /models/unload stays for conformance, daemon policy cannot unload a loaded model, and the real-server numbers are protocol evidence, not automatic-policy evidence.

Breadway referenced this pull request 2026-10-20 11:33:45 +08:00

llama.cpp loaded model never reports idle so daemon policy can never unload it #46

Breadway added 2 commits 2026-10-20 11:53:05 +08:00

Merge remote-tracking branch 'origin/main' into fix/ram-79-honest-llama-capability 04a1878ea5

docs: correct the llama automatic unload handoff claim de0268f6f5

Breadway merged commit 455d3c45a6 into main 2026-10-20 11:55:20 +08:00

Breadway referenced this pull request from a commit 2026-10-20 11:55:20 +08:00

Merge pull request 'State the missing idle gate for automatic llama unload' (#54) from fix/ram-79-honest-llama-capability into main

Breadway commented 2026-10-20 11:55:37 +08:00

Author

Owner

Copy link

Reviewed head de0268f6f5. Verdict: pass. Merged as 455d3c45a6.

The previous change request on 8816d989 is addressed. docs/AGENT-HANDOFF.md no longer says automation can unload one loaded llama router model. The card is not marked done: the coordinator still verifies the integrated result.

Acceptance mapping:

• No remaining docs claim that llama automation unloads a loaded model: pass. docs/AGENT-HANDOFF.md:79-86 now says the adapter implements the documented router unload API, but daemon policy cannot automatically unload a loaded model because residency does not prove idleness, and it points at docs/LLAMACPP.md for the missing idle gate. docs/LLAMACPP.md:3-8 and :34-45 say the same. README.md:91 is a pointer only. A repo scan found no remaining sentence that says enabling automation unloads a loaded llama router model.
• Idle gates unchanged: pass. LlamaCppAdapter::activity still returns Unknown when holding_anything (llamacpp.rs:473-495, holding_anything at :553-562). Planner still skips without is_confirmed_idle (planner.rs:187-196). AdapterExecutor::resolve still denies unconfirmed idle (executor.rs:266-268). Daemon folds gateway leases only as Active (daemon.rs:1456-1465).
• Low-level POST /models/unload still constructed: pass. operation() still builds it for one loaded router model (llamacpp.rs:498-543). Direct confirmation wording remains in the handoff and in a_router_unload_is_confirmed_by_the_exact_model_id_and_status.
• Registry note and tests still pin Unknown activity: pass. Registry note at adapter/mod.rs:545-549. llama_automation_note_does_not_claim_loaded_model_relief asserts the unavailable sentence and rejects "may unload a router model" (mod.rs:841-861). automation_never_turns_loaded_residency_into_confirmed_idleness asserts Unknown and not confirmed idle at 1s, 61s, and 121s, and still asserts operation() is Some (llamacpp.rs:822-850).

Merge of origin/main (04a1878, parents 8816d98 and 99eea2b) brought RAM-78 and RAM-84 into the branch. That diff is breadsearch revalidation, not a llama idle-gate change.

Evidence: isolated scratch worktree at this SHA. cargo test --locked -p breadram-core --lib for the three named tests: all passed. Required workflow "CPU checks / check (push)" success on this exact SHA (actions run 130, successful in 41s). Outstanding review on 8816d98 was stale COMMENT, not a live change request. Merge used the repo merge style with head_commit_id pinned to de0268f6. Confirmed merge commit 455d3c45a6 has parents 99eea2ba and de0268f6.

Reviewed head de0268f6f5aba9ef9e29b8c7576c22d81bf8a114. Verdict: pass. Merged as 455d3c45a6800fa571080ea7344c3027ada6c4f8. The previous change request on 8816d989 is addressed. docs/AGENT-HANDOFF.md no longer says automation can unload one loaded llama router model. The card is not marked done: the coordinator still verifies the integrated result. Acceptance mapping: - No remaining docs claim that llama automation unloads a loaded model: pass. docs/AGENT-HANDOFF.md:79-86 now says the adapter implements the documented router unload API, but daemon policy cannot automatically unload a loaded model because residency does not prove idleness, and it points at docs/LLAMACPP.md for the missing idle gate. docs/LLAMACPP.md:3-8 and :34-45 say the same. README.md:91 is a pointer only. A repo scan found no remaining sentence that says enabling automation unloads a loaded llama router model. - Idle gates unchanged: pass. LlamaCppAdapter::activity still returns Unknown when holding_anything (llamacpp.rs:473-495, holding_anything at :553-562). Planner still skips without is_confirmed_idle (planner.rs:187-196). AdapterExecutor::resolve still denies unconfirmed idle (executor.rs:266-268). Daemon folds gateway leases only as Active (daemon.rs:1456-1465). - Low-level POST /models/unload still constructed: pass. operation() still builds it for one loaded router model (llamacpp.rs:498-543). Direct confirmation wording remains in the handoff and in a_router_unload_is_confirmed_by_the_exact_model_id_and_status. - Registry note and tests still pin Unknown activity: pass. Registry note at adapter/mod.rs:545-549. llama_automation_note_does_not_claim_loaded_model_relief asserts the unavailable sentence and rejects "may unload a router model" (mod.rs:841-861). automation_never_turns_loaded_residency_into_confirmed_idleness asserts Unknown and not confirmed idle at 1s, 61s, and 121s, and still asserts operation() is Some (llamacpp.rs:822-850). Merge of origin/main (04a1878, parents 8816d98 and 99eea2b) brought RAM-78 and RAM-84 into the branch. That diff is breadsearch revalidation, not a llama idle-gate change. Evidence: isolated scratch worktree at this SHA. cargo test --locked -p breadram-core --lib for the three named tests: all passed. Required workflow "CPU checks / check (push)" success on this exact SHA (actions run 130, successful in 41s). Outstanding review on 8816d98 was stale COMMENT, not a live change request. Merge used the repo merge style with head_commit_id pinned to de0268f6. Confirmed merge commit 455d3c45a6800fa571080ea7344c3027ada6c4f8 has parents 99eea2ba and de0268f6.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Breadway/breadram!54

No description provided.