lingyuzeng/collective-memory-repo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add cKimi Warp alias and continuation fallback rule

Browse Source
This commit is contained in:
hotwa
2026-03-17 20:06:03 +08:00
parent 2f2d23592a
commit bf12bc2b37
3 changed files with 51 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
shared/long-term/projects/warp-acp-integration.md
View File

@@ -186,12 +186,41 @@ This preserves behavior consistency as much as possible before changing model fa
For `opencode-warp-infini-kimi`:
1. primary: `infini / kimi-k2.5`
2. fallback-1: another provider offering `kimi-k2.5` (for example `ckimi / kimi-k2.5`)
2. fallback-1: `ckimi / kimi-for-coding`
3. fallback-2: `infini / glm-5`
4. fallback-3: `infini / minimax-m2.5`
For `opencode-warp-ckimi-kimi-for-coding`:
1. primary: `ckimi / kimi-for-coding`
2. fallback-1: `infini / kimi-k2.5`
3. fallback-2: `infini / glm-5`
4. fallback-3: `infini / minimax-m2.5`
Exact fallback order should be documented per agent as providers are added.
### ACP continuation rule after provider limit / request failure
When an ACP task fails mid-run because a provider is limited, rate-limited, quota-exhausted, or otherwise request-blocked, the system should not just restart blindly.
Use this continuation rule:
1. detect that the failure is provider/request related rather than task-logic related
2. produce a concise task-state summary of what had already been completed, what failed, and what remains
3. start a new `opencode` ACP run using the next Warp fallback agent
4. pass the summary into the new run so the replacement agent can continue instead of redoing everything from scratch
The summary should include, when available:
- original task goal
- completed steps
- files changed or attempted
- command outputs or relevant error lines
- exact provider failure signal (for example rate limit / quota exhaustion)
- remaining work
This behavior is part of the Warp fallback design, especially for long-running coding tasks where provider limits may interrupt execution mid-stream.
## Operational Reminder
If runtime errors show quota exhaustion or provider-specific capacity limits during an ACP task, the operator should treat that as a routing event, not just a task failure. The next step is to move to the documented fallback provider/model path.