리콜 캐싱

반복되는 리콜은 10분의 1 가격으로.

요청당 옵트인하면 WOS가 검색 결과를 쿼리 텍스트 기준으로 캐시합니다. 규칙은 LLM 프롬프트 캐싱과 동일한 프리픽스 방식입니다. 캐시가 살아 있는 동안 반복되거나 이어지는 쿼리는 이전 결과를 재사용하고, 캐시된 부분은 정상 토큰 단가의 10%로 청구됩니다.

태블릿·스크롤 한정. 캐싱은 현재와 미래의 모든 태블릿·스크롤 모델에서 동작합니다. Book은 지원하지 않습니다. Book은 기억 위에서 추론하고 호출 사이에 학습하기 때문에 같은 질문에도 답이 정당하게 달라질 수 있고, 캐시된 결과는 설계상 틀린 답이 됩니다. Book에 cache_control을 보내면 403으로 명확하게 알려드립니다.

대화 하나, 세 턴

에이전트가 기억과 계속 대화할 때 실제로 벌어지는 일입니다. 매 턴, 지금까지의 대화를 쿼리로 보내고 cache_control을 켭니다.

write턴 1 - "앨리스: 나 지난봄에 리스본으로 이사했어."

전체 쿼리를 검색하고 캐시합니다: 입력이 2배 (TTL 5분).

extend턴 2 - 같은 텍스트 + "밥: 거기 날씨는 어때?"

밥의 문장만 색인하고 검색합니다. 이전 부분은 0.1배, 새 문장은 2배, 캐시는 이제 그 문장에서 끝납니다.

hit턴 3 - 완전히 같은 쿼리를 다시 (재시도, 새로고침)

엔진 호출이 아예 없습니다. 전부 0.1배: 90% 할인입니다.

요율

동작	토큰 과금	의미
캐시 쓰기 - TTL 5분	2×	첫 요청입니다. 결과는 5분 동안 유지되며, 읽을 때마다 유효시간이 앞으로 밀립니다.
캐시 쓰기 - TTL 1시간	3×	첫 요청이며, 한 시간 동안 유지됩니다.
캐시 읽기 - 히트 또는 프리픽스 히트	0.1×	쓰기 이후의 모든 요청: 캐시된 부분은 정상 토큰 단가의 10분의 1로 계산됩니다.

얼마나 아끼나

구체적인 예시입니다. 에이전트가 3,000토큰짜리 대화를 쿼리로 보내고 5분 안에 10번 반복하거나 이어갑니다. 캐싱이 없으면 정가로 30,000 입력 토큰입니다. 5분 캐시를 켜면 첫 쓰기 6,000(2배) + 아홉 번의 캐시 읽기 약 2,700 = 청구 토큰 8,700, 71% 절약입니다. 대화가 길어질수록 절약도 커집니다.

프리픽스 규칙

매칭은 쿼리의 앞부분 기준입니다. 앞이 그대로이고 뒤에 새 텍스트만 붙으면 캐시된 부분을 재사용하고 새 부분만 검색합니다. 캐시된 텍스트 끝보다 앞에서 무언가 바뀌면 아무것도 재사용할 수 없습니다.

prefix match

cached    [ A B C D E F G ]

○   [ A B C D E F G ] E
✗   [ B C D E F G ] E

○ 히트 - 앞이 그대로이고 E만 새로 들어왔습니다
✗ 미스 - 앞이 바뀌어서 전체 쿼리를 다시 검색하고 다시 캐시합니다

기억해야 할 규칙 세 가지

연장하면 새 꼬리까지 다시 캐시합니다. [A B C D E F G] + E 다음에는 캐시가 E에서 끝납니다. 꼬리는 쓰기 요금으로 한 번 계산되고, 다음 턴은 A부터 E까지 전체를 프리픽스로 다시 매칭할 수 있습니다.
요청당 연속된 프리픽스 하나입니다. 하나의 쿼리를 두 개의 캐시 조각으로 나눌 수 없고, 오직 앞부분만 매칭됩니다.
쓰기는 즉시 무효화합니다. store, store-turn, bulk-store, forget, supersede, 저장소 삭제가 일어나면 그 저장소의 캐시는 버려집니다. 캐시된 답이 낡은 기억을 돌려주는 일은 없습니다.

켜는 법

   
hits = mem.search(
    "...the conversation so far...", user_id="alice",
    cache_control={"ttl": "5m"},   # or "1h"
)
const hits = await mem.search(
  "...the conversation so far...", "alice", 10,
  { cache_control: { ttl: "5m" } },   // or "1h"
);
let hits = mem.search_with(
    "...the conversation so far...", "alice", 10,
    serde_json::json!({"cache_control": {"ttl": "5m"}}),   // or "1h"
).await?;
curl -X POST https://api.wontopos.com/api/v1/memory/search \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice",
       "query":"...the conversation so far...",
       "cache_control":{"ttl":"5m"}}'   # or "1h"

응답 - cache 객체가 무슨 일이 있었는지 알려줍니다

{ "memories": [ ... ],
  "cache": { "status": "hit",              // "write" | "hit" | "extend"
             "ttl": "5m",
             "cache_read_input_tokens": 412,
             "cache_creation_input_tokens": 0 } }

이 기능에 SDK가 꼭 필요한 것은 아닙니다. 캐싱은 HTTP 호출 하나에 붙는 필드 하나라서 어떤 프로그래밍 언어에서든 동작합니다. curl 탭이 만능 레시피이고, Python·TypeScript·Rust SDK는 똑같은 호출을 감싼 편의 도구일 뿐입니다.

캐싱은 워크스페이스 안에서 저장소별, 모델별로 격리되며 기본값은 꺼짐입니다. cache_control을 보내지 않으면 요청은 아무것도 달라지지 않습니다.

Product

Models

Start