openrouter/auto가 실제로 어떤 모델을 실행했는지, 그리고 비용은 얼마인지 파악하는 방법

만약 openrouter/auto를 통해 OpenRouter로 라우팅한다면, 당신은 결정을 편리함과 맞바꾼 것입니다. 라우터는 가격, 지연 시간(latency), 가용성을 기반으로 요청당 모델을 선택하며, 대부분의 경우 잘 선택합니다. 문제는 그 "대부분의 경우"라는 문구에 많은 의미가 담겨 있다는 점이며, 직접 찾아보기 전까지는 특정 요청을 어떤 모델이 처리했는지 알 수 없다는 것입니다.

이것은 이전보다 더 중요해졌습니다. OpenClaw와 같은 에이전트(Agents)와 점점 늘어나는 내부 도구들은 모델을 하드코딩하고 싶지 않기 때문에 정확히 auto를 기본값으로 사용합니다. 이는 합리적입니다. 하지만 이는 단일 에이전트 루프가 오후 시간 동안 토큰당 가격이 각기 다른 3~4개의 서로 다른 모델로 퍼져나갈 수 있음을 의미하며, 당신이 얻을 수 있는 유일한 신호는 월말에 나오는 합계 청구서뿐입니다. 청구 금액이 예상과 다를 때, "어떤 개발자가, 어떤 요청에, 어떤 모델을 사용했는지"에 대한 상세 내역이 바로 당신에게 결여되어 있는 정보입니다.

아무것도 재설계하지 않고 이 정보를 다시 확보하는 방법은 다음과 같습니다.

데이터는 이미 존재합니다

OpenRouter는 auto를 요청했을 때조차 모든 완료(completion) 시점에 선택된 모델을 기록합니다. 이를 확인하기 위해 트래픽을 가로챌 필요는 없습니다. 플랫폼은 두 가지 방식으로 이를 노출합니다.

첫 번째는 생성 시점의 요청별(per-request) 확인 방식입니다. 채팅 완료(chat completion) 응답에는 openrouter/auto가 아닌, 실제로 결정된 anthropic/claude-... 또는 google/gemini-... 문자열이 포함된 구체적인 모델 정보가 model 필드에 포함됩니다. 호출 지점(call site)을 제어할 수 있다면, 생성 id와 함께 해당 필드를 로그로 남기세요:

resp = client.chat.completions.create(
    model="openrouter/auto",
    messages=messages,
...

두 번째는 사후 확인 방식이며, 이는 확장성이 높습니다. OpenRouter에는 결정된 모델, 토큰 수, 행당 비용이 포함된 과거 생성 기록을 반환하는 활동/사용량(activity/usage) 엔드포인트가 있습니다. 해당 엔드포인트를 정기적으로 폴링(polling)하면 애플리케이션 코드를 전혀 건드리지 않고도 완전한 원장을 얻을 수 있습니다:

curl https://openrouter.ai/api/v1/activity \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

특정 로그 라인을 보강하고 싶다면, generation 엔드포인트에서 id를 통해 단일 생성(generation) 정보를 가져올 수도 있습니다. 데이터의 형태(shape)는 다양하므로, 이를 기반으로 구축하기 전에 정확한 필드 이름을 확인하려면 현재 OpenRouter 문서를 참조하세요. 하지만 결정된 모델(resolved model)과 비용(cost)은 모두 그 안에 포함되어 있습니다.

행(rows)을 모델별, 개발자별 진실로 전환하기

가공되지 않은 생성 행(raw generation rows) 자체는 정답이 아닙니다. 핵심은 그룹화(grouping)에 있으며, 그룹화의 품질은 키 위생(key hygiene) 상태에 달려 있습니다.

가장 유용한 방법은 모든 개발자(및 모든 에이전트)에게 각자의 OpenRouter API 키를 부여하는 것입니다. 이는 보안을 위한 형식적인 조치가 아니라, 귀속(attribution)을 위한 것입니다. 만약 모든 사람이 하나의 키를 공유한다면, 사용량(usage) 엔드포인트는 누가 발생시켰는지 알 수 없는 생성 기록의 더미를 던져줄 뿐입니다. 신원당 하나의 키를 부여하면 익명의 스트림이 GROUP BY가 가능한 행(rows)으로 변합니다.

이 체계가 갖춰지면, 일일 폴링(daily poll)과 몇 줄의 집계(aggregation)만으로 여러분이 실제로 원하는 테이블을 얻을 수 있습니다:

from collections import defaultdict

rows = fetch_activity()  # 생성 기록 리스트
...

이제 auto는 더 이상 블랙박스가 아닙니다. 지난 화요일, 다른 모든 사용자가 저렴한 티어(cheap tier)를 유지하는 동안 특정 개발자의 에이전트가 호출의 80%에서 조용히 비싼 모델로 결정(resolved)되었음을 확인할 수 있습니다. 이것이 바로 발견(finding)입니다. 귀속할 수 없는 숫자에 대해서는 조치를 취할 수 없습니다.

최악의 상황을 포착하기 위한 임계값(threshold) 설정하기

원장(ledger)은 무슨 일이 일어났는지를 알려줍니다. 폭주하는 에이전트를 당일에 잡아내려면 트리거(tripwire)가 필요하며, 가장 저렴하고 유용한 방법은 개발자별 기준선(per-developer baseline)을 설정하는 것입니다.

각 개발자의 최근 일정 기간(trailing window) 동안의 일일 평균 지출액과 표준 편차(standard deviation)를 계산하세요. 2~3주 정도면 충분합니다. 그런 다음 평균 + 3σ를 초과하는 날을 플래그(flag)로 표시합니다. 3시그마(3σ)는 의도적으로 보수적인 기준입니다. 이는 일반적인 변동성은 무시하고, 정말로 문제가 발생했을 때만 경보를 울립니다. 이것이 바로 실제로 계속 활성화해 둘 만한 알림이 갖춰야 할 조건입니다. 백오프(backoff) 없는 재시도 루프(retry loop), 동일한 200KB 파일을 계속해서 다시 읽고 있는 에이전트(agent), 누군가 점심시간 동안 켜두고 간 테스트 하네스(test harness) 등은 서서히 증가하는 것이 아니라 급증(spike)합니다. 개발자별 기준선에 설정된 3σ 대역은 이러한 상황을 다음 달 정산 시점이 아닌, 사건이 발생한 당일에 즉시 포착합니다.

이 체크 로직을 일일 폴링(daily poll)에 연결하고, 초과 사항을 사람들이 확인하는 곳에 게시하세요. 이 전체 과정은 코드 40줄 정도와 크론(cron) 엔트리 하나면 충분합니다.

여기서 폴링(polling)이 프록시(proxy)보다 나은 이유

흔히 하는 직관적인 생각은 OpenRouter 앞에 게이트웨이(gateway)를 두어 모든 것을 볼 수 있게 하는 것입니다. 특히 비용 가시성(cost visibility)만을 위해서라면, 이는 필요 이상의 과한 작업입니다. 프록시를 도입하면 그것이 크리티컬 패스(critical path)에 포함됩니다. 즉, 지연 시간(latency)을 추가할 수 있고, 프록시가 다운되면 추론(inference) 서비스도 함께 중단될 수 있으며, 개발자가 보내는 모든 프롬프트(prompt)와 완성문(completion)을 보게 됩니다. 이는 저장하고 보안을 유지해야 할 데이터의 범위를 의미 있게 확장하는 일입니다. 반면 사용량 API(usage API)는 이러한 노출 없이도 사후에 동일한 비용 및 모델 데이터를 읽기 전용(read-only)으로 제공합니다. 질문이 "우리가 얼마를 썼고 어떤 모델에 썼는가"라면, 그 질문에 답하기 위해 대화의 중간에 서 있을 필요는 없습니다.

이것이 전체적인 접근 방식입니다. 신원(identity)당 하나의 키를 사용하고, 사용량 엔드포인트(usage endpoint)를 폴링하며, 모델과 개발자별로 그룹화한 뒤, 각 기준선에 3σ 트리프와이어(tripwire)를 설정하는 것입니다. 이는 조용한 오후 시간 정도의 작업량이며, auto가 예상치 못한 고비용 작업을 수행하는 첫 순간에 그 가치를 충분히 증명할 것입니다.

만약 폴러(poller), 키(keys), 그리고 알림(alerting) 시스템을 직접 관리하고 싶지 않다면, 그것이 바로 우리가 Reckon을 만든 이유입니다. Reckon은 읽기 전용 사용량 API 폴링(usage-API polling, 프록시나 SDK를 사용하지 않으며 사용자의 프롬프트를 절대 볼 수 없음), KMS로 암호화된 키, 개발자별 및 이제는 모델별 OpenRouter 가시성을 실시간으로 제공하며, 당일 이상 징후 알림이 포함된 Slack 요약(Slack digests), /spend 명령어, 그리고 Linear 연동 기능을 제공합니다. 개발자 3명까지는 무료이며, Pro 플랜은 개발자 1명당 월 $19입니다. 직접 구축하든 아니든 간에, 이러한 가시성은 절약되는 비용보다 더 큰 가치를 제공할 것입니다.