요청에 필드 하나를 추가하자 에이전트 비용은 3배 절감되고 속도는 8배 빨라졌습니다

요약. 추론 모델(Reasoning models)은 사용자가 생각할 시간을 지정해주지 않으면 스스로 얼마나 오래 생각할지 결정합니다. 저희 에이전트는 그렇지 않았는데, 어려운 작업의 경우 모델이 한 단계에서 무려 14분 동안 33K 토큰을 소비하기도 했습니다. 요청 본문(request body)의 특정 필드("reasoning": {"effort": "low"})를 사용하자 작업을 3배 더 저렴하고 7~8배 더 빠르게 처리했으며, 수행하는 작업량도 줄지 않았습니다. (기존 7개 중 6개를 해결하던 것에서 12개 모두를 해결했습니다.) 결국 가장 좋은 설정은 '항상 낮게(always low)'나 '항상 높게(always high)'가 아니라, "테스트 실패 직후에만 낮게, 그리고 높게"였습니다. 아래에서는 측정 방법, 표, 코드, 그리고 이 방식이 고치지 못하는 것들에 대해 설명합니다.

본 게시물 소개. 프로젝트는 PC와 휴대폰에서 사용할 수 있는 오픈 소스(Apache-2.0) AI 에이전트인 Altair입니다. 제가 작성했으며 주로 Claude Code를 이용해 구축했습니다. 이 게시물, 실험 내용 및 차트는 동일한 AI 비서가 준비했으며, 저는 이를 검토하고 지지합니다. 모든 수치는 저희의 실행 결과를 기반으로 합니다.

이 프로젝트에 대한 세 번째 글입니다: 첫 번째는 스냅샷과 "완료(done)" 메시지 전에 테스트를 실행하는 것에 관한 것이었고, 두 번째 글은 브라우저 에이전트의 토큰을 58% 절감하는 것에 관한 것이었습니다.

시작 배경

저희는 저렴한 추론 모델(glm-5.3-flash)로 에이전트를 실행하고 제공업체의 로그를 확인했습니다. 한 작업에서 첫 단계만 무려 14분이 걸렸습니다. 제공업체 측에서는 청구할 시간이 충분했고, **단일 단계에서 32,978개의 추론 토큰(reasoning tokens)**을 사용했지만 답은 얻지 못했습니다. 저희의 루프 가드(loop guard)는 스트림을 160,000자에서 잘랐습니다.

원인은 사소했습니다. 추론 모델에는 "얼마나 깊이 생각할지"를 조절하는 노브가 있습니다. OpenAI에서는 reasoning_effort, OpenRouter에서는 reasoning.effort, Z.ai 스타일 API에서는 thinking으로 불립니다. 이 설정을 보내지 않으면, 제공업체 또는 모델이 스스로 결정합니다. OpenRouter의 문서에서도 그렇게 명시하고 있습니다. 저희 에이전트는 아무것도 보내지 않았습니다.

측정 방법

쉬운 작업(버그 수정, 코드 관련 질문 답변 등)은 어떤 설정에서도 100% 해결되었으므로 차이가 없습니다. 저희는 숨겨진 테스트가 포함된 여섯 가지 어려운 작업을 작성했습니다. 에이전트는 이를 볼 수 없으며, '완료'라고 말한 후에 실행됩니다:

• 시간 제한(time-to-live)이 있는 LRU 캐시 (11개의 숨겨진 엣지 케이스 테스트);
• 사용자 버그 보고서 7건으로부터 설정 파서 수정;
• 다중 파일 패키지 전반에 걸쳐 함수 이름 변경 및 매개변수 추가;
• 제외 항목이 포함된 로그의 지연 시간 95번째 백분위수 계산;
• "1.5M", "200K", "10 тыс" 파싱;
• 공휴일을 포함한 날짜 사이의 영업일 수, 100년 이상의 기간에 걸쳐 빠르게 계산.

각 작업은 숨겨진 테스트가 공정하도록 참조 코드를 사용하여 먼저 해결되었습니다. 에이전트는 실제 Altair이며 CLI(altair -p)를 통해 실행됩니다. 에이전트와 제공자 사이의 프록시가 모든 요청(크기, 캐시된 토큰, 추론 토큰, 시간)을 기록했습니다. 비용은 OpenRouter가 청구한 금액입니다.

결과

m$는 달러의 천분의 일입니다. 레벨 없이 12.6 m$였던 비용이 low를 사용하면 4.2 m$로 세 배 적게 들었습니다. 시간은 4.1분에서 0.55분으로, 7.5배 빨라졌습니다.

왜

평균적으로 레벨(level) 없이 태스크당 9,743개의 추론 토큰을 사용하지만, low를 사용할 경우 235개로, 41배 적습니다. 이 모델의 경우 출력 토큰 비용이 입력보다 3.3배 높아 까다로운 태스크에서는 추론(reasoning)이 주요 비용 항목입니다.

긴 태스크는 어떨까요?

짧은 태스크는 59단계였습니다. 저희는 또한 1520단계의 태스크도 시도해 보았습니다. 서로 다른 모듈에 버그가 여섯 개 포함된 패키지, 자체 코드 60개 파일에서 12개 값을 감사(auditing)하는 작업, 그리고 "여덟 개의 파일을 완전히 읽은 후 그 파일들에 대해 질문하기" 같은 작업들이었습니다.

모든 설정에서 9개 중 9개를 해결했지만, 레벨 없이 진행할 경우 태스크당 비용은 28m$에 달하고 소요 시간은 5.2분이 걸렸습니다. 명시적인 레벨을 사용했을 때는 11~13m$이며 1분 조금 넘게 걸렸습니다.

핵심 변화: 무언가 잘못되었을 때만 깊이 생각하기

low는 저렴하고, high는 더 안전합니다. 저희는 둘 다 원했기 때문에 단계별로 두 가지 모드를 시도했습니다:

• "계획에 대해 생각하기(think about the plan)" — 첫 번째 단계에서는 high를 사용하고 이후에는 low를 사용합니다;
• "실패 후에 생각하기(think after a failure)" — 기본적으로는 low를 사용하지만, 테스트가 실패했거나 도구가 오류를 반환한 바로 다음 단계에서만 high를 사용합니다.

문제는 모든 제공자가 자체 필드를 가지고 있다는 점입니다:

def reasoning_extra(level, base_url, model, override="auto"):
    """추론 레벨에 대한 요청 필드 ( "default" / 알 수 없는 레벨의 경우 {})."""
    if level not in LEVELS:
...

우가 그 과정에서 마주친 문제들:

• 이 모델의 경우 OpenRouter는 reasoning: {"enabled": false}와 reasoning_effort: "none"을 400 에러 코드("Reasoning is mandatory for this endpoint")와 함께 거부합니다. 오직 effort: "low"만 작동합니다.
• 반대로 Z.ai 스타일의 게이트웨이는 thinking: {"type": "disabled"}를 사용하며, reasoning.effort에 대해서는 아예 응답하지 않았습니다.
• 필드를 알지 못하는 제공자는 400 에러를 반환할 수 있습니다. 우리는 이를 포착하고, 해당 필드 없이 재시도한 후, 다시 보내지 않도록 기억합니다.

에이전트 루프는 각 단계별로 레벨을 선택합니다:

FAILURE_RE = re.compile(r"\b\d+ failed\b|\bFAILED\b|Traceback \(most recent call last\)|AssertionError|"
                        r"\bexit code [1-9]\d*\b|\bSyntaxError\b|[A-Za-z]Error:")

...

도구 사용 라운드(round)가 끝날 때마다, _round_failed는 도구가 에러를 반환했거나 출력에 "2 failed", 트레이스백 또는 0이 아닌 종료 코드가 포함된 경우 참(true)입니다.

주요 작업 외의 서비스 호출 사고 과정 (Service calls thought more than the main ones)

로그에서 두 군데가 더 발견되었습니다.

채팅 제목. 에이전트는 첫 번째 메시지로부터 모델에게 제목을 요청합니다. 그 답변의 약 95%는 추론(reasoning)에 관한 것이었습니다: 다섯 단어짜리 제목에 대해 약 190 토큰의 "사고 과정(thoughts)"이 사용되었습니다. 추론 기능을 끄면 답변은 12 토큰이며 속도가 1.6~3배 빠르고, 여섯 개의 샘플 제목 모두 여전히 괜찮았습니다.

히스토리 요약. 컨텍스트가 커질 때, 에이전트는 모델에게 대화의 시작 부분을 압축하도록 요청합니다. 답변 제한은 600 토큰이었습니다. 모델은 이 토큰들을 추론에 사용했고 요약본은 4건 중 3건에서 비어 있었습니다 (finish_reason: length). 빈 요약본은 누락(fold)이 아니라 손실(loss)입니다. 에이전트는 내용을 압축하는 대신 대화의 시작 부분을 버립니다. 제한을 2,000으로 늘리자 빈 요약본은 발생하지 않았습니다.

서비스 호출은 이제 최소한의 추론을 요청하며, 요약 제한은 2,500입니다.

이것이 해결하지 못하는 것들

• 단일 모델. 모든 측정은 glm-5.3-flash를 기준으로 이루어졌습니다. 다른 모델들은 수준(level)을 다르게 확장하므로, "낮음"의 의미가 다를 수 있습니다. 원칙—제공자에게 수준 결정권을 맡기지 말 것—은 유효하지만, 정확한 수치는 그렇지 않습니다.
• 소규모 샘플. 설정당 12~18회 실행입니다. 해결된 작업이 한두 개 차이 나는 것은 노이즈일 수 있습니다. 비용과 시간에서 3배의 차이는 아닙니다.
• 모든 제공자가 수준을 갖춘 것은 아니다. Z.ai 스타일 게이트웨이는 단순히 켜짐(on) 또는 꺼짐(off)만 알고 있습니다. "실패 후 높은 수준"이라는 것은 "충분히 깊이 생각하라"는 의미이며, 이는 비용이 많이 듭니다. 저희의 작업에서 이 게이트웨이를 사용했을 때 "항상 꺼짐"으로 설정한 것이 적응형(adaptive) 방식보다 절반 가격이었습니다 (12개 중 12개 모두, 5.9 대 10.8만). 비용이 가장 중요하다면 그곳에서는 "낮음"을 선택하세요.
• 작업 자체가 코드이다. 글쓰기, 검색 또는 분석의 경우 최적의 수준은 다를 수 있습니다.

직접 확인해 보기

실험의 핵심은 특정 수준(set level)으로 설정된 단일 에이전트 실행입니다:

# proxy.py는 모든 에이전트 요청에 제공자에게 수준을 추가합니다.
body = {**{"reasoning": {"effort": "low"}}, **request_body, "model": provider["model"]}
# stand.py: 에이전트가 작업을 해결한 후, 숨겨진 테스트가 실행됩니다.
...

전체 스탠드(로깅 프록시, 숨겨진 테스트 및 참조 솔루션이 포함된 작업, 요약 스크립트)와 원본 결과는 다음과 같습니다: research/agent-lab-2026-10 (python lab/facts.py를 실행하면 이 게시물에 있는 모든 숫자가 저장된 결과로부터 재계산되므로, 키가 필요하지 않습니다). Altair의 코드는 **https://github.com/Qweezyy/AltairAgent**입니다 — 수준은 Settings → Agent → Reasoning level (기본값 "Adaptive")에 있으며, .env 파일의 LLM_REASONING 모듈 pc/core/llm/reliability.py에서 확인할 수 있습니다.

사용하는 에이전트에서 추론 수준을 어떻게 설정하시나요 — 고정적으로, 작업 유형별로, 아니면 진행됨에 따라가요? 아무런 수준도 설정하지 않았을 때 모델이 필요 이상으로 깊게 생각하는 것을 본 적이 있습니까?