왜 WOS인가

AI 에이전트를 위한 장기 기억.

WOS는 기억 API입니다. 사용자의 기억을 한 번 저장해두고, 매 쿼리마다 관련된 것만 회수해 모델의 프롬프트에 넣습니다.

검색은 순수 의미 기반이며 키워드·BM25 매칭이 없어, 언어가 달라도 검색 품질이 같습니다. 저장량과 무관하게 한 쿼리는 작고 제한된 컨텍스트로 돌아오고, 당신의 저장된 기억 위엔 어떤 모델도 돌지 않습니다.

주요 동작

  • store - 사용자의 기억 하나를 저장합니다.
  • recall - 쿼리에 필요한 기억을 한 번에 회수합니다. 주로 쓰는 호출입니다.
  • search - 저장된 기억에 대한 원시 의미 검색입니다.
  • supersede - 오래된 기억을 갱신하거나 교체합니다.
  • forget - 기억 하나 또는 사용자 전체를 삭제합니다 (GDPR).
왼쪽에서 항목을 선택하세요 각 주제를 자세히 볼 수 있습니다.
모델

세 개의 모델, 하나의 계보.

WOS 모델은 사람이 지식을 지녀 온 방식에서 이름을 땁니다 - Tablet, Scroll, Codex. 돌판, 두루마리, 제본된 책. 뒤로 갈수록 엔진이 에이전트를 위해 해내는 일이 늘어납니다.

Tablet

사용 가능
돌에 새기다 · 저장과 회수

가볍고 빠르고 저렴하게 기억을 심고 꺼냅니다. 모든 모델이 위에 쌓이는 토대.

Scroll

사용 가능
두루마리를 펼치다 · LLM이 거드는 회수

언어 모델을 더해 질문을 더 깊이 읽고 더 넉넉한 컨텍스트를 데려와, 흩어진 근거가 하나 모자란 채가 아니라 함께 옵니다.

Codex

다음
책을 펴다 · 스스로 길을 찾다

상황에 맞는 기억과 도구를 스스로 골라 펼칩니다. 쓸수록 길을 더 잘 찾습니다.

Tablet 1의 전체 벤치마크 리포트는 벤치마크 페이지에 있습니다.

비용

우리에게 $2, LLM에선 그 몇 배를 아낍니다.

WOS는 매 프롬프트에 전체 히스토리를 욱여넣는 대신, 쿼리당 ~1,200개의 관련 토큰만 LLM에 전달합니다. 그 격차는 막대하고, 히스토리가 커질수록 더 벌어집니다.

1,000 쿼리당 LLM 비용 Tablet 1 기준
사용자 히스토리100K
월 쿼리 수1,000
사용 LLM
45× 더 저렴 - 월 $244 절감
WOS 없이$250.00
WOS 사용$5.50

WOS에 쓴 $1마다 LLM에서 ~$98을 아낍니다. 히스토리가 크거나 모델이 비쌀수록 ROI가 커집니다.

절감이 나오는 곳

  • WOS 없이는 매 프롬프트에 전체 히스토리를 넣습니다 - 100K 토큰 × $2.50/1M = $0.25, 매 쿼리마다 (GPT-4o 입력 단가 기준, Opus급 모델은 약 2배).
  • WOS는 한 번만 적재($2/1M)하고, 이후 각 쿼리는 작은 검색($3/1M × 1,200)과 ~1,200 토큰에 대한 LLM 호출뿐입니다.
  • LLM이 읽는 토큰이 적을수록 비용이 줄고, WOS는 기억이 커져도 그 수치를 일정하게 유지합니다.
컨텍스트 축소 = 히스토리 ÷ 투입 토큰이며 비용 배수가 아닙니다(비용은 위 계산기).  25K → 21× · 100K → 83× · 200K → 167×.
다국어

모든 언어, 같은 정확도.

검색은 순수 의미 기반입니다 - 임베딩만 쓰고 키워드나 BM25 매칭은 전혀 없습니다. 그래서 사용자가 日本語, 中文, Español, English 무엇으로 적어도 검색 품질이 동일합니다.

BM25 같은 어휘 매칭은 특정 언어의 형태 - 형태소, 띄어쓰기, 문자 체계 - 에 맞춰 동작합니다. 여러 언어를 섞어 쓰는 저장소에서는 그만큼 언어별로 검색 품질이 달라진다는 뜻입니다. WOS는 어휘 매칭을 아예 사용하지 않아, 모든 언어가 같은 경로를 지납니다.

한 저장소에 세 언어를 동시에

저장소마다 언어를 정할 필요가 없습니다 - 자유롭게 섞으세요. 아래는 한 사용자의 기억에 일본어·영어·스페인어가 동시에 들어있고, 어떤 언어로 묻든 맞는 기억을 찾아오는 모습입니다. 라이브 API에서 실제로 주고받은 내용입니다:

# one user, three languages stored together
mem.add("彼女はコーヒーより紅茶が好き", user_id="alice")                      # Japanese
mem.add("she works at a design studio in Brooklyn", user_id="alice")       # English
mem.add("A ella le encanta hacer senderismo los sábados", user_id="alice")  # Spanish
실제 결과 - 질문마다 다른 언어의 기억을 찾아냄
"¿Qué bebe ella?"               -> 彼女はコーヒーより紅茶が好き
"what does she do on weekends?" -> A ella le encanta hacer senderismo los sábados
"彼女の仕事は?"                  -> she works at a design studio in Brooklyn

번역 단계도, 언어 감지도, 언어별 설정도 없습니다. 기억과 질문은 언어가 아니라 의미로 배치됩니다 - 맥락과 의미만 같으면 언어가 달라도 찾아냅니다.

여기 세 언어는 지면에 맞춘 것일 뿐 - 애초에 "지원 언어 목록"이라는 게 없습니다. 같은 라이브 테스트가 中文·Русский·العربية 기억으로도 통과했고, 전부 운영 API에서 실측한 것입니다.

키워드를 일부러 금지한 이유

BM25 같은 어휘 점수는 특정 언어를 더 강화하는 성질이 있어, 한 저장소에 여러 언어를 담는 사용에서는 방해가 됩니다. 그래서 엔진에서 완전히 제거했고 코드 리뷰에서 규칙으로 강제합니다: 어휘 점수가 경로에 끼면 언어별로 검색 품질이 달라지기 때문입니다.

LongMemEval은 영어 전용이라 다국어 검색 품질은 측정하지 않습니다. 다국어는 위 데모처럼 라이브 API에서 직접 확인할 수 있습니다.
구조

당신의 기억 위엔 모델이 돌지 않습니다.

저장은 말한 그대로 두고, 엔진은 임베딩으로 검색합니다 - 저렴하고 빠르고 결정론적입니다. 당신의 저장된 기억 위에선 어떤 모델도 돌지 않습니다. Tablet은 모델을 전혀 쓰지 않고, Scroll·Codex는 더 나은 결과를 위해 엔진 둘레에 모델을 더하지만, 그 모델은 당신의 질문만 볼 뿐 저장한 것은 보지 않습니다.

  • 결정론적 엔진. 엔진은 같은 쿼리에 같은 기억을 반환합니다 - 그래서 벤치마크 편차가 리더 모델에서만 발생합니다.
  • 대규모에서도 저렴. 저장·검색에 생성 비용이 없어, 기억이 커져도 비용이 모델 사용량이 아니라 저장량을 따라갑니다.

당신의 말, 그대로

쓰기 시점에 언어 모델로 텍스트에서 "사실"을 추출해 다시 쓰는 설계도 흔합니다. 그 설계는 세 가지를 맞바꿉니다: 매 쓰기마다의 생성 비용, 추가 지연, 그리고 원문 대신 모델의 의역이 저장된다는 점. WOS는 반대쪽을 선택했습니다 - 말한 그대로 저장하고, 해석은 읽기 시점에 당신의 LLM이 원문을 들고 하게 합니다.

WOS가 아닌 것: 직접 운영해야 하는 벡터 DB도, 조립해야 하는 RAG 프레임워크도 아닙니다. 당신의 저장된 데이터 위엔 어떤 모델도 돌리지 않습니다 - 그 경로는 순수 임베딩입니다. Scroll과 Codex는 더 나은 결과를 위해 언어 모델을 쓰지만, 그 모델은 당신의 질문만 볼 뿐 저장된 기억은 보지 않으며 - 당신의 데이터로 학습하거나 수집하지 않습니다.
근거

측정되고 재현 가능한 90.7%.

LongMemEval-S에서 90.7%, 5회 독립 실행 평균(σ 0.5%, 체리피킹 없음), 벤치마크 표준 채점자인 GPT-4o로 채점.

같은 벤치마크라도 채점 프로토콜에 따라 수치가 크게 달라집니다 - 채점자, 프롬프트, 검색 레이어에 무엇을 허용하는지에 따라서요. 우리는 벤치마크가 공표한 표준 제3자 GPT-4o 채점자를 그대로 쓰고, 시험에 맞춰 아무것도 바꾸지 않으며, 채점 코드와 리더 프롬프트를 공개해 누구나 90.7%를 그대로 재현할 수 있게 합니다.

측정 프로토콜 한눈에

항목우리 방식
데이터셋LongMemEval-S (정제판), 문항당 ~240K 토큰 히스토리
채점자벤치마크 표준 GPT-4o 채점자 - 우리가 아닌 제3자
실행독립 5회, 전 회차 점수 공개, 평균 보고 (σ 0.5%)
리더리더 모델·프롬프트 고정, 원문 그대로 공개

정직하게 유지하는 것: 제3자 채점자, 변경 없이 공개한 리더 프롬프트, 순수 의미 기반 검색, 그리고 최고 회차가 아니라 전 회차 보고. 검색 엔진은 결정론적이라 다시 돌려도 같은 기억이 나옵니다.

더 어려운 벤치로 올라갑니다

우리는 아직 정복하지 못한 가장 어려운 표준 벤치마크 위에서 겨룹니다 - 적힌 점수는 모든 WOS 모델이 세운 최고 기록이고, 더 나은 모델이 나올 때마다 새로 쓰입니다. 94%를 넘기는 순간, 더 어려운 벤치마크로 졸업합니다.

LongMemEval-S진행 중
Tablet 185.2%
Scroll 190.7%
GPT-4o 채점 · 모든 WOS 모델 중 최고졸업까지 94%
전체 리포트 보기
가격

모델당 토큰 단가 둘,
요청당 $0.0001.

100만 토큰 단가에 요청당 $0.0001을 더해, 쓴 만큼만. 구독도, 저장료도, 기억 개수 제한도 없습니다. 에이전트가 쓰고 읽을 때만 내고 - 기억하고 있는 것에는 내지 않습니다.

모델입력 / 1M출력 / 1M
Tablet 1$2$3사용 가능
Scroll 1$4$8사용 가능
Codex 1--미정
  • 요청당 $0.0001. 모든 API 호출에 붙는 정액 요금으로, 토큰 사용량에 더해집니다.
  • 저장은 무료입니다. 적재할 때 한 번 내면 보관은 공짜입니다. 개수 제한도, 보관 기간 제한도 없습니다.
  • 보관만 합니다. 학습하지 않고, 사용하지 않고, 보지 않습니다. 에이전트의 기억은 당신의 것 - 저희는 회수할 수 있게 정리만 합니다.
  • Tablet이 이렇게 싼 이유: 엔진이 모델을 돌리지 않아 원가가 임베딩과 디스크지 GPU가 아니기 때문입니다. Scroll·Codex는 모델을 더하며, 그 비용이 더 높은 가격에 담겨 있습니다.
보관량에 월 단위로 과금하거나 플랜별로 기억 개수를 제한하는 과금 모델도 있습니다. WOS는 보관량·보관 기간과 무관하게 저장에 과금하지 않습니다.

사용량 티어별 한도 보기 →

개발자

세 번의 호출: 저장, 회수, 답변.

하나의 API. recall() 호출이 단기·장기 기억과 주변 컨텍스트를 한 번의 왕복으로 돌려줘, 프롬프트에 바로 넣을 수 있습니다.

1

저장

add()로 사용자의 사실과 대화를 저장합니다. 적재 시 임베딩 - LLM 없음.

2

회수

recall()이 단기 + 장기 + 컨텍스트를 한 번에 반환합니다 - 고정 크기의 컨텍스트.

3

답변

그 제한된 컨텍스트를 당신의 LLM에 전달하세요 - 어떤 제공사든, 당신의 키로.

from wontopos import Client
mem = Client(api_key="wos-...")
mem.add("she prefers tea over coffee", user_id="alice")
# one call: short + long + context
ctx = mem.recall("what does alice drink?", user_id="alice")
빠른 시작

5분 안에 첫 recall.

키 하나, 설치 한 줄, 호출 세 번이면 에이전트에 기억이 생깁니다. 이 페이지의 모든 코드는 실제로 실행해 검증했고, 응답도 실물 그대로입니다.

1

API 키 발급

콘솔에서 키를 만듭니다. wos-live-로 시작하는 155자 키가 한 번만 표시됩니다. 환경변수로 보관하고, 코드에 직접 적지 마세요.

2

설치

pip install wontopos        # Python
npm install wontopos        # TypeScript / JavaScript
cargo add wontopos          # Rust
# curl - nothing to install, just set WOS_API_KEY
3

저장소 만들고, 저장 & 회수

저장소는 저장·회수의 단위인 user_id입니다. 저장소는 명시적이라 먼저 만들고(아래 호출), 그 안에 저장·회수합니다. 저장 - 적재 시 임베딩, LLM 호출 없음. 회수 - 단기 + 장기 + 문맥을 한 번의 왕복으로.

from wontopos import Client

mem = Client(api_key="wos-live-...", user_id="alice")  # set the store once
mem.create_store()              # create it (stores are explicit)
mem.add("she prefers tea over coffee")  # no user_id needed

# one call → short-term + long-term + context
ctx = mem.recall("what does alice drink?")
import { Client } from "wontopos";

const mem = new Client({ apiKey: "wos-live-...", userId: "alice" });  // set the store once
await mem.createStore();            // create it (stores are explicit)
await mem.add("she prefers tea over coffee");  // no userId needed

// one call → short-term + long-term + context
const ctx = await mem.recall("what does alice drink?");
use wontopos::Client;

let mem = Client::new("wos-live-...").with_user("alice");  // set the store once
mem.create_store(None).await?;            // create it (stores are explicit)
mem.add("she prefers tea over coffee", None, json!({})).await?;

// one call → short-term + long-term + context
let ctx = mem.recall("what does alice drink?", None).await?;
# create the store once - stores are explicit
curl -X POST https://api.wontopos.com/api/v1/memory/collection \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice"}'

# store - embedded on the way in, no LLM call
curl -X POST https://api.wontopos.com/api/v1/memory/store \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","content":"she prefers tea over coffee"}'

# one call → short-term + long-term + context
curl -X POST https://api.wontopos.com/api/v1/memory/recall \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","query":"what does alice drink?"}'
실제 응답 - create_store()
{"user_id": "alice", "status": "created"}
실제 응답 - add()
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}
저장소는 한 번만 지정. 클라이언트에 user_id를 주면 모든 호출이 그걸 써서 매번 안 적어도 됩니다; 호출마다 user_id를 넘기면 그 호출만 덮어씁니다. 저장소는 명시적: 없는 저장소에 저장·회수하면 404 - 먼저 만들어야 합니다. 모든 계정엔 default 저장소가 있어 user_id를 아예 안 줘도 바로 됩니다. 목록·관리는 Stores 참고.

recall()은 네 블록을 돌려줍니다 - short_term(최근 대화), long_term(관련 기억), context(가장 관련된 기억의 주변), 그리고 LLM에게 쓰는 법을 알려주는 instruction. 이 덩어리를 그대로 프롬프트에 넣으면 됩니다.

어떤 언어로든 동작합니다. 영어로 저장하고 한국어·일본어·중국어로 물어도 같은 기억이 나옵니다. 키워드 매칭이 아니라 임베딩 검색이라서요.

언어별 메서드 전부 보기 →

저장소

저장소 - 만들고, 보고, 지우기.

저장소는 저장·회수의 단위인 user_id - 최종 사용자·에이전트·주제마다 격리된 기억 공간 하나입니다. 저장소는 명시적이라 저장·회수 전에 먼저 만들어야 하고, 아니면 404가 돌아옵니다. 모든 계정엔 default 저장소가 기본으로 있어 만들지 않고도 바로 시작할 수 있습니다.

격리 구조. 계정이 워크스페이스를 갖고, 워크스페이스마다 기억·API 키·사용량이 격리됩니다(결제는 계정 공유). 저장소는 워크스페이스 안에 있어, 같은 워크스페이스의 키는 저장소를 공유하고 다른 워크스페이스끼리는 서로의 기억을 못 봅니다. 계정 → 워크스페이스 → 저장소(user_id) → 기억.
mem.create_store("alice")        # create (idempotent)
mem.list_stores()              # [{"user_id","created_at"}, ...]
mem.delete_store("alice")        # delete the store + all its memories
await mem.createStore("alice");
await mem.listStores();          // [{ user_id, created_at }, ...]
await mem.deleteStore("alice");     // store + all its memories
mem.create_store("alice").await?;
let stores = mem.list_stores().await?;
mem.delete_store("alice").await?;
# create
curl -X POST https://api.wontopos.com/api/v1/memory/collection \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" -d '{"user_id":"alice"}'
# list
curl https://api.wontopos.com/api/v1/memory/collections -H "X-API-Key: $WOS_API_KEY"
# delete (store + all its memories)
curl -X DELETE https://api.wontopos.com/api/v1/memory/collection \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" -d '{"user_id":"alice"}'
실제 응답 - create
{ "user_id": "alice", "status": "created" }   // "exists" if it already did
실제 응답 - list
{ "collections": [
  { "user_id": "default", "created_at": "2026-06-26T02:23:14Z" },
  { "user_id": "alice",   "created_at": "2026-06-26T02:24:01Z" }
], "count": 2 }
없는 저장소 회수 시
{ "error": { "type": "not_found_error",
  "message": "Store 'ghost' does not exist. Create it first with
              POST /api/v1/memory/collection {\"user_id\":\"ghost\"}, then store or recall." } }
사람별로 기억을 나누려면 최종 사용자마다 저장소 하나("alice", "user_42"), 개인 비서라면 default 하나면 됩니다. 코드 없이 콘솔에서도 저장소를 만들고 둘러볼 수 있습니다(Memory ids → Issue). 저장소 삭제는 영구적 - 그 안의 모든 기억이 사라집니다.
Python SDK

Python - 모든 메서드, 세 그룹.

쓰고, 읽고, 지우고. 아래 모든 예제는 2026-06-10 라이브 API에서 실제로 실행했고, 응답은 실물 그대로입니다.

pip install wontopos
from wontopos import Client

mem = Client(api_key="wos-live-...")  # or read from an env var

모델 선택

API 키는 어느 기억(당신 계정)을, 모델은 어느 엔진이 그 기억을 읽을지 정합니다. 모든 모델이 기억을 공유하므로, 한 모델로 저장하고 다른 모델로 회수할 수 있습니다. 클라이언트에 기본값을 두고, model=로 호출마다 바꾸세요.

mem = Client(api_key="wos-live-...", model="tablet-1")  # default engine
mem.recall("...", user_id="alice")                  # tablet-1
mem.recall("...", user_id="alice", model="tablet-1")  # or pick a model per call

list_models ✓ live-tested

카탈로그 - model에 넣을 수 있는 id와 각 모델의 가용 여부. memory: "shared"는 같은 저장소를, "isolated"는 자기 저장소를 씁니다. API 키가 필요 없습니다.

mem.list_models()
실제 응답
[{"id": "tablet-1", "name": "Tablet 1", "available": true, "memory": "shared"}]

위 카탈로그는 항상 지금 쓸 수 있는 모델만 보여줘요 - 다른 id를 넣으면 명확한 에러가 돌아와요. 새 모델은 출시되면 자동으로 거기 나타나요.

쓰기

add ✓ live-tested

기억 하나를 저장합니다. 적재 시 임베딩 - LLM 호출이 없어 임베딩 비용만 듭니다.

mem.add("she prefers tea over coffee", user_id="alice")
실제 응답
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}

add_turn ✓ live-tested

대화 한 턴(사용자 + 어시스턴트)을 단기·장기 기억에 한 번에 저장합니다.

mem.add_turn("alice", "hi", "hello!")
실제 응답
{"status": "ok"}

add_bulk ✓ live-tested

긴 텍스트를 한 번에 적재합니다. 서버에서 청크 분할 + 임베딩 - 기존 히스토리 이관에 적합합니다.

mem.add_bulk("Alice moved to Brooklyn in March. She works at a design studio downtown.", user_id="alice")
실제 응답
{"elapsed_secs": 0.154154944, "status": "ok", "stored": 1, "total_chunks": 1}

update ✓ live-tested

사실이 바뀌었을 때. 옛 기억은 superseded 로 마킹되어 보존되고, 새 기억이 회수에서 그 자리를 차지합니다.

mem.update("alice", old_memory_id="576700aa-...", new_content="she switched to coffee this year")
실제 응답
{"new_memory_id": "07e94433-b7cc-4e49-8d8f-f37fc1a392b7",
 "old_memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "superseded"}

읽기

search ✓ live-tested

의미 검색, 관련도 순. 순수 임베딩 - 키워드 매칭이 없어 어떤 언어로 물어도 기억을 찾습니다. SDK는 memories 배열을 바로 돌려주며, 아래는 HTTP 원문입니다.

r = mem.search("what does she drink?", user_id="alice", limit=1)
실제 응답 (HTTP 원문)
{"memories": [{
   "id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624",
   "content": "she prefers tea over coffee",
   "category": "general",
   "time_bucket": "2026-06",
   "importance": 0.3,
   "similarity": 0.6316057443618774,
   "is_superseded": false,
   "superseded_by": null,
   "created_at": "2026-06-10T04:20:39.688276876Z"
 }], "search_ms": 315, "total_found": 1}
필드의미
similarity질문과의 임베딩 유사도 (0–1).
is_supersededupdate()로 교체된 기억이면 true.
search_ms서버 검색 소요 시간.

recall ✓ live-tested

한 번의 왕복으로 LLM에 필요한 모든 것을 돌려줍니다 - 결과를 프롬프트에 그대로 넣으면 됩니다. 저장량과 무관하게 항상 고정 크기입니다.

ctx = mem.recall("what does she drink?", user_id="alice")
실제 응답 (구조 - 목록 축약)
{"short_term":  {"count": 2, "turns": [{"role": "user", "content": "hi", ...}]},
 "long_term":   {"count": 4, "memories": [{"content": "she prefers tea over coffee",
                                           "similarity": 0.63, ...}]},
 "context":     {"count": 4, "around_top_memory": [
                  "[match] she prefers tea over coffee",
                  "[after] Alice moved to Brooklyn in March. ..."]},
 "instruction": "Use short_term for recent context, long_term for relevant
                 past memories, context for surrounding conversation of the
                 most relevant memory."}

history ✓ live-tested

최근 대화 턴(단기 기억), 오래된 것부터.

turns = mem.history("alice")
실제 응답 (HTTP 원문)
{"count": 2, "turns": [
   {"role": "user",      "content": "hi",     "timestamp": "2026-06-10T04:20:40.989011337Z"},
   {"role": "assistant", "content": "hello!", "timestamp": "2026-06-10T04:20:40.989013416Z"}
 ], "user_id": "alice"}

stats ✓ live-tested

한 사용자의 기억 통계.

mem.stats("alice")
실제 응답
{"short_term_turns": 2, "total_memories": 4, "user_id": "alice"}

삭제

delete ✓ live-tested

기억 하나를 id로 삭제합니다.

mem.delete("alice", memory_id="576700aa-...")
실제 응답
{"memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "deleted"}

delete_all ✓ live-tested

한 사용자의 모든 기억을 삭제 - 한 번의 호출, GDPR 대응.

mem.delete_all("alice")
실제 응답
{"memories_deleted": 4, "status": "deleted", "user_id": "alice"}
TypeScript SDK

TypeScript - 모든 메서드, 세 그룹.

쓰고, 읽고, 지우고. 아래 모든 예제는 2026-06-10 라이브 API에서 실제로 실행했고, 응답은 실물 그대로입니다.

npm install wontopos
import { Client } from "wontopos";

const mem = new Client({ apiKey: "wos-live-..." });

모델 선택

API 키는 어느 기억(당신 계정)을, 모델은 어느 엔진이 그 기억을 읽을지 정합니다. 모든 모델이 기억을 공유하므로, 한 모델로 저장하고 다른 모델로 회수할 수 있습니다. 생성자에 기본값을 두고, withModel()로 호출마다 바꾸세요.

const mem = new Client({ apiKey: "wos-live-...", model: "tablet-1" });  // default
mem.recall("...", "alice");                          // tablet-1
mem.withModel("tablet-1").recall("...", "alice");  // or pick a model per call

listModels ✓ live-tested

카탈로그 - model에 넣을 수 있는 id와 각 모델의 가용 여부. memory: "shared"는 같은 저장소를, "isolated"는 자기 저장소를 씁니다. API 키가 필요 없습니다.

await mem.listModels();
실제 응답
[{"id": "tablet-1", "name": "Tablet 1", "available": true, "memory": "shared"}]

위 카탈로그는 항상 지금 쓸 수 있는 모델만 보여줘요 - 다른 id를 넣으면 명확한 에러가 돌아와요. 새 모델은 출시되면 자동으로 거기 나타나요.

쓰기

add ✓ live-tested

기억 하나를 저장합니다. 적재 시 임베딩 - LLM 호출이 없어 임베딩 비용만 듭니다.

await mem.add("she prefers tea over coffee", "alice");
실제 응답
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}

addTurn ✓ live-tested

대화 한 턴(사용자 + 어시스턴트)을 단기·장기 기억에 한 번에 저장합니다.

await mem.addTurn("alice", "hi", "hello!");
실제 응답
{"status": "ok"}

addBulk ✓ live-tested

긴 텍스트를 한 번에 적재합니다. 서버에서 청크 분할 + 임베딩 - 기존 히스토리 이관에 적합합니다.

await mem.addBulk("Alice moved to Brooklyn in March. She works at a design studio downtown.", "alice");
실제 응답
{"elapsed_secs": 0.154154944, "status": "ok", "stored": 1, "total_chunks": 1}

update ✓ live-tested

사실이 바뀌었을 때. 옛 기억은 superseded 로 마킹되어 보존되고, 새 기억이 회수에서 그 자리를 차지합니다.

await mem.update("alice", "576700aa-...", "she switched to coffee this year");
실제 응답
{"new_memory_id": "07e94433-b7cc-4e49-8d8f-f37fc1a392b7",
 "old_memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "superseded"}

읽기

search ✓ live-tested

의미 검색, 관련도 순. 순수 임베딩 - 키워드 매칭이 없어 어떤 언어로 물어도 기억을 찾습니다. SDK는 memories 배열을 바로 돌려주며, 아래는 HTTP 원문입니다.

const r = await mem.search("what does she drink?", "alice", 1);
실제 응답 (HTTP 원문)
{"memories": [{
   "id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624",
   "content": "she prefers tea over coffee",
   "category": "general",
   "time_bucket": "2026-06",
   "importance": 0.3,
   "similarity": 0.6316057443618774,
   "is_superseded": false,
   "superseded_by": null,
   "created_at": "2026-06-10T04:20:39.688276876Z"
 }], "search_ms": 315, "total_found": 1}
필드의미
similarity질문과의 임베딩 유사도 (0–1).
is_supersededupdate()로 교체된 기억이면 true.
search_ms서버 검색 소요 시간.

recall ✓ live-tested

한 번의 왕복으로 LLM에 필요한 모든 것을 돌려줍니다 - 결과를 프롬프트에 그대로 넣으면 됩니다. 저장량과 무관하게 항상 고정 크기입니다.

const ctx = await mem.recall("what does she drink?", "alice");
실제 응답 (구조 - 목록 축약)
{"short_term":  {"count": 2, "turns": [{"role": "user", "content": "hi", ...}]},
 "long_term":   {"count": 4, "memories": [{"content": "she prefers tea over coffee",
                                           "similarity": 0.63, ...}]},
 "context":     {"count": 4, "around_top_memory": [
                  "[match] she prefers tea over coffee",
                  "[after] Alice moved to Brooklyn in March. ..."]},
 "instruction": "Use short_term for recent context, long_term for relevant
                 past memories, context for surrounding conversation of the
                 most relevant memory."}

history ✓ live-tested

최근 대화 턴(단기 기억), 오래된 것부터.

const turns = await mem.history("alice");
실제 응답 (HTTP 원문)
{"count": 2, "turns": [
   {"role": "user",      "content": "hi",     "timestamp": "2026-06-10T04:20:40.989011337Z"},
   {"role": "assistant", "content": "hello!", "timestamp": "2026-06-10T04:20:40.989013416Z"}
 ], "user_id": "alice"}

stats ✓ live-tested

한 사용자의 기억 통계.

await mem.stats("alice");
실제 응답
{"short_term_turns": 2, "total_memories": 4, "user_id": "alice"}

삭제

delete ✓ live-tested

기억 하나를 id로 삭제합니다.

await mem.delete("alice", "576700aa-...");
실제 응답
{"memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "deleted"}

deleteAll ✓ live-tested

한 사용자의 모든 기억을 삭제 - 한 번의 호출, GDPR 대응.

await mem.deleteAll("alice");
실제 응답
{"memories_deleted": 4, "status": "deleted", "user_id": "alice"}
Rust SDK

Rust - 모든 메서드, 세 그룹.

쓰고, 읽고, 지우고. 아래 모든 예제는 2026-06-10 라이브 API에서 실제로 실행했고, 응답은 실물 그대로입니다.

cargo add wontopos
use wontopos::Client;

let mem = Client::new("wos-live-...");

모델 선택

API 키는 어느 기억(당신 계정)을, 모델은 어느 엔진이 그 기억을 읽을지 정합니다. 모든 모델이 기억을 공유하므로, 한 모델로 저장하고 다른 모델로 회수할 수 있습니다. with_model()로 기본값을 두고, 한 번 더 체이닝하면 그 호출만 바뀝니다.

let mem = Client::new("wos-live-...").with_model("tablet-1");  // default
mem.recall("...", "alice").await?;                       // tablet-1
mem.with_model("tablet-1").recall("...", "alice").await?;  // or pick a model per call

list_models ✓ live-tested

카탈로그 - with_model에 넣을 수 있는 id와 각 모델의 가용 여부. memory: "shared"는 같은 저장소를, "isolated"는 자기 저장소를 씁니다. API 키가 필요 없습니다.

mem.list_models().await?;
실제 응답
[{"id": "tablet-1", "name": "Tablet 1", "available": true, "memory": "shared"}]

위 카탈로그는 항상 지금 쓸 수 있는 모델만 보여줘요 - 다른 id를 넣으면 명확한 에러가 돌아와요. 새 모델은 출시되면 자동으로 거기 나타나요.

쓰기

add ✓ live-tested

기억 하나를 저장합니다. 적재 시 임베딩 - LLM 호출이 없어 임베딩 비용만 듭니다.

mem.add("she prefers tea over coffee", "alice", json!({})).await?;
실제 응답
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}

add_turn ✓ live-tested

대화 한 턴(사용자 + 어시스턴트)을 단기·장기 기억에 한 번에 저장합니다.

mem.add_turn("alice", "hi", "hello!").await?;
실제 응답
{"status": "ok"}

add_bulk ✓ live-tested

긴 텍스트를 한 번에 적재합니다. 서버에서 청크 분할 + 임베딩 - 기존 히스토리 이관에 적합합니다.

mem.add_bulk("Alice moved to Brooklyn in March...", "alice", "general").await?;
실제 응답
{"elapsed_secs": 0.154154944, "status": "ok", "stored": 1, "total_chunks": 1}

update ✓ live-tested

사실이 바뀌었을 때. 옛 기억은 superseded 로 마킹되어 보존되고, 새 기억이 회수에서 그 자리를 차지합니다.

mem.update("alice", "576700aa-...", "she switched to coffee this year").await?;
실제 응답
{"new_memory_id": "07e94433-b7cc-4e49-8d8f-f37fc1a392b7",
 "old_memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "superseded"}

읽기

search ✓ live-tested

의미 검색, 관련도 순. 순수 임베딩 - 키워드 매칭이 없어 어떤 언어로 물어도 기억을 찾습니다. SDK는 memories 배열을 바로 돌려주며, 아래는 HTTP 원문입니다.

let r = mem.search("what does she drink?", "alice", 1).await?;
실제 응답 (HTTP 원문)
{"memories": [{
   "id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624",
   "content": "she prefers tea over coffee",
   "category": "general",
   "time_bucket": "2026-06",
   "importance": 0.3,
   "similarity": 0.6316057443618774,
   "is_superseded": false,
   "superseded_by": null,
   "created_at": "2026-06-10T04:20:39.688276876Z"
 }], "search_ms": 315, "total_found": 1}
필드의미
similarity질문과의 임베딩 유사도 (0–1).
is_supersededupdate()로 교체된 기억이면 true.
search_ms서버 검색 소요 시간.

recall ✓ live-tested

한 번의 왕복으로 LLM에 필요한 모든 것을 돌려줍니다 - 결과를 프롬프트에 그대로 넣으면 됩니다. 저장량과 무관하게 항상 고정 크기입니다.

let ctx = mem.recall("what does she drink?", "alice").await?;
실제 응답 (구조 - 목록 축약)
{"short_term":  {"count": 2, "turns": [{"role": "user", "content": "hi", ...}]},
 "long_term":   {"count": 4, "memories": [{"content": "she prefers tea over coffee",
                                           "similarity": 0.63, ...}]},
 "context":     {"count": 4, "around_top_memory": [
                  "[match] she prefers tea over coffee",
                  "[after] Alice moved to Brooklyn in March. ..."]},
 "instruction": "Use short_term for recent context, long_term for relevant
                 past memories, context for surrounding conversation of the
                 most relevant memory."}

history ✓ live-tested

최근 대화 턴(단기 기억), 오래된 것부터.

let turns = mem.history("alice").await?;
실제 응답 (HTTP 원문)
{"count": 2, "turns": [
   {"role": "user",      "content": "hi",     "timestamp": "2026-06-10T04:20:40.989011337Z"},
   {"role": "assistant", "content": "hello!", "timestamp": "2026-06-10T04:20:40.989013416Z"}
 ], "user_id": "alice"}

stats ✓ live-tested

한 사용자의 기억 통계.

mem.stats("alice").await?;
실제 응답
{"short_term_turns": 2, "total_memories": 4, "user_id": "alice"}

삭제

delete ✓ live-tested

기억 하나를 id로 삭제합니다.

mem.delete("alice", "576700aa-...").await?;
실제 응답
{"memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "deleted"}

delete_all ✓ live-tested

한 사용자의 모든 기억을 삭제 - 한 번의 호출, GDPR 대응.

mem.delete_all("alice").await?;
실제 응답
{"memories_deleted": 4, "status": "deleted", "user_id": "alice"}
curl

curl - 설치 없이, 같은 메서드.

설치할 SDK가 없습니다 - 어떤 HTTP 클라이언트든 됩니다. 키만 한 번 설정하면 SDK가 감싸는 그 엔드포인트를 그대로 호출해요. Base URL https://api.wontopos.com, 인증은 X-API-Key, 입출력은 JSON.

# set your key once (never hard-code it)
export WOS_API_KEY="wos-live-..."

쓰기

store ✓ live-tested

기억 하나 저장. 적재 시 임베딩 - LLM 호출 없음.

curl -X POST https://api.wontopos.com/api/v1/memory/store \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","content":"she prefers tea over coffee"}'
실제 응답
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}

store-turn ✓ live-tested

대화 한 턴(사용자+어시스턴트)을 단기·장기에 한 번에 저장.

curl -X POST https://api.wontopos.com/api/v1/memory/store-turn \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","user_msg":"hi","assistant_msg":"hello!"}'
실제 응답
{"status": "ok"}

supersede ✓ live-tested

사실이 바뀌면 - 옛 기억은 superseded로 마킹, 새 기억이 회수에서 그 자리를 차지.

curl -X POST https://api.wontopos.com/api/v1/memory/supersede \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","old_memory_id":"576700aa-...","new_content":"she switched to coffee this year"}'
실제 응답
{"new_memory_id": "07e94433-...", "old_memory_id": "576700aa-...", "status": "superseded"}

읽기

search ✓ live-tested

의미 검색, 관련도 순. 순수 임베딩 - 어떤 언어로 물어도 기억을 찾음.

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":"what does she drink?","max_results":1}'
실제 응답
{"memories": [{"id": "576700aa-...", "content": "she prefers tea over coffee",
   "similarity": 0.63, "is_superseded": false}], "search_ms": 315, "total_found": 1}

recall ✓ live-tested

한 번의 왕복으로 단기 + 장기 + 문맥 + instruction. 프롬프트에 그대로 넣으면 됨.

curl -X POST https://api.wontopos.com/api/v1/memory/recall \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","query":"what does she drink?"}'
실제 응답 (구조)
{"short_term": {"count": 2, "turns": [...]},
 "long_term":  {"count": 4, "memories": [{"content": "she prefers tea over coffee", "similarity": 0.63}]},
 "context":    {"count": 4, "around_top_memory": ["[match] she prefers tea over coffee"]},
 "instruction": "Use short_term for recent context, long_term for relevant past memories..."}

삭제

forget ✓ live-tested

id로 기억 하나 삭제, 생략하면 사용자 전체 삭제(GDPR).

curl -X POST https://api.wontopos.com/api/v1/memory/forget \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice"}'  # omit memory_id = delete all
실제 응답
{"memories_deleted": 1, "status": "deleted", "user_id": "alice"}

엔드포인트 + 바디 필드 전부 보기 →

엔그램

Engrams

모델이 호출하는 회수 도구 - 같은 기억 위에서 서로 다른 검색 전략을 씁니다. 하나만 쓰거나 여러 개를 동시에 호출하세요.

곧 나옴. 아래 일반 엔그램은 LLM 없는 회수 파이프라인이라 Tablet 1부터 모든 티어에서 돕니다. 지금 API는 저장·회수만 서빙해서 이 호출들은 아직 라이브가 아닙니다. 회고록·아카이브는 결이 다른 모델 모드라 아래 별도 섹션에서 다룹니다.

엔그램은 계속 추가됩니다 - 목록은 늘어납니다.

회고록 & 아카이브 곧 나옴

이건 호출하는 도구가 아니라 모델 모드입니다. 모델에서 고르면 그냥 검색을 포함한 모든 회수에 시간이 그 방식으로 적혀 돌아옵니다. 곧 나옴.

엔그램 목록 엔그램

Time_awareness 곧 나옴

호출 옵션이 아니라 모델 모드. 모델(Time_awareness-memoir 또는 Time_awareness-archive)을 고르면 - 그냥 검색이든 recall이든 엔그램이든 - 추가 파라미터 없이 모든 회수가 그 방식으로 돌아옵니다. 회고록은 사람이 기억하듯, 아카이브는 정확한 기록 그대로 - 차이는 시간을 적는 방식에서 가장 잘 드러납니다. Time_awareness- 접두는 앞으로 다른 능력이 들어올 자리를 남깁니다.

회고록

Time_awareness-memoir
사람이 기억하듯 · 서사로

무슨 일이 어떻게 다음으로 이어졌는지, 사람이 떠올리는 흐릿한 시간 감각과 함께 들려줍니다 - 목록이 아니라 경험으로.

아카이브

Time_awareness-archive
기록 그대로 · 정밀한 시각

맞는 것을 정밀한 경과 시간과 절대 앵커로, 기록 그대로 돌려줍니다 - 모델이 바로 읽도록 구조화되어.

이미 저장한 기억을 렌더할 뿐, 기억을 만들지는 않습니다. 기억 하나는 user_id 아래 store / add 호출 한 번 (그 user_id가 곧 그 사람의 저장소). 먼저 저장해야, 그 다음 어떤 회수든 - 아래 그냥 검색 포함 - 시간 태그가 붙어 돌아옵니다. 저장은 Quickstart 참고.
# plain search - no engram - on a memoir model
r = mem.search("what does Alice drink?", user_id="alice", model="Time_awareness-memoir", tz=9)
# every hit gets a .time field → "a couple weeks ago"  (archive model → "2 weeks ago (Jun 09)")
// plain search - no engram - on a memoir model
const r = await mem.withModel("Time_awareness-memoir").search("what does Alice drink?", "alice", 10, { tz: 9 });
// model picks the mode; tz over HTTP via the X-WOS-Timezone header
let r = mem.with_model("Time_awareness-memoir").search("what does Alice drink?", "alice", 10).await?;
curl -X POST https://api.wontopos.com/api/v1/memory/search \
  -H "X-API-Key: wos-live-..." -H "X-WOS-Model: Time_awareness-memoir" -H "X-WOS-Timezone: 9" \
  -d '{"user_id":"alice","query":"what does Alice drink?"}'
# each memory comes back with a "time" field; use Time_awareness-archive for exact time

tz는 호출자의 UTC 오프셋(시간) - 라 "this morning" 같은 표현과 새벽 4시 경계가 그 사람 현지 시간으로 찍힙니다. 안 주면 UTC, HTTP에선 X-WOS-Timezone 헤더. 지역별 대략값: 미국 동부 -5, 중부 -6, 서부 -8 · 영국 / 리스본 0 · 중부 유럽 +1 · 동유럽 +2 · 인도 +5.5 · 중국 / 싱가포르 +8 · 한국 / 일본 +9 · 시드니 +10. (표준시 기준 - 서머타임이면 일부 지역은 +1, 사용자가 실제로 쓰는 값을 그대로 넣으세요.)

같은 검색, 두 모델 - 기억은 똑같고 time만 달라집니다:

결과 · Time_awareness-memoir
{ "count": 3, "memories": [
  { "content": "Alice prefers tea over coffee", "time": "a couple weeks ago" },
  { "content": "met Alice at the cafe downtown",  "time": "yesterday afternoon" },
  { "content": "Alice moved to Brooklyn",          "time": "about half a year ago" }
] }
결과 · Time_awareness-archive
{ "count": 3, "memories": [
  { "content": "Alice prefers tea over coffee", "time": "2 weeks ago (Jun 09)" },
  { "content": "met Alice at the cafe downtown",  "time": "yesterday at 14:00" },
  { "content": "Alice moved to Brooklyn",          "time": "6 months ago (Dec 2025)" }
] }
경과회고록아카이브
3분a few minutes ago3 minutes ago
14분about 15 minutes ago14 minutes ago
30분half an hour ago30 minutes ago
50분about an hour ago50 minutes ago
2시간a couple hours ago2 hours ago, at 13:10
8시간this morning8 hours ago, at 07:10
어제 낮yesterday afternoonyesterday at 14:00
어제 밤last night17 hours ago, at 22:00
2일a couple days ago2 days ago (Tue 15:10)
6일several days ago6 days ago (Fri 15:10)
9일about a week agolast week (Jun 16)
16일a couple weeks ago2 weeks ago (Jun 09)
35일about a month agolast month (May 21)
60일a couple months ago2 months ago (Apr 2026)
180일about half a year ago6 months ago (Dec 2025)
380일about a year agolast year (Jun 2025)
800일a couple years ago2 years ago (Apr 2024)
1500일about 4 years ago4 years ago (May 2022)

위 값은 전부 렌더러의 실제 출력입니다. "어제" 두 줄을 보세요: 회고록은 낮과 밤을 가르지만 - 하루는 잠 한 번 - 아카이브는 시계 시각 하나로 적고 낮·밤을 나누지 않습니다.

모드별 시간 읽는 법

회고록 - 사람이 실제로 말하는 방식. 최근은 비교적 또렷하다가(약 15분 전, 30분 전) 멀어질수록 표현이 넓어집니다 - 2주쯤 전, 반년쯤 전, 몇 년 전 - 기억 자체가 멀수록 풀어지듯. 하루 안에서는 시계 대신 landmark를 씁니다: 오늘 아침, 어젯밤, 어제 오후. 그리고 하루는 달력 한 칸이 아니라 잠 한 번: 경계가 현지 새벽 4시쯤이라, 늦은 밤도 여전히 '오늘 밤'으로 읽히지 벌써 내일이 되지 않습니다.

아카이브 - 정밀, 항상 앵커와 함께. 모든 줄에 정확한 경과 시간 + 모델이 계산할 수 있는 절대 기준이 붙고, 가까울수록 앵커가 촘촘해집니다: 오늘은 시계(8시간 전, 07:10), 이번 주는 요일+시계(2일 전 (화 15:10)), 이번 달은 날짜(지난주 (6월 16일)), 그 너머는 월·연도(6개월 전 (2025년 12월)). 모호함 없이, 틀림 없이.

회고록과 아카이브는 호출마다 붙이는 옵션이 아니라 모든 회수(그냥 검색·recall·엔그램)에 적용되는 모델 모드입니다. 모델 티어(Tablet → Scroll → Codex)가 엔진이 하는 일의 깊이를, 모드(회고록/아카이브)가 시간을 적는 방식을 정합니다. 곧 나옴.
엔그램 목록 엔그램

deep_recall

멀티홉 회수. 쿼리로 검색한 뒤 최상위 매치의 내용으로 한 번 더 검색해 단일 검색이 놓칠 연결 맥락을 끌어옵니다. 기억이 서로를 참조할 때(사람 → 프로젝트 → 세부) 가장 좋습니다. 최대 ~12개.

out = mem.engram("deep_recall", "what should I know about Alice?", user_id="alice")
const out = await mem.engram("deep_recall", "what should I know about Alice?", "alice");
let out = mem.engram("deep_recall", "what should I know about Alice?", "alice").await?;
curl -X POST https://api.wontopos.com/api/v1/engram/run \
  -H "X-API-Key: wos-live-..." -H "Content-Type: application/json" \
  -d '{"name":"deep_recall","user_id":"alice","query":"what should I know about Alice?"}'
응답
{ "engram": "deep_recall", "hops": 2, "count": 12,
  "memories": [ ... ],
  "usage": { "input_tokens": 5, "output_tokens": 61 } }
토큰 과금 - 호출마다 usage(입력+출력)가 나오며 API 나머지와 같은 토크나이저로 셉니다. 숨은 수수료 없음. 여러 개를 한 번에? 동시에 호출하면 됩니다 - 각 엔그램은 독립 요청.
엔그램 목록 엔그램

timeline

시간순 회수. 관련도가 아니라 사건 발생 시점 기준 최신순으로 정렬해 반환합니다. "언제 X했지", 이력, 순서 질문에. 최대 15개.

events = mem.engram("timeline", "project milestones", user_id="alice")
const events = await mem.engram("timeline", "project milestones", "alice");
let events = mem.engram("timeline", "project milestones", "alice").await?;
curl -X POST https://api.wontopos.com/api/v1/engram/run \
  -H "X-API-Key: wos-live-..." -H "Content-Type: application/json" \
  -d '{"name":"timeline","user_id":"alice","query":"project milestones"}'
응답
{ "engram": "timeline", "hops": 1, "count": 15,
  "memories": [ ... ],
  "usage": { "input_tokens": 4, "output_tokens": 88 } }
토큰 과금 - 호출마다 usage(입력+출력)가 나오며 API 나머지와 같은 토크나이저로 셉니다. 숨은 수수료 없음. 여러 개를 한 번에? 동시에 호출하면 됩니다 - 각 엔그램은 독립 요청.
엔그램 목록 엔그램

gather

넓은 수집. 검색 후 상위 매치 주변을 확장해 deep_recall보다 더 넓게 훑습니다. 한 사람·프로젝트·주제 관련된 걸 한 번에 다 모을 때. 최대 ~18개.

related = mem.engram("gather", "everything about Project Atlas", user_id="alice")
const related = await mem.engram("gather", "everything about Project Atlas", "alice");
let related = mem.engram("gather", "everything about Project Atlas", "alice").await?;
curl -X POST https://api.wontopos.com/api/v1/engram/run \
  -H "X-API-Key: wos-live-..." -H "Content-Type: application/json" \
  -d '{"name":"gather","user_id":"alice","query":"everything about Project Atlas"}'
응답
{ "engram": "gather", "hops": 4, "count": 18,
  "memories": [ ... ],
  "usage": { "input_tokens": 6, "output_tokens": 142 } }
토큰 과금 - 호출마다 usage(입력+출력)가 나오며 API 나머지와 같은 토크나이저로 셉니다. 숨은 수수료 없음. 여러 개를 한 번에? 동시에 호출하면 됩니다 - 각 엔그램은 독립 요청.
HTTP API

모든 엔드포인트, 하나의 Base URL.

SDK 없이도 됩니다 - 어떤 HTTP 클라이언트든 가능. Base URL https://api.wontopos.com, 인증은 X-API-Key 헤더, 입출력은 JSON. 기억 작업은 POST, 저장소 관리는 /collection에 POST / GET / DELETE. 저장소가 먼저 있어야 하고(Stores 참고), 없으면 404.

엔드포인트용도바디 필드
POST /api/v1/memory/collection저장소 생성user_id
GET /api/v1/memory/collections저장소 목록(없음)
DELETE /api/v1/memory/collection저장소 + 기억 삭제user_id
/api/v1/memory/store기억 하나 저장user_id · content · metadata?
/api/v1/memory/store-turn대화 턴 저장user_id · user_msg · assistant_msg
/api/v1/memory/bulk-store긴 텍스트 적재user_id · content · category?
/api/v1/memory/search의미 검색user_id · query · max_results?
/api/v1/memory/recall단기 + 장기 + 문맥user_id · query
/api/v1/memory/history최근 대화user_id
/api/v1/memory/stats기억 통계user_id
/api/v1/memory/supersede바뀐 사실 교체user_id · old_memory_id · new_content
/api/v1/memory/forget하나(또는 전체) 삭제user_id · memory_id? (생략 = 전체 삭제)
# create the store once (stores are explicit)
curl -X POST https://api.wontopos.com/api/v1/memory/collection \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice"}'

# store a memory
curl -X POST https://api.wontopos.com/api/v1/memory/store \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","content":"she prefers tea over coffee"}'

# recall - one call, ready for your prompt
curl -X POST https://api.wontopos.com/api/v1/memory/recall \
  -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \
  -d '{"user_id":"alice","query":"what does alice drink?"}'
실제 응답 - store
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}
사용량 티어

기능은 모두에게 동일.
티어는 한도만 올립니다.

모든 티어가 같은 엔진을 씁니다 - 같은 recall 품질, 같은 다국어, 모든 메서드. Tier 5까지는 누적 충전액이 쌓이면 신청이나 영업 통화 없이 자동으로 올라갑니다. Enterprise(Tier 6)만 예외입니다.

지출 한도

티어마다 한 달에 쓸 수 있는 금액에 상한이 있습니다. 누적 충전액이 다음 기준에 도달하면 즉시 승급됩니다.

티어누적 충전월 지출 한도
Tier 1$5$100
Tier 2$40$500
Tier 3$200$1,000
Tier 4$400$5,000
Tier 5$1,000$25,000
Tier 6 - Enterprise영업 협의무제한

속도 한도

속도 한도는 계정 단위입니다 - 한 계정의 모든 API 키가 하나의 한도를 공유하며, 티어에 따라 올라갑니다. 넘으면 retry-after 헤더와 함께 429를 돌려주므로, 잠시 물러났다(1초 → 2초 → 4초) 재시도하면 됩니다. 모든 엔드포인트가 멱등에 친화적이라 재시도해도 안전합니다.

티어분당 요청
Tier 1150
Tier 2300
Tier 3600
Tier 41,500
Tier 53,000
Tier 6 - Enterprise영업 협의

Enterprise(Tier 6)는 커스텀 한도, SLA, 전담 지원, 그리고 선택적 self-host 라이선스를 제공합니다 - 문의하세요.

과금은 사용량 기반입니다: 토큰에 요청당 $0.0001이 더해집니다. Tablet은 입력 100만 토큰당 $2, 출력 100만 토큰당 $3. 저장은 제한 없이 무료입니다. 이렇게 가격을 정한 이유.
에러와 한도

문제가 생겼을 때.

에러는 안정적인 type, 사람이 읽는 메시지, 그리고 문의 시 함께 보낼 수 있는 request_id가 담긴 JSON 봉투로 옵니다.

실제 응답 - 잘못된 키 (HTTP 401)
{"type": "error", "error": {
   "type": "authentication_error",
   "message": "Invalid or revoked API key.",
   "request_id": "063f8b83-eee2-4383-a5cf-11e4bcd29d7c"
 }}
HTTP의미대처
401잘못됐거나 폐기된 API 키키 확인, 콘솔에서 재발급.
422잘못된 바디 (필드 누락/타입 오류)메시지에 정확한 필드가 나옵니다 - 고치고 재시도.
429요청 한도 초과지수 백오프(1초 → 2초 → 4초) 후 재시도. 모든 엔드포인트가 재시도에 안전합니다.
5xx서버 측 문제백오프 후 재시도. 문의 시 request_id를 함께 보내주세요.
# SDK error handling (Python)
from wontopos import Client, WosError

try:
    mem.search("...", user_id="alice")
except WosError as e:
    if e.status == 401: ...  # bad key
    elif e.status == 429: ...  # back off and retry
키 안전. 키는 생성 시 한 번만 표시되고 서버에는 해시로만 저장됩니다. 환경변수로 보관하고, 유출 시 콘솔에서 폐기하세요 - 폐기는 즉시 적용됩니다.

요청 한도는 계정 단위로 모든 키가 공유하며, 티어에 따라 올라갑니다 - 사용량 티어 참고. 계정 사용량은 콘솔에 표시됩니다.

셀프 호스팅

당신의 서버, 당신의 데이터.

엔진을 자체 인프라에서 운영할 수 있습니다 - 같은 API, 같은 SDK. 클라이언트가 바라보는 주소만 바꾸면 나머지는 그대로입니다.

mem = Client(api_key="...", base_url="https://wos.your-host.com")
const mem = new Client({ apiKey: "...", baseUrl: "https://wos.your-host.com" });
let mem = Client::with_base_url("...", "https://wos.your-host.com");
  • 데이터 주권. 기억이 당신의 네트워크 밖으로 나가지 않습니다.
  • 동일한 인터페이스. 같은 메서드와 엔드포인트가 동일하게 동작합니다.
  • 라이선스. 셀프 호스팅 패키지는 배포 단위로 협의합니다 - 문의하기.
확장

컨텍스트 윈도를 넘어서.

WOS는 어떤 LLM 컨텍스트 윈도보다도 큰 140만 토큰 히스토리에서도 회수하고, 여전히 ~1,470 토큰의 짧은 조각만 돌려줍니다.

에이전트의 기억은 프롬프트에 들어가는 양에 갇히지 않습니다. 전부 보관하고 중요한 것만 회수합니다. 히스토리가 아무리 커져도 마찬가지입니다.

프라이버시

비공개, 그리고 당신의 것.

데이터는 당신의 저장소에 머뭅니다. 저희는 그것으로 학습하지도, 열람하지도, 재사용하지도 않습니다 - 회수할 수 있게 정리만 합니다.

  • BYOK. LLM 키는 요청마다 전달되며 저장되지 않습니다.
  • 격리. 기억은 계정별, 그리고 user_id별로 분리됩니다.
  • GDPR 삭제 & 셀프 호스팅. 한 번의 호출로 사용자를 삭제하고, 원하면 엔진을 자체 환경에서 운영할 수 있습니다.