보조 슬롯 비용 줄이기 | Hermes provider를 바꿔도 청구서가 안 줄 때

provider 비교보다 먼저 비용 구조를 봅니다

Hermes에서 실제 비용을 흔드는 것은 메인 모델의 벤치마크보다 보조 슬롯, 압축 모델의 컨텍스트, 캐시가 언제 깨지는지입니다. provider 이름은 이 구조 위에 올라가는 마지막 선택에 가깝습니다.

💡 Tip: Hermes에서 비싼 청구서는 메인 답변 한 번보다, 작은 보조 작업이 같은 고가 모델을 계속 물고 들어갈 때 더 자주 만들어집니다.

인증 경로가 provider 선택보다 앞에 있습니다

많이 하는 오해가 "이미 구독 중이니 Hermes에 그냥 붙이면 되겠지"입니다. 공식 문서 기준으로는 provider마다 시작 조건이 다릅니다.

Anthropic OAuth는 Claude Max 플랜과 별도 구매한 extra usage credits가 있어야 동작합니다. Max에 기본 포함된 사용량이 아니라 추가로 충전한 크레딧만 Hermes 경로에서 차감됩니다. GitHub Copilot은 ghp_* 클래식 PAT를 받지 않고 gho_, github_pat_, ghu_ 계열만 허용합니다. OpenAI Codex는 device code 방식이라 별도 CLI 설치 없이도 붙을 수 있지만, 인증 파일 위치와 저장 방식은 일반 API 키 흐름과 다릅니다.

Nous Portal은 OAuth 한 번으로 여러 모델과 Tool Gateway까지 바로 연결되는 쪽이라, 새로 시작하는 사람에게 마찰이 가장 적습니다. 반대로 Anthropic, Copilot, xAI처럼 기존 구독을 재활용하는 경로는 플랜 조건이나 토큰 종류 제한이 먼저 발목을 잡는 경우가 많습니다.

여기서 실무 팁이 하나 있습니다. hermes model과 세션 안의 /model은 다른 명령입니다. /model은 이미 설정된 provider 사이 전환이고, 새 provider 추가나 OAuth 재인증은 세션을 나간 뒤 hermes model에서 합니다.

확인: 원하는 provider가 목록에 아예 없으면 세션을 종료한 뒤 hermes model을 다시 열어 보세요. /model만 반복했다면 인증 화면까지 못 간 상태일 가능성이 큽니다.

64K 컨텍스트가 안 되면 로컬 계획부터 다시 세워야 합니다

Hermes는 컨텍스트 64,000 토큰 미만 모델을 시작 시점에 거부합니다. 이유는 단순합니다. 시스템 프롬프트와 도구 스키마만으로도 기본 공간을 많이 먹기 때문에, 그 아래로는 멀티스텝 툴 호출이 안정적으로 성립하지 않기 때문입니다.

호스팅 provider는 대체로 이 조건을 넘지만 로컬 엔드포인트는 자주 여기서 걸립니다. Ollama가 대표적입니다.

일반적인 데스크톱에서 ollama serve를 그대로 켜면 4K나 32K로 뜰 수 있습니다. 그리고 OpenAI 호환 API 경로에서는 요청마다 컨텍스트를 올리는 방식이 아니라 서버 쪽 설정 자체를 바꿔야 합니다.

# 서버 전체에 적용
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# 모델 단위로 고정
FROM qwen2.5-coder:32b
PARAMETER num_ctx 64000

llama.cpp 계열은 --ctx-size 65536 같은 방식입니다. 로컬 모델로 비용을 아끼고 싶다면 단가보다 먼저 이 숫자가 가능한지부터 봐야 합니다.

⚠️ 주의: 로컬 모델이 "대답은 된다"와 Hermes에서 "실전 세션이 버틴다"는 같은 말이 아닙니다. 64K 미만이면 시작 단계에서 바로 걸러집니다.

확인: 로컬 엔드포인트를 붙이기 전에 실제 컨텍스트가 64K 이상인지 provider 측 관리 화면이나 실행 상태에서 먼저 확인하세요.

진짜 청구서는 보조 슬롯 11개에서 새기 시작합니다

Hermes는 메인 모델 외에 컨텍스트 압축, 비전, 웹 추출, 승인 판정, MCP 라우팅, 세션 제목 생성 같은 보조 작업용 슬롯을 따로 둡니다. 문제는 이 슬롯들이 기본값 auto이고, auto는 대체로 메인 모델을 먼저 사용한다는 점입니다.

즉 메인 모델을 Opus나 고가 추론 모델로 두면, 세션 제목 짓기나 압축 요약 같은 작은 작업도 같은 가격표로 처리될 수 있습니다. 그래서 provider를 바꿨는데도 비용이 안 내려가는 일이 생깁니다.

설정은 대시보드 Models 화면의 Show auxiliary에서 슬롯별로 바꾸거나, 모델 카드의 Use as 기능으로 한 번에 배정할 수 있습니다. YAML 기준으로는 다음과 같은 형태입니다.

auxiliary:
  title_generation:
    provider: openrouter
    model: google/gemini-3-flash-preview
  compression:
    provider: openrouter
    model: google/gemini-3-flash-preview

주의할 점도 있습니다. 보조 슬롯에 지정한 provider가 실제로 인증되지 않았으면 조용히 기본값으로 떨어지고 로그에만 경고가 남을 수 있습니다.

확인: 슬롯을 바꾼 뒤 새 세션을 열고, provider가 여전히 auto로 남아 있지 않은지와 인증이 살아 있는지를 함께 보세요.

압축 모델은 가격보다 컨텍스트 크기를 먼저 봐야 합니다

Hermes 압축은 두 층으로 생각하는 편이 이해가 쉽습니다. 에이전트 내부 압축은 기본적으로 컨텍스트의 50% 근처에서 걸리고, 게이트웨이 쪽 검사는 더 높은 비율에서 안전망처럼 한 번 더 작동합니다. 긴 세션을 유지하는 데는 이 구조가 도움이 되지만, 보조 압축 모델이 메인보다 작은 컨텍스트를 가지면 상황이 거꾸로 나빠집니다.

가장 조용하고 가장 아픈 함정은 이것입니다. 요약 모델 컨텍스트가 메인 모델보다 작으면, 중간 대화가 요약 없이 버려질 수 있습니다. 압축해야 하는 구간 전체를 요약 모델이 한 번에 받아야 하는데, 여기서 컨텍스트 초과가 나면 경고만 남기고 요약을 포기한 채 오래된 턴을 떨궈 버릴 수 있습니다. 사용자는 갑자기 앞 대화를 잊는다고 느끼고, 원인을 provider 품질 탓으로 오해하게 됩니다.

그래서 보조 압축 모델을 싼 쪽으로 바꿀 때는 가격표보다 컨텍스트 크기를 먼저 봐야 합니다. 1M 컨텍스트 모델과 128K 모델을 오가는데 모든 모델에 같은 임계값 50%를 두는 것도 낭비입니다.

compression:
  threshold: 0.50
  model_thresholds:
    "glm-5.2": 0.40
    "claude-sonnet": 0.35

이런 식으로 모델별 임계값을 따로 두면 긴 세션에서 압축 호출 빈도를 더 현실적으로 조정할 수 있습니다.

확인: 긴 세션에서 갑자기 앞 맥락을 못 이어받는다면 메인 모델보다 provider 자체를 탓하기 전에, 압축 모델의 컨텍스트 크기와 임계값부터 보세요.

프롬프트 캐시는 모델 전환과 폴백에서 깨집니다

Claude 계열처럼 프롬프트 캐싱이 잘 붙는 provider는 멀티턴 입력 비용을 크게 줄여 줍니다. 문제는 캐시 키가 보통 모델과 계정에 묶여 있다는 점입니다. 그래서 세션 중간에 /model로 모델을 바꾸거나, 폴백이 발동해 다른 provider로 넘어가면, 다음 요청이 전체 대화를 할인 없이 다시 읽을 수 있습니다.

특히 /model <name> --once처럼 한 턴만 올리는 동작은 생각보다 함정입니다. 짧은 세션에서는 유리할 수 있지만, 긴 세션 중간에 곁다리 질문 하나 때문에 캐시 프리픽스를 두 번 깨면 절약분보다 재읽기 비용이 커질 수 있습니다.

폴백도 마찬가지입니다. fallback_providers는 세션 단위가 아니라 턴 단위입니다. 새 사용자 메시지가 들어올 때마다 primary부터 다시 시도하고, 그 턴에서만 보조 provider를 씁니다. 장애를 피하는 데는 좋지만, 긴 세션에서는 provider를 자주 오갈수록 캐시 손실 가능성이 커집니다.

model:
  provider: anthropic
  default: claude-sonnet-4-6

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4

실무 규칙은 단순합니다. 모델 전환은 세션 초반이나 새 세션에서 하고, 긴 세션 중간에는 가급적 그대로 간다입니다.

provider 분류는 이름이 아니라 걸림돌 기준으로 봐야 합니다

provider 글이 자주 낡는 이유는 이름을 정리하는 데 그치기 때문입니다. Hermes 사용자에게 더 유효한 방식은 "언제 쓰는가"보다 "어디서 막히는가"를 같이 적는 것입니다.

중요한 것은 "어느 provider가 싸냐"보다 "내가 지금 부딪히는 병목이 인증인지, 컨텍스트인지, 캐시인지"를 먼저 가르는 일입니다. xAI처럼 모델 은퇴가 빠른 provider는 반년만 지나도 가격표와 목록이 낡아 버립니다. 이런 글에서는 단가표보다 확인 명령과 판단 기준이 더 오래 갑니다.

키와 설정 파일 경계를 실제 운영 기준으로 나눕니다

Hermes는 일반 설정과 시크릿을 파일 단위로 나누는 방향을 갖고 있습니다. 실제 운영에서 중요한 것은 이 경계를 사람이 손으로 잘 지키는가가 아니라, 도구가 경로를 분리해서 유지하느냐입니다.

~/.hermes/
├── config.yaml
├── .env
├── auth.json
└── logs/

일반적으로 config.yaml에는 모델, 터미널 백엔드, 압축 같은 비밀이 아닌 설정이 들어가고, .env와 auth.json에는 API 키와 OAuth 자격증명이 들어갑니다. 회사 키와 개인 키가 섞이면 감사 대응이 어려워지고, Docker 백엔드에서 컨테이너로 넘기는 환경 변수 화이트리스트까지 헷갈리기 시작합니다.

이 주제에서 중요한 질문은 "유명 provider냐"가 아니라 내 코드와 키가 어디를 거쳐 가는가입니다. 조직 환경이면 managed scope, egress 프록시, docker_forward_env 같은 경계 도구가 있는지까지 확인해야 합니다.

확인: 회사 저장소에서 Hermes를 돌릴 때는 어떤 키가 config.yaml, .env, auth.json, 컨테이너 전달 목록 중 어디에 놓였는지 한 번에 설명할 수 있어야 합니다.

하루짜리 셋업은 provider 추가보다 평범한 대화 확인이 먼저입니다

공식 문서 흐름에서 반복해서 나오는 원칙은 간단합니다. 평범한 대화 한 번이 안 되면 기능을 더 붙이지 말라는 것입니다. provider를 붙이고, 세션을 열고, 재개를 확인하고, 그 다음에야 보조 슬롯과 샌드박스를 만집니다.

# 1. provider 선택
hermes model

# 2. 평범한 대화 확인
hermes --tui

# 3. 세션 재개 확인
hermes --continue

# 4. 보조 슬롯 정리
hermes config set auxiliary.title_generation.provider openrouter
hermes config set auxiliary.title_generation.model google/gemini-3-flash-preview

# 5. 샌드박스와 egress
hermes config set terminal.backend docker
hermes egress setup
hermes egress start

# 6. 폴백은 마지막
hermes fallback add

# 7. 상태 확인
hermes doctor
hermes config get model --json

여기서 원본 글에 있던 docker run ... nousresearch/hermes-agent model 같은 예시는 공식 표준 설치 경로라기보다 특정 작성자 환경에 가깝습니다. 독자가 그대로 복사하다 막히기 쉬운 부분이라면 일반 설치 경로와 별도 예시를 분리해서 써야 합니다.

확인: hermes --tui에서 저장소 요약 같은 평범한 대화가 먼저 성립해야 합니다. 이 단계가 안 되면 보이스, 라우팅, 스킬, 게이트웨이 같은 다음 기능은 붙이지 마세요.

사용량은 총액보다 비율을 봐야 원인이 보입니다

원본 글의 "일별 호출 수와 실패율을 보라"는 방향은 맞았지만, Hermes 사용자에게 더 유용한 관찰값은 총액보다 비율입니다. Models 화면 하단의 모델별 사용량 카드에서 실제로 어떤 모델이 메인인지, 어떤 모델이 aux 슬롯으로 올라오는지를 같이 봐야 원인이 분해됩니다.

• 보조 작업 모델이 상위 사용량에 자주 보이면: 슬롯 정리가 안 된 상태입니다.
• 압축 호출이 유난히 많으면: threshold를 올리거나 model_thresholds로 모델별 조정이 필요합니다.
• 폴백 모델이 자주 보이면: primary가 불안정하고 캐시도 자주 깨지고 있을 가능성이 큽니다.

이 세 가지를 보면 provider 자체를 갈아타야 하는지, 아니면 같은 provider 안에서 보조 슬롯과 압축만 조정하면 되는지 판단이 빨라집니다.

원하는 provider가 안 보이거나 기억이 자꾸 끊길 때 원인을 거꾸로 봅니다

문제가 생겼을 때 증상은 비슷해도 원인은 꽤 다릅니다.

이 표의 핵심은 provider 이름을 더 찾는 게 아니라, 어느 층에서 막혔는지를 빨리 가르는 것입니다.

출처와 링크

• Hermes Agent Quickstart
• Hermes Agent AI Providers
• Hermes Agent Configuration
• Hermes Agent Configuring Models
• Hermes Agent Fallback Providers
• Hermes Agent Context Compression and Caching

조사 기준: 2026년 7월. 설정 키와 기본값, provider 목록, 모델 은퇴 여부는 릴리스마다 바뀔 수 있으니 적용 전 hermes config check와 hermes doctor로 현재 버전을 다시 확인하세요.