llama-cppでPiをコーディングエージェントとして使っているときに、問題に気づきました。Pi側に問題があるのか、それとも自分の設定に何か不備があるのか、あるいはこれが単に予想される挙動なのかを確認したいです。
thinking を有効にした状態で、Qwen3.5 122b を使っています。エージェントによる編集を大量に行うと、思考（thinking）の処理とツール呼び出しがかなり細かく交互に挟まります。これら自体はすべて問題なく動作しています。
しかし次のターンで入力を渡す段階になると、コンテキストキャッシュが大量に無効化されます。Piが前のターンの thinking ブロックを送っていないように見えるためです。これは llama-cpp のログで確認できます。thinking ブロックを落として分岐したことが分かります：
srv params_from_: Chat format: peg-native slot get_availabl: id 3 | task -1 | selected slot by LCP similarity, sim_best = 0.736 (> 0.100 thold), f_keep = 0.703 slot launch_slot_: id 3 | task -1 | sampler chain: logits -> ?penalties -> ?dry -> ?top-n-sigma -> top-k -> ?typical -> top-p -> min-p -> ?xtc -> temp-ext -> dist slot launch_slot_: id 3 | task 29044 | processing task, is_child = 0 slot update_slots: id 3 | task 29044 | new prompt, n_ctx_slot = 262144, n_keep = 0, task.n_tokens = 48112 slot update_slots: id 3 | task 29044 | old: ... <|im_start|>assistant | <think> The user is saying slot update_slots: id 3 | task 29044 | new: ... <|im_start|>assistant | You're right - ball-to slot update_slots: id 3 | task 29044 | 198 248045 74455 198 248068 198 760 1156 369 5315 slot update_slots: id 3 | task 29044 | 198 248045 74455 198 2523 2224 1245 471 4776 4534 slot update_slots: id 3 | task 29044 | n_past = 35407, slot.prompt.tokens.size() = 50377, seq_id = 3, pos_min = 50376, n_swa = 0 そして、thinking コンテキストが落とされたところから履歴が分岐したため、いくつかのコンテキストチェックポイントが無効化され、そこからキャッシュを再計算しているように続きます。
まだこの点を深く掘り下げられてはいないのですが、確認したいことがあります。こういう挙動は予想されるものですか？設定を間違えているのでしょうか、それとも Pi が過去のターンから thinking コンテキストを送っていないことがバグなのでしょうか？
以下は、Pi 設定の models.json から取ってきたモデル設定です：
{ "id": "unsloth/Qwen3.5-122B-A10B-GGUF:UD-Q4_K_XL", "name": "Qwen3.5 122B-A10B (local)", "reasoning": true, "input": ["text", "image"], "contextWindow": 262144, "maxTokens": 65536, "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }, "compat": { "thinkingFormat": "qwen-chat-template" } }, [link] [comments]
