Letta 에이전트를 OpenAI 호환 엔드포인트에서 실행하기.

빠른 답: 서버의 환경 변수 두 개.

OpenAI 호환 엔드포인트를 위한 Letta의 문서화된 경로는 셀프 호스팅 서버의 환경 설정입니다: 서버를 시작할 때 OPENAI_API_BASE를 엔드포인트 URL로, OPENAI_API_KEY를 그 키로 설정하면 Letta가 그 엔드포인트가 서빙하는 모델을 등록합니다. APIsRouter의 base는 https://api.apisrouter.com/v1입니다. UI에는 에이전트별 base-URL 필드가 없습니다; 엔드포인트는 서버 레벨의 결정이며, 그래서 환경이 중요한 표면입니다. 한 가지 요구사항은 타협 불가능하며 다른 무엇보다 먼저 읽을 가치가 있습니다: Letta의 문서는 OpenAI 호환 엔드포인트가 함수 호출을 지원해야 한다고 명시하는데, 에이전트 루프 자체가 툴 호출 위에 구축되어 있기 때문입니다. 순수한 채팅 완성만 하는 엔드포인트는 Letta 에이전트를 전혀 실행할 수 없습니다. APIsRouter의 카탈로그 모델은 /v1/chat/completions를 통해 표준 툴 콜링을 구사하며, 이것이 Letta가 기대하는 형태입니다.

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

Letta가 왜 채팅 앱보다 모델에 더 크게 의존하는가.

Letta(GitHub의 letta-ai, 약 2.4만 스타)는 MemGPT 연구 프로젝트에서 성장해 상태를 유지하는 에이전트를 만듭니다: 세션을 넘어 지속되는, 스스로 편집하는 메모리를 가진 에이전트입니다. 채팅 클라이언트가 여러분의 메시지를 보내고 답변을 출력하는 곳에서, Letta 에이전트는 모든 상호작용마다 내부 루프를 돌립니다. 알고 있는 것에 대해 추론하고, 메모리 툴을 호출해 자신의 코어 메모리와 아카이브 저장소를 읽고 다시 쓴 다음에야 응답을 만듭니다. 그 아키텍처는 엔드포인트 라우팅에 두 가지 결과를 낳습니다. 첫째, 루프의 모든 단계가 툴 콜링 요청이므로 함수 호출이 있으면 좋은 것이 아니라 엄격한 요구사항입니다; 툴 스키마를 다루지 못하는 모델은 여기서 우아하게 성능이 저하되는 것이 아니라 에이전트의 기억 능력 자체가 망가집니다. 둘째, 상호작용당 요청량은 대화 기록이 시사하는 것보다 높습니다. 메모리 관리가 보이는 답변 뒤에서 함께 발동하기 때문입니다. 이 모든 것을 서빙하는 모델 id는 엔드포인트에는 순수 문자열이므로, OPENAI_API_BASE 뒤의 멀티벤더 게이트웨이가 있으면 Claude id가 에이전트 루프를 실행하는 동안 같은 서버에서 빠른 id가 더 가벼운 에이전트를 서빙할 수 있으며, 각각 자신의 핸들로 지정됩니다.

업스트림이 직접 밝힌 솔직한 지원 현황.

Letta의 문서는 OpenAI 프록시 엔드포인트가 공식적으로 지원되지 않으며 오류를 만날 가능성이 있다고 명시하고, 대신 직접 프로바이더 연결을 권장합니다. 이 주제를 다루는 대부분의 페이지가 마치 존재하지 않는 것처럼 구는 그 경고는 묻혀서는 안 되고 인용될 가치가 있습니다. 실제로 이것이 의미하는 바는 들리는 것보다 좁습니다: Letta는 퍼스트파티 API를 대상으로 테스트하며, OpenAI 시맨틱스에서, 특히 툴 콜링 주변에서 벗어난 엔드포인트는 업스트림이 우선순위를 두지 않을 실패를 만듭니다. 진정으로 스펙(툴 콜을 포함해)을 구현한 엔드포인트는 문제없이 실행되며, 이것이 정확히 게이트웨이가 사느냐 죽느냐를 가르는 호환성 기준입니다. 지원 이력에는 알아둘 만한 실제 버그도 하나 있었습니다. 2026년 초까지 OPENAI_API_BASE를 통해 등록된 모델은 openai-proxy 프로바이더로 자동 프리픽스가 붙었지만 에이전트 생성은 더 짧은 허용 프리픽스 목록에 대해서만 검증했으므로, 프록시 모델은 등록되지만 에이전트 생성에는 쓸 수 없었습니다. 이 이슈는 2026년 1월 수정으로 닫혔습니다; 고정된 이전 서버를 운영 중이고 서버가 명백히 나열하는 모델을 에이전트 생성이 거부한다면 바로 이 불일치를 겪고 있는 것이며, 업그레이드가 해결책입니다. 한 가지 더 움직이는 표적: Letta의 제품 표면은 계속 이동해왔고, 현재 문서는 클래식 도커 이미지가 더 이상 활발히 유지되는 표면이 아님을 언급하면서 신규 사용자를 새로운 배포 모드로 유도하고 있습니다. 위의 환경 변수는 셀프 호스팅 서버를 위한 문서화된 메커니즘입니다; 배포하는 그 주에 업스트림이 권장하는 서버 아티팩트가 무엇인지 현재 문서를 확인하세요.

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

상태 유지 에이전트를 위한 모델 선택.

중요한 평가는 루프 충실도입니다: 테스트 에이전트를 만들고, 메모리 업데이트를 강제하는 대화를 나눈 다음, 에이전트의 코어 메모리를 읽어 실제로 바뀌었는지 확인하세요. 모델은 매력적인 답변을 쓰면서도 메모리 계약을 어길 수 있으며, 루프 테스트만이 그것을 잡아냅니다.

• 메모리 편집은 구조화된 툴 작업입니다. claude-sonnet-4-6과 gpt-5.5는 자신의 메모리를 다시 쓰는 루프를 안정적으로 처리하며, 이것이 Letta 에이전트가 필요로 하는 핵심 능력입니다.
• 오래 지속되는 에이전트는 컨텍스트를 누적합니다. 컨텍스트 윈도우 깊숙이 들어가서도 일관성을 유지하는 모델이 상태 없는 채팅보다 여기서 더 중요하며, 고위험 어시스턴트에서 claude-opus-4-7이 그 자리를 얻는 이유입니다.
• 사용자별 또는 작업별로 하나씩인 경량 에이전트 무리는 볼륨 워크로드입니다. claude-haiku-4-5-20251001은 에이전트당 비용을 평평하게 유지하면서도 꽤 괜찮은 툴 호출을 해냅니다.
• deepseek-v4-pro는 추론과 이중 언어 트래픽을 섞는 에이전트에 테스트할 가치가 있습니다; 툴 콜링 요구사항이 관문이므로 산문이 아니라 루프 자체를 테스트하세요.
• 무엇을 고르든 에이전트별로 고르세요. 서버가 카탈로그 전체를 등록하고 각 에이전트가 핸들에 바인딩되므로, 메모리 집약적인 컨시어지와 일회성 작업 에이전트가 서로 다른 id로 나란히 실행될 수 있습니다.

사용한 만큼 지불 · 공식 요금보다 저렴

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Letta 특유의 실패 패턴.

서버가 나열하는 모델을 에이전트 생성이 거부하는 것은 앞서 말한 역사적 프리픽스 버그입니다. 프록시를 통해 등록된 모델은 영향받은 버전에서 에이전트 생성이 받아들이지 않는 프로바이더 프리픽스를 달고 있었습니다. 수정은 2026년 1월에 반영됐습니다; 현재 릴리스에서는 모델 목록에 표시된 핸들이 곧 작동하는 핸들입니다. 이전 이미지에 고정되어 있다면, 다른 무엇보다 먼저 업그레이드해야 할 가장 강력한 이유입니다. 응답은 하지만 절대 기억하지 못하는 에이전트는 툴 콜링 실패입니다. 엔드포인트가 함수 호출을 구현하지 않았거나, id 뒤의 모델이 툴 스키마를 잘 다루지 못하는 것입니다. 증상은 대화는 작동하지만 코어 메모리가 절대 업데이트되지 않는 것입니다. 같은 에이전트를 claude-sonnet-4-6에서 테스트해 엔드포인트 문제와 모델 문제를 분리하세요. 잘못된 곳에 설정된 환경 변수는 도커의 고전입니다: 셸에서 export한 OPENAI_API_BASE는 -e 플래그 없이 시작된 컨테이너에는 아무 영향도 주지 않습니다. 변수는 서버 프로세스 자체에 도달해야 합니다. 그리고 엔드포인트가 서버 레벨이므로 파급 범위를 기억하세요: OPENAI_API_BASE를 바꾸면 그 서버의 모든 에이전트가 이동합니다. 에이전트별 엔드포인트 오버라이드가 없으므로 게이트웨이당 서버 하나가 깔끔한 토폴로지이며, 모델 선택은 에이전트별로 차별화하세요.

어떤 사람들이 게이트웨이를 통해 Letta를 쓰는가.

• 시도해보는 모델마다 별도의 벤더 계정, 키, 청구 표면 없이 Claude급 메모리 편집을 원하는 영구 어시스턴트 구축자.
• 사용자마다 에이전트를 받는 에이전트 무리를 운영하며, 키별 사용량 추적이 메모리 레이어의 실제 비용을 읽기 쉬운 리포트로 바꾸는 팀.
• 모델이 자기 편집형 메모리를 어떻게 다루는지 비교하는 연구자 — 각 후보는 프로바이더 마이그레이션이 아니라 테스트 에이전트의 핸들 변경일 뿐입니다.
• 직접적인 벤더 API 접근이 막혀 있고 네트워크 정책이 허용하는 것이 게이트웨이 엔드포인트 하나뿐인 환경의 셀프 호스터.
• 특정 벤더의 결제 수단에 접근할 수 없는 개발자. 카드 없이 충전만으로 사용할 수 있어 프로바이더별 가입 의존성이 사라집니다.

엔드포인트 검증 및 첫 에이전트 디버깅.

서버보다 먼저 게이트웨이를 검증하세요: 키로 모델을 나열하고, 툴 정의를 붙여 채팅 완성을 한 번 실행하세요. 툴 콜링이 Letta가 실제로 의존하는 능력이기 때문입니다. curl에서 툴 콜 왕복이 작동하면 엔드포인트 쪽은 증명된 것입니다. 그런 다음 변수 두 개로 서버를 시작하고 모델 목록을 읽으세요. 목록에 나타나는 모델은 등록을 증명하고, 목록에 있는 핸들로 성공적으로 만들어진 에이전트는 프리픽스 경로를 증명하며, 코어 메모리를 업데이트하는 대화는 루프 전체를 처음부터 끝까지 증명합니다. 이 순서로 디버깅하세요. 각 단계마다 별개의 실패 집합이 있기 때문입니다: 각각 환경 변수, 서버 버전, 모델의 툴 능력. 에이전트가 실행되기 시작하면 APIsRouter 콘솔에서 요청별 모델, 토큰 수, 지출을 볼 수 있습니다. 상태 유지 에이전트는 대화 기록이 시사하는 것보다 상호작용당 더 많이 청구됩니다. 모든 답변 뒤에서 메모리 관리가 실행되기 때문이며, 사용량 로그는 그 숨은 승수가 예산으로 잡을 수 있는 숫자가 되는 곳입니다.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

자주 묻는 질문