Hermes reasoning effort 설정: 세션·전역·모델별 적용

Hermes를 항상 가장 높은 reasoning 단계로 두어도 모든 작업이 좋아지는 것은 아닙니다. 화면에 thinking이 보인다고 해서 선택한 effort가 실제 요청에 적용됐다는 뜻도 아닙니다. 일상 작업에는 실용적인 전역 기본값을 두고, 어려운 작업에서만 세션 값을 올리며, 반복 비교로 효과가 확인된 모델에만 모델별 기본값을 추가한 뒤 동일한 검증 과제와 공급자 요청 기록으로 확인하는 방식이 안전합니다.

기본 선택: medium에서 시작하기

Hermes는 none, minimal, low, medium, high, xhigh, max, ultra를 받습니다. 값을 설정하지 않으면 medium으로 해석됩니다. 다만 모델이나 경로가 전체 단계를 지원하지 않을 수 있어 값이 낮아지거나, 다른 값으로 변환되거나, 무시되거나, 거부될 수 있습니다. 최신 동작은 Hermes 설정 문서와 사용 중인 공급자의 실제 요청 기록을 함께 확인하세요.

작업	시작 단계	변경 조건
형식 변환, 필드 추출, 결정적인 짧은 재작성	low; 지원 확인 후에만 minimal 또는 none	필드 누락이나 형식 위반이 있으면 medium
작은 코드 수정, 일반 질문, 범위가 명확한 디버깅	medium	반복해서 정확하면 low, 제약을 놓치면 high
여러 제약이 있는 리뷰, 파일 간 원인 분석, 설계 비교	high	품질 향상이 반복되고 대기 시간이 허용될 때만 xhigh 또는 max
매우 어려운 계획이나 긴 의존 관계 분석	먼저 high와 xhigh 비교	통제된 비교에서 실질적 이득이 있을 때만 max 또는 ultra

ultra는 Hermes 내부 단계입니다. 현재 경로가 실제로 보낼 수 있는 가장 높은 값으로 매핑되므로, 이름만 보고 전역 기본값으로 선택하지 마세요.

Thinking 표시와 effort 변경은 서로 다른 설정

다음 명령은 현재 세션의 reasoning effort를 바꿉니다.

/reasoning high
/reasoning none

다음 명령은 thinking 표시 여부만 바꿉니다.

/reasoning show
/reasoning hide

Thinking을 숨겨도 요청은 high로 동작할 수 있습니다. Thinking이 보인다고 해서 높은 단계라는 뜻도 아닙니다. 인수 없이 /reasoning을 실행해 현재 effort와 표시 상태를 따로 확인하세요.

세션·전역·모델별 설정을 언제 쓰나

세션: 지금 처리할 어려운 작업 하나

활성 세션에서 다음을 실행합니다.

/reasoning high

기본적으로 변경은 현재 세션에만 적용됩니다. 이후 모든 대화를 바꾸지 않고 특정 디버깅이나 아키텍처 판단에만 더 많은 effort를 배정하는 가장 안전한 방법입니다.

현재 세션에서 reasoning 비활성화를 요청하려면 다음을 사용합니다.

/reasoning none

선택한 모델과 경로가 비활성화를 허용해야 실제로 꺼집니다. 공급자가 reasoning을 필수로 요구하거나, 값을 다른 방식으로 매핑하거나, 거부할 수 있으므로 실제 요청 기록을 확인해야 합니다.

전역: 일상적인 기본값

새 세션에도 값을 저장하려면 --global을 붙입니다.

/reasoning medium --global

Hermes는 이를 agent.reasoning_effort로 저장합니다. 다양한 작업을 한다면 최대 단계보다 medium을 전역 기준으로 두고, 정말 어려운 세션만 일시적으로 올리는 편이 안전합니다.

터미널에서 저장된 값을 읽습니다.

hermes config path
hermes config get agent.reasoning_effort
hermes config check

config get이 값을 반환한다는 것은 Hermes가 설정을 읽었다는 뜻입니다. 공급자가 그 값을 그대로 수락하고 실행했다는 증거는 아닙니다.

모델별: 자주 전환하는 모델의 안정적인 기본값

빠른 모델과 깊은 reasoning 모델을 자주 오간다면 config.yaml을 수정합니다.

agent:
  reasoning_effort: "medium"
  reasoning_overrides:
    "custom/example-fast-model": "low"
    "custom/example-deep-model": "high"

일치하는 모델별 설정은 전역 agent.reasoning_effort보다 우선합니다. Hermes에 실제로 설정한 정확한 model ID를 사용하는 것이 좋습니다. 파일을 수정한 뒤 새 세션을 열고 대상 모델을 선택한 다음 /reasoning을 다시 실행하세요.

설정 맵은 다음으로 확인합니다.

hermes config get agent.reasoning_overrides --json

Model ID에는 점과 슬래시가 자주 들어갑니다. YAML을 직접 수정하는 방법이 간단합니다. hermes config set으로 점이 포함된 새 키를 만들 때는 CLI 명령 문서의 리터럴 점 이스케이프 규칙을 따르세요.

우선순위: 전역 값을 바꿔도 달라지지 않는 이유

선택한 모델에서는 다음 순서로 생각하면 됩니다.

1. 현재 세션의 임시 /reasoning 선택
2. 일치하는 agent.reasoning_overrides 항목
3. 전역 agent.reasoning_effort
4. 모델 또는 공급자의 기본값

전역 값이 low인데 /reasoning이 계속 high를 보여 준다면, 먼저 세션 설정이나 모델별 설정을 찾으세요. /model로 전환한 뒤에도 다시 확인해야 합니다. 새 모델은 다른 override와 일치할 수 있습니다.

동일한 검증 과제로 비교하기

한 단계는 단순 재작성으로, 다른 단계는 어려운 버그로 테스트하면 effort가 아니라 작업 차이를 측정하게 됩니다. 아래 작은 과제는 사람이 결과를 확인할 수 있고 도구도 필요하지 않습니다.

이 함수는 겹치거나 맞닿은 닫힌 정수 구간을 병합하되, 이미 포함한 범위를 줄이면 안 됩니다.
최소 반례 하나를 찾고, 예상 출력과 실제 출력을 제시하며, 가장 작은 코드 수정과 회귀 테스트 세 개를 작성하세요.
도구를 사용하지 마세요. counterexample, expected, actual, fix, tests 키를 가진 JSON만 반환하세요.

def merge_ranges(ranges):
    ranges = sorted(ranges)
    merged = []
    for start, end in ranges:
        if not merged or start > merged[-1][1] + 1:
            merged.append([start, end])
        else:
            merged[-1][1] = end
    return merged

뒤 구간이 현재 구간 안에 완전히 포함될 때 더 작은 끝값을 대입해 범위를 줄이는 것이 핵심 오류입니다. 문체가 아니라 다음 다섯 항목을 각 1점으로 평가하세요.

1. 추가 문장이 없는 유효한 JSON
2. 실제 오류를 일으키는 포함 구간 반례
3. 올바른 expected와 actual
4. 더 큰 끝값을 유지하는 최소 수정
5. 포함·인접·분리 구간을 다루는 테스트

수동 비교: 장기 기본값을 빠르게 고르는 방법

후보 단계마다 새 세션을 사용하세요. Model ID, 공급자, 작업 디렉터리, 컨텍스트, 도구 설정, 과제 문구, 출력 형식을 동일하게 유지합니다. 1회 실행은 1차 선별에 충분하지만, 자주 쓰는 기본값을 바꿀 결정이라면 각 최종 후보를 최소 세 번 정상 실행해 우연한 차이를 안정적인 개선으로 오해하지 않도록 합니다.

다음을 기록하세요.

항목	기록 방법
Effort	과제 전에 /reasoning을 실행하고 표시값 저장
품질	위의 0~5점 기준으로 평가
대기 시간	제출부터 최종 답변 완료까지의 실제 시간
모델과 공급자	Hermes 상태와 공급자 요청 기록에서 확인
실제 사용량	provider/API 요청 기록이나 청구 상세 사용
이상 징후	timeout, retry, fallback, 오류, 모델 전환 표시

Retry나 fallback이 발생한 실행은 정상 실행과 평균내지 마세요. 모델, 호출 수, 대기 시간, Token 사용량이 동시에 달라져 reasoning effort의 영향만 분리할 수 없습니다.

--usage-file로 Hermes 로컬 보고서 저장하기

기계적으로 비교하려면 전역 단계를 일시적으로 변경해 같은 one-shot 과제를 실행합니다.

hermes config set agent.reasoning_effort low
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-low-usage.json > ./hermes-low-output.txt

hermes config set agent.reasoning_effort medium
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-medium-usage.json > ./hermes-medium-output.txt

hermes config set agent.reasoning_effort high
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-high-usage.json > ./hermes-high-output.txt

실제 비교에서는 위의 축약 문구 대신 세 실행에 동일한 전체 과제를 전달하세요. 선택한 모델의 모델별 설정이 전역 값을 가리지 않는지도 먼저 확인합니다. 테스트 후 원래 설정을 복원하세요. 이전에 값이 없었다면 다음을 실행합니다.

hermes config unset agent.reasoning_effort

명시적 값이 있었다면 기록한 원래 값으로 다시 설정합니다.

Hermes JSON에는 input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider, estimated_cost_usd가 포함될 수 있습니다. 최상위 카운터는 main agent loop를 다룹니다. 제목 생성, vision, compression 같은 보조 호출은 auxiliary에 분리되며, 로컬 합계는 total_including_auxiliary에 있습니다.

다음 세 경계를 구분하세요.

• estimated_cost_usd는 로컬 추정치이지 공급자 청구서가 아닙니다.
• 공급자가 어떤 Token 범주를 반환하지 않으면, 필드가 없다는 사실은 사용량이 0이라는 증거가 아닙니다.
• Retry나 fallback이 발생하면 공급자 요청 목록에서 실제 호출과 모델을 확인해야 합니다.

네 가지 증거를 분리해서 확인하기

유효한 검증은 다음 네 가지를 따로 기록합니다.

1. 설정 읽기: hermes config get과 config.yaml에 의도한 값이 있는지 확인합니다. 이는 Hermes가 저장하고 해석한 값을 증명할 뿐, 공급자가 수락한 값을 증명하지는 않습니다.
2. 실제로 전송되거나 매핑된 effort: 대상 모델을 고른 뒤 /reasoning을 실행합니다. 상태에 sends ... on this route가 표시되거나 경로가 송신 요청 trace를 제공하면, API로 전송된 값이 예상 매핑과 일치하는지 확인합니다. Thinking 표시 여부는 별도의 화면 설정입니다.
3. 공급자 측 수신·수락·실행: 경로나 공급자가 실제로 제공할 때만 서버 측 요청 기록, echoed value, 명시적인 수락·실행 확인을 사용합니다. 성공 신호는 서버 측 파라미터가 전송·매핑된 값과 일치하고 거부, retry, fallback, 추가 하향 조정 기록이 없는 것입니다. Payload trace는 수신만 증명할 뿐 실행을 증명하지 않습니다. 공급자가 제공하지 않는 필드를 요구하지 마세요.
4. 사용량과 결과: 실제 모델, 출력 품질, 지연 시간, Token 범주, API 호출 수, 청구 또는 추정 비용을 기록합니다. 이 데이터는 경로와 실제 사용량을 확인할 수 있지만 공급자가 수락한 effort를 증명하지는 않으며, reasoning Token 수로 단계를 역산할 수도 없습니다.

네 가지 증거는 서로를 대신하지 않습니다. 공급자 로그가 모델, Token, 호출 수, 소비액만 보여 주고 effort를 공개하지 않는다면, 기록된 설정 아래에서 출력·지연 시간·실제 사용량을 비교했다는 결론까지만 내릴 수 있고 공급자가 실제로 수락한 단계는 확인할 수 없습니다.

none이 저장되지 않는 것처럼 보일 때

2026년 10월 5일 공개된 GitHub issue에서 작성자는 자신이 명시한 특정 main 커밋에서 hermes config set agent.reasoning_effort none이 YAML null을 저장할 수 있었고, /reasoning none --global은 문자열 none을 저장했다고 보고했습니다. 이는 특정 버전에 한정된 사용자 보고입니다. 현재 버전에도 같은 현상이 있거나 이후 버전에서 수정되었다는 증거는 아닙니다.

다음 순서로 확인하세요.

1. /reasoning none --global 실행
2. hermes config get agent.reasoning_effort 실행
3. hermes config path가 가리키는 파일을 열어 값이 빈 값이나 null이 아니라 문자열 none인지 확인
4. 새 세션을 시작하고 /reasoning을 다시 실행
5. 경로나 공급자가 서버 측 요청 기록, echoed value, 명시적인 확인을 제공할 때만 전송·매핑된 값과 수신·수락된 값을 대조합니다. 로그에 모델, Token, 소비액만 있다면 수락된 effort를 확인할 수 없다고 기록하고 역산하지 않습니다.

모델이 reasoning을 필수로 요구한다면 완전히 끌 수 없습니다. 표시 설정을 반복해서 바꾸는 대신 해당 경로가 받는 가장 낮은 단계를 사용하세요.

OpenAI-compatible 사용자 지정 공급자를 쓸 때

실제 동작은 Hermes, 모델, 공급자의 조합으로 결정됩니다. 예를 들어 현재 BetterToken Hermes 설정 가이드는 자신의 API Key, Base URL https://www.bettertoken.ai/v1, 카탈로그의 정확한 model ID를 설정한 뒤 짧은 요청으로 연결을 먼저 확인하도록 안내합니다. BetterToken은 모든 모델이 모든 reasoning 단계를 지원하거나 높은 단계가 모든 작업을 개선한다고 보장하지 않습니다.

어떤 공급자든 model ID, 요청 기록, 실제 사용량을 같은 비교표에 넣으세요. 그렇지 않으면 의도하지 않은 모델, 경로, 청구 방식 변경을 reasoning effort의 효과로 오해할 수 있습니다.

품질 기준을 넘는 가장 낮은 단계를 선택하기

전역 기준은 medium으로 두고, 가끔 발생하는 어려운 작업은 세션 설정을 사용하세요. 동일 과제를 반복 비교해 안정적인 이득이 나타난 모델에만 high, xhigh 또는 그 이상의 모델별 설정을 추가합니다. 기계적인 작업은 품질 기준을 유지하고 측정한 지연 시간이나 실제 사용량이 예상대로 개선될 때만 low, minimal, none으로 낮춥니다. 경로가 sends 매핑이나 공급자 측 수락·실행 기록을 공개하면 이를 확인하고, 공개하지 않으면 증거의 한계를 명시해 Token이나 소비액을 수락된 단계의 증명으로 사용하지 마세요.

유용한 기본값은 이론적으로 가장 강한 단계가 아닙니다. 사용 중인 모델과 경로에서 허용 가능한 대기 시간과 실제 사용량으로 품질 목표를 꾸준히 충족하는 가장 낮은 effort입니다.