Paritok 토큰 게이트웨이로 AI 코딩 에이전트 비용 절감하기
Paritok은 코딩 에이전트의 파일 읽기와 도구 출력을 압축하여 토큰 사용량을 74%까지 줄여줍니다. 단순한 컨텍스트 삭제가 아닌 데이터 재구성 방식을 통해 비용을 절감하는 원리와 손익분기점 계산법을 상세히 설명합니다.
Paritok이 요청을 처리하는 방식
Paritok은 토큰 게이트웨이입니다. 코딩 에이전트와 모델 API 사이에서 요청을 압축한 뒤 전달하는 프록시 역할을 합니다. 에이전트는 제공업체 대신 http://127.0.0.1:8080과 통신합니다. 프록시는 도구 스키마, 파일 읽기, 도구 출력 및 이전 대화 내용을 재작성하여 더 작은 페이로드를 업스트림으로 전송하고, 응답은 변경하지 않은 채 그대로 반환합니다.
제공업체는 수신된 데이터 양을 기준으로 비용을 청구하므로, 페이로드가 작아지면 청구서 금액도 줄어듭니다. 이것이 이 도구의 핵심 개념입니다. 이는 단순히 "컨텍스트를 더 길게 유지한다"는 주장과는 다르며, 이 도구가 단순히 깔끔한 정리를 넘어 흥미로운 이유이기도 합니다.
이 프로젝트는 초기 단계입니다. 첫 공개 태그는 2026년 7월이며, 현재 태그는 2026년 8월 5일 자 v1.3.0입니다. 가중치와 게이트웨이 코드는 Apache 2.0 라이선스를 따릅니다. 압축 모델은 Qwen3-4B-Instruct-2507 기반의 LoRA(low-rank adaptation) 어댑터이며, 실제 코딩 에이전트의 궤적에서 추출한 45,000개의 교사 증류(teacher-distilled) 샘플로 학습되었습니다.
왜 이것이 컨텍스트 트리밍이 아닌가
트리밍은 데이터를 삭제합니다. 에이전트가 컨텍스트 제한에 도달하여 가장 오래된 대화 내용을 삭제하면, 3번째 턴에서 읽었던 파일은 사라집니다. 20번째 턴에서 해당 파일이 필요해지면 에이전트는 파일을 다시 읽어야 하므로, 해당 토큰에 대한 비용을 두 번 지불하게 됩니다. 즉, 절약은 일시적인 대출에 불과합니다.
Paritok은 세그먼트를 더 짧은 형식과 태그인 [REF:id]로 대체하고, 전체 텍스트는 프록시에 보관합니다. 모델은 read_original 또는 expand_context를 호출하여 세그먼트를 복구합니다. 이는 실패 방식에 변화를 줍니다. 트리머는 정보를 잊어버리는 방식으로 실패하며, 이 사실을 사용자에게 알리지 않습니다. 반면 압축기는 손실이 있는 요약본을 모델에 제공하는 방식으로 실패하며, 요약본이 충분하지 않을 경우 모델이 원본을 요청할 수 있습니다.
도구 필터도 동일하게 작동합니다. 필터링된 도구 스키마는 제거되는 대신 스텁(stub)으로 처리되며, 모델은 gateway_search_tools를 호출하여 도구를 복구합니다. 이는 중요한 차이입니다. 도구를 영구적으로 숨기는 필터는 에이전트의 수행 능력을 변화시키며, 사용자는 작업이 조용히 실패하고 나서야 그 사실을 알게 되기 때문입니다.
세 가지 레버와 무료로 제공되는 기능
첫 번째 레버는 도구-스키마 필터입니다. 모든 요청은 전체 tools 배열을 포함합니다. Claude Code 턴에서 여러 MCP(model context protocol) 서버를 연결하면, 해당 블록의 크기는 약 29,000 토큰으로 측정됩니다. 필터는 사용자의 요청과 각 도구 설명을 130 MB 크기의 임베딩 모델인 BAAI/bge-small-en-v1.5로 임베딩한 뒤, 일치하는 도구만 남기고 나머지는 스텁(stub)으로 처리합니다. 이 블록은 약 8,000 토큰으로 줄어듭니다. 해당 임베딩 모델은 CPU에서 실행됩니다.
두 번째 레버는 콘텐츠 압축이며, 이 부분은 GPU에서 4B 모델을 필요로 합니다. 파일 읽기, 도구 출력, 기록은 원래 크기의 25.7% 수준으로 다시 작성됩니다. 74%라는 수치는 여기서 나옵니다. 주의 깊게 읽어야 할 점은 74%가 압축 대상 콘텐츠의 압축률이지, 청구 금액의 절감액이 아니라는 것입니다.
세 번째 레버는 기록 요약입니다. 컨텍스트 예산이 가득 차면 최근 윈도우를 벗어난 턴들은 요약되어, 제한에 도달하지 않고 긴 세션을 계속 유지할 수 있게 합니다.
두 번째 레버만이 GPU를 필요로 합니다. 이 페이지에서 가장 유용한 문장입니다. pip install "paritok[toolselect]"은 일반적인 CPU VPS에서도 도구 필터 기능을 제공하며, 이는 매달 비용이 발생하지 않는 제품의 절반에 해당합니다. GPU를 대여하기 전에 먼저 시도해 보십시오.
측정 항목 및 테스트 환경
The data behind this chart
[
{
"label": "Paritok-4B-v1",
"compressed_to_pct": 25.7,
"quality_retained_pct": 86.5
},
{
"label": "gpt-4.1-mini",
"compressed_to_pct": 50.2,
"quality_retained_pct": 85.6
},
{
"label": "gpt-5",
"compressed_to_pct": 61.9,
"quality_retained_pct": 93.6
}
]이 수치는 프로젝트에서 SWE-bench Lite를 대상으로 자체 테스트 환경에서 측정한 공식 결과입니다. Paritok-4B-v1은 콘텐츠를 원본 크기의 25.7%로 압축하면서도, 압축하지 않았을 때의 해결률 대비 86.5%의 성능을 유지합니다. gpt-5를 압축기로 사용하면 93.6%로 더 높은 품질을 유지할 수 있지만, 압축률은 61.9%에 그칩니다. 또한, 최상위 모델의 비용을 지불하면서 최상위 모델의 비용을 절감하는 셈이 됩니다.
품질 지표를 객관적으로 확인하십시오. 해결률의 86.5%를 유지한다는 것은, 압축하지 않은 실행에서는 해결했던 문제를 압축 실행에서는 해결하지 못했다는 의미이며, 이는 대략 7번 중 1번꼴로 실패한다는 뜻입니다. 벤치마크에서는 표에 적힌 숫자일 뿐이지만, 실제 저장소에서는 두 번 실행해야 하는 작업이 됩니다.
The data behind this chart
[
{
"label": "Turn 1",
"saved_pct": 25
},
{
"label": "Turn 5",
"saved_pct": 39
},
{
"label": "Turn 12",
"saved_pct": 57
},
{
"label": "Turn 20",
"saved_pct": 63
}
]세션이 진행될수록 누적되는 기록이 압축 대상이 되므로, 전체적인 비용 절감 효과는 커집니다. 프로젝트 보고서에 따르면 단일 턴에서는 약 25%, 5턴에서는 39%, 20턴에서는 63%의 절감 효과가 나타납니다. 또한 절감 효과가 정체되는 지점도 명시되어 있습니다. 200,000 토큰 예산 내에서 절대적인 절감량은 8~12턴 부근인 턴당 약 48,000 토큰에서 평탄화됩니다. 컨텍스트가 가득 차면 기록이 더 이상 늘어나지 않기 때문입니다. 널리 인용되는 "85% 이상"이라는 수치는 컨텍스트가 포화된 세션을 기준으로 합니다. 이는 최상의 시나리오이므로, 이를 기준으로 계획을 세우지 마십시오.
FAQ
24GB GPU가 Paritok 비용을 상쇄할 수 있습니까?
이 정도 규모의 모델에는 24GB 카드가 일반적인 대여 단위입니다. 2026년 8월 7일 기준으로, 24GB RTX 4090의 시간당 온디맨드 평균 가격은 $0.44이며, 최저가는 $0.20 수준입니다. $0.44를 기준으로 계산해 보겠습니다. 한 달 내내 가동하면 730시간이므로 $321가 소요됩니다. 근무 시간에만 하루 8시간씩 22일간 가동하면 176시간이므로 $77가 소요됩니다.
이제 토큰 절감액을 달러로 환산해 보겠습니다. 이 절감 효과는 입력 토큰에 적용됩니다. 출력 토큰은 프록시를 그대로 통과하므로 비용 변화가 없습니다. 코딩 에이전트의 일반적인 경우처럼 입력 토큰이 전체 비용의 80%를 차지한다고 가정하고, 실제 청구서와 비교하여 이 가정을 확인하십시오. 달러 절감액은 토큰 감소율에 0.8을 곱한 값입니다.
The data behind this chart
[
{
"label": "Turn 5 (39% saved)",
"bill_always_on_usd": "1,030",
"bill_workday_only_usd": 248
},
{
"label": "Turn 20 (63% saved)",
"bill_always_on_usd": 637,
"bill_workday_only_usd": 154
},
{
"label": "Saturated (85% saved)",
"bill_always_on_usd": 472,
"bill_workday_only_usd": 114
}
]세션 포화도가 85%일 때 비용의 68%를 절감할 수 있으므로, 월간 에이전트 사용료가 약 $472를 넘으면 상시 가동하는 카드의 비용을 상쇄할 수 있습니다. 근무 시간에만 인스턴스를 사용한다면 이 기준은 약 $114가 됩니다. turn-20 수치인 63% 기준으로는 각각 $637와 $154가 됩니다. 짧은 세션에서 나타나는 turn-5 수치인 39% 기준으로는, 카드를 대여할 가치가 있으려면 월간 사용료가 최소 $1,030 이상이어야 합니다.
표에 제시된 것보다 상황을 유리하게 만드는 두 가지 요소가 있습니다. 모델이 반드시 24GB를 필요로 하지는 않습니다. q4 빌드는 약 2.5GB, bf16 빌드는 약 8GB이므로, 더 작은 카드를 사용하거나 이미 다른 용도로 운영 중인 GPU 서버를 활용하면 표의 모든 수치가 낮아집니다. 또한 코딩하지 않을 때 인스턴스를 중지하는 것이 가장 큰 비용 절감 수단인데, 이는 대여료를 약 4분의 3까지 줄여주기 때문입니다.
반대로 상황을 악화시키는 요소도 있습니다. 압축 과정은 실제 연산 작업을 수반합니다. 4B 모델이 압축하는 모든 토큰은 읽고 써야 하는 토큰이므로, 각 에이전트 턴마다 지연 시간이 추가됩니다. 시간당 비용을 지불하는 카드에서는 이 비용이 청구서의 항목이 아닌 대기 시간으로 나타나므로, 체감하기 전까지는 간과하기 쉽습니다.
일반적으로 대여 GPU 시간과 API 토큰 비용을 비교하고 있다면, GPU VPS와 API 토큰 간의 손익분기점에서 추론 자체에 대한 동일한 계산 방식을 확인할 수 있습니다.
VPS에서 Paritok 게이트웨이 실행하기
Python 3.10 이상이 필요합니다. Ubuntu 24.04는 Python 3.12를 기본으로 제공하므로, CPU 전용 환경이라면 별도의 설정 없이 기본 VPS 이미지만으로 충분합니다.
sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"버전을 고정하십시오. 해당 저장소는 2026년 7월 29일에 v1.2.8을, 2026년 8월 5일에 v1.3.0을 릴리스했습니다. 이처럼 빠르게 변화하는 프로젝트는 릴리스마다 설정 키 명칭을 변경하곤 합니다. 단순히 pip install paritok를 사용하거나 main의 git clone를 사용하면 다음 주에는 다른 게이트웨이가 설치될 수 있으며, 측정했던 수치가 어떤 버전에서 나온 것인지 기록이 남지 않습니다.
기본 백엔드는 Ollama입니다. 모델을 내려받은 뒤, 프록시가 인식할 수 있는 짧은 이름을 지정하십시오.
ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1그 옆에 paritok.yaml를 작성하십시오. use_gpu_server: false는 압축 기능을 로컬 하드웨어에서 유지하도록 하는 설정입니다.
use_gpu_server: false
local_model:
base_url: http://localhost:11434paritok proxy --port 8080 --config-file paritok.yamlparitok up은 위 모든 과정을 수행하는 단축 명령어입니다. 모델이 없으면 내려받고 8080 포트에서 프록시를 시작합니다. 에이전트를 연결하기 전에 프록시가 정상인지 확인하십시오.
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats/health는 "status":"ok"와 버전 문자열이 포함된 작은 JSON 객체를 반환합니다. /stats은 압축 총계와 프록시가 자체적으로 추산한 절감량을 반환합니다. 이 추산치는 프록시가 스스로의 작업을 평가한 결과이므로, 실제 사용량은 서비스 제공업체의 사용량 페이지에서 확인하십시오.
편의성보다 처리량이 중요하다면, vLLM을 사용하여 베이스 모델 위에 어댑터를 올리십시오.
vllm serve Qwen/Qwen3-4B-Instruct-2507 \
--enable-lora \
--lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
--port 8000Ollama는 구축이 빠릅니다. vLLM은 동시 요청 처리에 훨씬 뛰어나며, 여러 에이전트가 하나의 서버를 공유할 때 중요해집니다. Ollama와 vLLM의 실질적인 차이를 확인하여 선택하십시오.
베이스 URL 환경 변수를 사용하여 에이전트가 프록시를 가리키도록 설정하십시오.
export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080Codex CLI는 OPENAI_BASE_URL을 무시하므로, paritok.yaml에 codex.enabled: true가 설정되어 있으면 프로젝트가 자동으로 ~/.codex/config.toml을 작성합니다. 변수만 내보내면 Codex는 여전히 제공업체와 직접 통신하며, 이 경우 작업 중에도 /stats 카운터가 전혀 움직이지 않습니다.
리스너는 반드시 127.0.0.1에 유지하고, 0.0.0.0에는 절대 두지 마십시오. 프록시는 제공업체의 API 키를 업스트림으로 전달합니다. 따라서 인터넷에서 접근 가능한 프록시는 해당 키에 대한 오픈 릴레이(open relay)가 됩니다. 포트를 발견한 사람은 키를 직접 보지 않고도 사용자의 비용을 소진할 수 있습니다. 포트를 개방하는 대신 SSH 터널이나 VPN을 통해 노트북에서 접근하십시오.
재부팅 후에도 서비스가 유지되도록 systemd에서 실행하십시오. 설치 경로에 맞춰 경로를 수정하십시오.
[Unit]
Description=Paritok compression proxy
After=network-online.target
[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.targetsudo systemctl enable --now paritok로 서비스를 활성화한 뒤, 다시 /health를 curl로 호출하십시오. 서비스가 시작되자마자 종료된다면 설정 파일 경로가 잘못되었을 가능성이 큽니다. 이때 journalctl -u paritok -n 50을 실행하면 원인을 확인할 수 있습니다.
호스팅 옵션과 그 비용
이 프로젝트는 압축 기능을 서비스 형태로도 판매합니다. API 키로 use_gpu_server: true을 설정하면 4B 모델이 해당 업체의 하드웨어에서 실행됩니다. 가격은 토큰 100만 개 처리당 $0.30이며, 자체 문서에 따르면 2026년 8월 말까지는 무료로 제공됩니다. 이 방식을 사용하면 GPU 대여 비용과 앞서 언급한 모든 운영 업무가 사라집니다.
하지만 이는 사용자의 프롬프트와 에이전트가 읽는 파일이 모델 제공업체에 도달하기 전에, 사용자의 기기를 떠나 제3자에게 전송됨을 의미합니다. 셀프 호스팅은 바로 이러한 중간 단계를 피하기 위해 존재합니다. 해당 플래그를 설정하기 전에 무엇을 우선시할지 결정하십시오. 플래그 변경은 한 줄로 끝나지만, 그 결과는 그렇지 않기 때문입니다.
직접 전후 성능을 측정하는 방법
공개된 수치는 SWE-bench Lite 환경에서 프로젝트 자체 테스트 도구를 사용하여 측정한 결과입니다. 귀하의 저장소는 SWE-bench Lite가 아니므로, 직접 측정해야 합니다.
- 프록시를 거치지 않는 일반적인 일주일을 보냅니다. 제공업체의 사용량 페이지에서 입력 토큰, 캐시 읽기 토큰, 출력 토큰을 총 비용(달러)이 아닌 각각 별도의 줄로 기록합니다.
- 다음 일주일은 프록시를 앞에 두고 동일한 유형의 작업을 수행합니다.
- 입력 토큰과 캐시 읽기 토큰 수치를 비교합니다. 출력 토큰은 압축되지 않으므로 수치가 거의 일정해야 합니다. 만약 출력 토큰 수치가 크게 변했다면 프록시 외의 다른 요인이 변경된 것입니다.
- 다시 수행해야 했던 작업의 수를 셉니다. 이는 성능의 질적 측면을 나타내며, 어떤 대시보드에서도 보고하지 않는 지표입니다.
- 총합을 비교하기 전에 2주 차의 GPU 사용 시간을 추가합니다.
입력과 출력을 분리하는 것은 두 항목의 가격 책정 방식이 매우 다르며, 압축기는 그중 하나에만 영향을 미치기 때문에 중요합니다. 2026년 8월 기준, Claude Sonnet 4.6은 입력 토큰 100만 개당 3달러, 출력 토큰 100만 개당 15달러이며, 프롬프트 캐시 읽기는 입력 요금의 10%인 100만 개당 0.30달러입니다. 입력 토큰과 출력 토큰 비용의 차이가 입력 측 압축기의 가치를 결정합니다. Claude Code의 토큰이 실제로 소비되는 곳을 확인하면 컨텍스트 중 어느 부분이 압축할 가치가 있을 만큼 큰지 알 수 있습니다.
프롬프트 캐싱은 특히 도구 필터 계산을 복잡하게 만듭니다. 도구 블록은 요청의 앞부분에 위치하므로, 첫 번째 턴 이후에는 일반적으로 입력 가격의 10%로 캐시 적중이 발생합니다. 캐시된 블록에서 21,000 토큰을 줄이면 캐시되지 않은 요율인 0.063달러가 아닌, 100만 개당 0.30달러 기준으로 21,000 토큰, 즉 턴당 약 0.006달러를 절약하게 됩니다. 이 프로젝트는 세션 동안 필터링된 블록을 고정 상태로 유지하여 캐시된 접두사가 변경되지 않도록 합니다. 매 턴마다 도구를 다시 선택하는 필터는 해당 접두사를 무효화하여 절약한 비용보다 더 많은 비용을 발생시킬 것입니다.
아직 검증되지 않은 사항
위의 모든 성능 수치는 프로젝트 자체에서 제공한 것입니다. SWE-bench Lite 결과에 대한 독립적인 재현 사례는 없으며, 2026년 7월에 첫 태그가 생성된 이후 코드의 운영 이력도 매우 짧습니다. 압축률과 품질 유지 수치 모두 해당 지표가 유리하게 작용하는 당사자가 측정한 것입니다. 이것이 해당 수치가 틀렸다는 의미는 아닙니다. 다만 확인되지 않은 수치이므로, 직접 산출한 데이터와는 다르게 취급해야 합니다.
설정을 탓하기 전에 알아두어야 할 문서화된 동작이 하나 있습니다. 도구 필터가 사용하는 임베딩 모델은 시작 시점이 아닌 첫 번째 요청 시점에 로드됩니다. 따라서 프로젝트 문서에서는 10에서 15초 정도의 웜업(warm-up) 시간이 필요하며, 이후 호출당 약 15 ms가 소요된다고 안내합니다. 프록시가 시작된 후 테스트용 요청을 하나 보내두면, 실제 에이전트의 첫 번째 작업이 멈춘 것처럼 보이는 현상을 방지할 수 있습니다.
오후 시간 동안 직접 확인해 볼 수 있는 네 가지 사항이 있습니다. 프록시가 시작되어 유지되는지, 작업 중에 /stats가 이동하는지, 사용 중인 제공업체의 입력 토큰 사용량이 실제로 감소하는지, 그리고 에이전트가 여전히 작업을 완료하는지 여부입니다. 이러한 사항들은 어떤 공개된 벤치마크보다 귀하의 설정에 적합한지 판단하는 데 더 나은 기준이 됩니다.
이 도구가 기존 도구들과 어떻게 배치되는지에 관하여, 자체 호스팅 LiteLLM 게이트웨이는 요청 내용을 변경하지 않고 라우팅 및 계측을 수행합니다. 따라서 두 도구는 서로 다른 문제를 해결하며, Paritok을 에이전트에 가장 가깝게 배치하여 함께 연결할 수 있습니다. 만약 실제 목표가 특정 도구의 사용이 아닌 비용 절감이라면, VPS 기반 에이전트를 위한 광범위한 비용 제어 설정을 통해 비용 부담 없이 먼저 시도해 볼 수 있는 여러 변경 사항을 확인할 수 있습니다.
FAQ
Paritok은 API 비용을 줄여줍니까, 아니면 컨텍스트 사용량만 줄여줍니까?
비용이 절감됩니다. 프록시가 요청을 제공자에게 전달하기 전에 다시 작성하므로, 제공자는 수정된 요청을 기준으로 요금을 청구합니다. 실제 절감 폭은 광고하는 수치보다 작을 수 있습니다. 74%라는 수치는 압축되는 콘텐츠의 압축률을 의미합니다. 종단 간(end-to-end) 기준으로 이 프로젝트는 단일 턴에서 약 25%, 20번째 턴에서 약 63%의 절감 효과를 보고하며, 입력 토큰만 영향을 받습니다. 출력 토큰은 변경 없이 그대로 통과합니다.
압축 모델을 직접 호스팅하려면 GPU가 얼마나 필요합니까?
q4 빌드는 약 2.5 GB, bf16 빌드는 약 8 GB를 차지하므로 24 GB 카드에서 충분한 여유를 두고 실행할 수 있습니다. 더 작은 카드에서도 작동하며, 이 경우 손익분기점 계산이 사용자에게 더 유리해집니다. 도구 스키마 필터는 GPU가 전혀 필요하지 않습니다. 이 필터는 CPU에서 실행되는 130 MB 크기의 임베딩 모델인 BAAI/bge-small-en-v1.5를 사용합니다. 일반적인 VPS에 paritok[toolselect]를 설치하면 약간의 RAM 사용만으로 도구 블록 압축 효과를 얻을 수 있습니다.
압축기가 에이전트에게 필요한 정보를 삭제하면 어떻게 됩니까?
아무것도 삭제되지 않습니다. 압축된 세그먼트에는 [REF:id] 태그가 붙으며, 모델은 read_original 또는 expand_context를 사용하여 전체 텍스트를 복구합니다. 필터링된 도구 스키마는 삭제되는 것이 아니라 스텁(stub)으로 대체되며, 모델은 gateway_search_tools을 통해 이를 복구합니다. 실제 위험은 파일이 누락되는 것보다 더 미묘합니다. 모델이 손실이 있는 요약본을 기반으로 작업하다가 원본을 요청해야 한다는 사실을 깨닫지 못할 수 있습니다. SWE-bench Lite에서 측정하는 86.5%의 품질 유지 수치가 바로 이를 의미합니다.
첫 번째 요청에 왜 15초나 걸립니까?
도구 필터 뒤에 있는 임베딩 모델이 시작 시점이 아닌 첫 번째 요청 시점에 로드되기 때문입니다. 프로젝트 문서에 따르면 10에서 15초 정도의 웜업 시간이 필요하며, 그 이후에는 호출당 약 15 ms가 소요됩니다. 프록시를 시작한 후 curl를 사용하여 의미 없는 요청을 하나 보내두면, 첫 번째 실제 에이전트 턴에서 지연이 발생하지 않습니다.
직접 호스팅 대신 호스팅된 GPU 서버를 사용해야 합니까?
호스팅 서비스를 사용하면 GPU 대여 비용과 유지보수 부담이 사라지며, 2026년 8월 기준으로 처리된 토큰 100만 개당 $0.30의 요금이 부과됩니다. 하지만 이 방식은 프롬프트와 에이전트가 읽는 파일을 모델 제공자에게 도달하기 전에 제3자에게 전송합니다. 코드를 직접 제어하는 인프라에 유지하기 위해 직접 호스팅을 선택했다면, 이 설정은 도입 취지를 무색하게 만듭니다. 직접 호스팅을 유지해야 컨텍스트와 제공자 API 키를 모두 자신의 서버 내에 안전하게 보관할 수 있습니다.