Question 1

Bedrock Claude 5 프롬프트 캐싱에서 cachePoint 블록이 전송되지 않고 모든 요청이 새로운 입력으로 과금되는 문제를 어떻게 해결하나요?

Accepted Answer

이것은 prime-agent `packages/ai` 0.7.x 및 커밋 `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` 패키지를 다시 빌드하고 재배포한 후, 동일한 프리픽스로 두 번 연속 `ConverseStream` 호출을 수행하세요. 두 번째 응답은 `cacheReadInputTokens > 0`을 보고해야 합니다; `us.anthropic.claude-fable-5-1`에서 테스트한 결과 `cacheReadInputTokens: 21829`가 반환되었습니다. 캐시 읽기 토큰과 신규 입력 토큰을 모니터링하여 캐싱이 활성화되어 있는지 확인하세요.

Question 2

잘못된 형식의 non-ASCII CSI 이스케이프 시퀀스로 인해 발생하는 pa-tui 패닉 "byte index is not a char boundary"을 해결하는 방법은?

Accepted Answer

패닉은 `decode_csi_with_modifier`가 UTF-8 바이트 오프셋을 요구하는 `str::split_at`에 유니코드 문자 개수를 전달하기 때문에 발생합니다. `\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 스냅샷 복원 시 쓰기 모드 파일이 0바이트로 잘려나가는 것을 어떻게 방지할 수 있나요?

Accepted Answer

이 오류는 dill 0.4.1이 닫힌 핸들을 포함한 파일 객체를 `_create_filehandle(name, mode)`로 직렬화하기 때문에 발생합니다. `_restore_state`가 `dill.loads()`를 호출하면 dill이 저장된 경로를 다시 엽니다. 저장된 모드가 `"w"`인 경우 재오픈 시 `O_TRUNC`가 사용되어, 로드 후 검사가 핸들을 닫기 전에 파일이 아무런 경고 없이 0바이트로 초기화됩니다.

즉시 적용 가능한 해결 방법:

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`의 로드 후 파일 객체 검사는 심층 방어(defense-in-depth) 차원의 정리에 불과하며, 최초의 `O_TRUNC`를 막을 수 없습니다. 가능한 경우 v0.1.21 복구 안전성 수정이 포함된 릴리스로 업그레이드하고, 영향을 받은 파일은 백업에서 복원하세요.

Question 4

모델 응답이 max_tokens에서 잘렸는데도 ACP session/prompt가 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`이거나 출력 토큰이 토큰 상한과 같은 경우를 잘림으로 처리하세요.

Question 5

oMLX / OpenAI 호환 로컬 모델에서 auto-compaction이 "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 오류 메시지를 인식하지 못해 컴팩션, 후행 어시스턴트 제거 또는 재시도가 수행되지 않으며, 세션 내 이후의 모든 프롬프트가 동일하게 실패합니다. 이는 두 가지 정규식 누락 때문입니다: (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