Question 1

Bedrock Claude 5 でプロンプトキャッシュが cachePoint ブロックを送信せず、すべてのリクエストが新規入力として課金される問題を修正するにはどうすればよいですか？

Accepted Answer

これは prime-agent の `packages/ai` 0.7.x および commit `9fb6cde` の `main` における `packages/ai/src/providers/amazon-bedrock.ts` のバグです。`supportsPromptCaching()` は `-4-`、`claude-3-7-sonnet`、または `claude-3-5-haiku` を含むモデル ID に対してのみキャッシュを有効にするため、`claude-fable-5-1`、`claude-opus-5-5`、`claude-sonnet-5` などの Claude 5 ID では `cachePoint` ブロックが暗黙的に省略されます。`AWS_BEDROCK_FORCE_CACHE=1` を設定しても機能しません。これは、関数がその環境変数をチェックする前に Claude モデルの分岐からリターンしてしまうためです。上流の修正を適用するか、Claude 5 以降のモデルを認識するように関数にパッチを適用してください: 既存の `-4-` および従来の Claude チェックの横に `if (candidates.some((s) => /claude-(?:fable|opus|sonnet|haiku)-(?:[5-9]|\d{2,})(?:-|$)/.test(s))) return true;` を追加します。より安全な長期的な修正は、3.7 以前のモデルの短い拒否リストを除き、すべての Claude モデルがキャッシュをサポートしていると仮定することです。`packages/ai` パッケージを再ビルドして再デプロイし、同じプレフィックスで 2 回連続の `ConverseStream` 呼び出しを行います。2 回目のレスポンスでは `cacheReadInputTokens > 0` が報告されるはずです。`us.anthropic.claude-fable-5-1` でのテストでは `cacheReadInputTokens: 21829` が返されました。キャッシュ読み取りトークンと新規入力トークンを監視して、キャッシュが有効であることを確認してください。

Question 2

不正な非ASCII CSIエスケープシーケンスが原因で発生する pa-tui のパニック "byte index is not a char boundary" を修正する方法

Accepted Answer

パニックが発生するのは、`decode_csi_with_modifier` が Unicode の文字数を `str::split_at` に渡しているためです。`str::split_at` は UTF-8 のバイトオフセットを要求します。`\x1b[;éA` のような入力に含まれる `é` のようなマルチバイト文字では、計算されたオフセットが文字の内部に入り込んでしまうことがあります。

`crates/pa-tui/src/input.rs` で、次のコードを:

```rust
let (modifier, final_char) = last.split_at(last.chars().count() - 1);
```

`char_indices` から導出したバイト境界を使う次のコードに置き換えてください:

```rust
let final_index = last
    .char_indices()
    .next_back()
    .map_or(0, |(index, _)| index);
let (modifier, final_char) = last.split_at(final_index);
```

これにより、最後の UTF-8 文字の先頭で分割されます。その後、既存の `modifier.parse::<u8>()` が、TUI をクラッシュさせる代わりに、不正な形式のプレフィックスを通常どおり拒否します。issue #3175 の修正を含むビルドを使用してください。それまでは、不正な形式の非 ASCII CSI シーケンスをターミナルに送信しないでください。

Question 3

カーネル再起動後に dill のスナップショット復元によって書き込みモードのファイルがゼロバイトに切り詰められるのを防ぐにはどうすればよいですか？

Accepted Answer

この障害は、dill 0.4.1 がクローズされたハンドルを含むファイルオブジェクトを `_create_filehandle(name, mode)` としてシリアライズするために発生します。`_restore_state` が `dill.loads()` を呼び出すと、dill は保存されたパスを再度開きます。保存されたモードが `"w"` の場合、再オープン時に `O_TRUNC` が使用され、ロード後のチェックがハンドルを閉じる前に、ファイルが警告なくゼロ化されます。

即時の回避策:

1. `with open(...) as f` の変数をカーネルの名前空間に残さないでください。ブロックの後で削除してください:
```python
with open("/path/file.md", "w") as f:
    f.write(data)
del f
```

2. 再起動する前に、名前空間からファイルオブジェクトをすべて削除してください:
```python
import io
for name, value in list(globals().items()):
    if isinstance(value, io.IOBase):
        try:
            value.close()
        except Exception:
            pass
        del globals()[name]
```

3. dill の `_create_filehandle` を含む既存のスナップショットレコードは、`dill.loads()` が実行される前に破棄または除去する必要があります。ロード後にオブジェクトをチェックしても、デシリアライズ中にファイルがすでに切り詰められているため、手遅れです。

`prime-agent-runtime/src/rlm/repl.py` の `_snapshot_state`（約714行目）での恒久的な修正:
```python
import io

if isinstance(value, io.IOBase):
    skipped.append({"name": name, "reason": "file handle"})
    continue
```

また、デシリアライズの前に、`_read_snapshot_records` でレガシーな `_create_filehandle` レコードを除去してください。`_restore_state` でのロード後のファイルオブジェクトチェックは、多層防御のためのクリーンアップにすぎず、最初の `O_TRUNC` を防ぐことはできません。利用可能な場合は、v0.1.21 のリカバリ安全性修正を含むリリースにアップグレードし、影響を受けたファイルをバックアップから復元してください。

Question 4

なぜ ACP の session/prompt は、モデルのレスポンスが max_tokens で切り捨てられた場合でも end_turn を返すのですか？

Accepted Answer

これは prime-agent の ACP stop-reason マッピングにおけるバグです。キャンセルフラグと自律トークン予算ステータスのみを考慮するため、`finish_reason: "length"` を返した最後のモデル呼び出しが `stopReason: "end_turn"` として誤って報告されます。修正 `acp: report max_tokens when the final model response was truncated` を含むリリースにアップグレードしてください。ソースからビルドする場合は、`crates/pa-daemon/src/acp/meta.rs` 内の `acp_stop_reason_for_status` と、`acp-stop-reason.ts` 内の TypeScript の `acpStopReason` マッピングを更新し、最後のアシスタントメッセージの `stopReason: "length"` が ACP の `stopReason: "max_tokens"` にマッピングされるようにしてください。回避策としては、呼び出しごとのモデルトレースを調べ、`finish_reason=length` であるか、出力トークン数がトークン上限と等しい場合を切り詰め（truncation）として扱ってください。

Question 5

oMLX / OpenAI互換のローカルモデルで、自動コンパクションが「Prompt is too long: N tokens > M maximum context length」エラーで失敗するのはなぜですか？

Accepted Answer

オーバーフロー検出器 `is_context_overflow`（`crates/pa-ai/src/utils_inner/overflow.rs`）は oMLX の 400 エラーメッセージを認識しないため、コンパクション、末尾のアシスタントメッセージの削除、リトライのいずれも行われず、セッション内の後続のプロンプトはすべて同じように失敗します。これは正規表現の 2 つの抜け漏れが原因です: (1) `prompt is too long` パターンは大文字小文字を区別しますが、oMLX は "Prompt" を大文字で始めています。(2) `maximum context length is \d+ tokens` パターンは、oMLX の `N tokens > M maximum context length` とは異なる語順を想定しています。修正方法: パターンを `(?i)prompt is too long` に変更する、および/または新しいパターン `(?i)tokens > \d+ maximum context length` を追加します。パッチが適用されるまでの回避策: コンテキストウィンドウの小さいモデル（例: 大規模な OpenRouter モデルから 262k のローカルモデル）にセッションを切り替える場合は、オーバーフローが発生する前に手動でコンパクションを実行するか、新しいセッションを開始してください。

prime-agent

概要

README プレビュー

FAQ (5)

同类型项目

hermes-agent

firecrawl

go

markitdown