OpenRouter Activity Dashboard 사용법: 비용 추적, CSV 내보내기, Analytics API 주의점

모델 하나가 조직 평균 비용의 25배를 쓰고 있다면, 알아채기까지 몇 달을 기다릴 이유는 없다. OpenRouter는 2026년 8월 17일, 자사 프리뷰 모델 하나가 월 약 $6.2K를 조용히 소진하고 있었다고 공개했다. 비용의 98%는 단일 배치 파이프라인 API 키에서 발생했다. 같은 날 출시된 Activity dashboard는 이런 문제를 몇 달이 아니라 몇 분 안에 드러내기 위한 도구다. UI에서는 지출, 토큰, 캐시 적중률, 요청 단위 상세 내역을 한곳에서 확인할 수 있다. 다만 그 아래의 베타 Analytics API는 다소 거칠며, 이 글에서 그 주의점을 짚어본다.

월 $6.2K가 새는 방식: Activity Dashboard가 포착하는 문제

출시 공지에 담긴 내부 사례는 이 도구가 겨냥한 실패 패턴을 정확히 보여준다. 한 프리뷰 모델은 한 달 동안 250M 토큰에 $6,185를 사용했다. 백만 토큰당 약 $24.7, 캐시 적중률은 7.6%였다. API 키 기준으로 파고들자 batch-pipeline 키 하나가 127M 토큰, 37,000건의 요청에서 $6,067를 차지한 것으로 나타났다. 대량·저복잡도 배치 작업에 백만 토큰당 약 $48를 쓰고 있었던 셈이다. 해결은 모델을 한 줄 바꾸는 일이었다(비용 제어 cookbook의 전체 분석 참고).

OpenRouter Activity dashboard announcement page

대시보드와 함께 제공된 기능은 다음과 같다. 맞춤형 쿼리를 만드는 Explore, 변화 감지용 Trends, 프롬프트 인젝션 및 민감 데이터 이벤트를 위한 Guardrails, 요청 단위 로그, 베타 Analytics API, 그리고 코딩 에이전트에 설치할 수 있는 GitHub의 openrouter-analytics skill이다.

Activity 탭별로 답하는 질문

OpenRouter Activity 대시보드는 메뉴가 아니라 질문 중심으로 구성돼 있다. 비용을 추적할 때는 세 탭이 핵심이며, 각각 보는 관점이 다르다.

Overview: 지금 얼마나 쓰고 있나

Overview에는 총지출, 요청 수, 토큰 사용량, 캐시 적중률, 백만 토큰당 혼합 비용이라는 다섯 가지 핵심 지표가 먼저 표시된다. 각 지표에는 스파크라인과 이전 기간 대비 수치도 붙는다. 아래에서는 주요 사용자와 앱, 모델별 지출, OpenRouter 크레딧과 추정 BYOK 비용의 비중, 프롬프트·완료 토큰 수를 확인할 수 있다. 비용 총액 자체가 궁금할 때 계속 열어둘 탭이다.

Trends: 지난 기간과 비교해 무엇이 달라졌나

Trends는 절대 금액보다 변화폭을 기준으로 모델, 사용자, API 키, 앱을 정렬한다. 통제 불능 상태로 비용을 쓰기 시작한 에이전트, 갑자기 인기를 얻은 모델, 실험용이던 내부 도구가 기본값이 된 상황을 잡는 데 맞춰져 있다. Overview가 비싼 대상을 보여준다면, Trends는 언제부터 비싸졌는지를 알려준다.

Explore: 원하는 기준으로 직접 분석하기

Explore는 쿼리 빌더다. 지출, 요청 수, 여러 토큰 카테고리, 캐시 적중률, 백만 토큰당 혼합 비용, BYOK·크레딧별 지출뿐 아니라 P50/P90/P99 지연 시간과 처리량까지 지표로 선택할 수 있다.

그룹화는 모델, 제공자, API 키, 앱, 사용자, 워크스페이스, 국가, 지역, 컨텍스트 길이, 세션, 생성, 커스텀 ID, 분류기 중 최대 두 차원까지 가능하다. 시간 집계 단위는 분부터 월까지 지원하며, 막대·선·점 차트로 렌더링할 수 있다. 차트는 개인용 또는 조직 전체용으로 저장 가능하다. 단, 세 번째 그룹화 차원은 즉시 거부된다. 또 로그의 프롬프트·완료 내용은 요청이 실행되기 전에 비공개 입출력 로깅을 켜둔 경우에만 표시된다.

API 없이 CSV 또는 PDF로 내보내기

회계팀이나 스프레드시트 작업에 API는 필요 없다. Activity 페이지에서는 코드 없이도 같은 집계 수치를 요약 또는 상세 보고서로 두 형식으로 내보낼 수 있다. 공식 내보내기 절차는 다섯 단계다.

Activity 페이지를 연다.
기간과 그룹화 기준(모델, API 키 또는 생성자)을 선택한다.
오른쪽 상단의 옵션 메뉴를 연다.
내보내기 선택하기를 누른다.
CSV 또는 PDF를 선택한다.

기본 내보내기는 지출, 토큰, 요청을 함께 담은 요약 보고서다. 상세 보고서가 필요하다면 먼저 특정 지표 카드를 열고 내보내면 된다. 상세 버전은 선택한 그룹화 기준에 따라 해당 지표를 분해한다. 기간을 고르면 하위 시간 간격은 자동으로 정해진다.

시간 필터	하위 간격
1시간	분 단위
1일	시간 단위
1개월	일 단위
1년	월 단위

문서의 작은 글씨도 두 가지는 확인할 만하다. 이 보고서의 BYOK 비용은 제공자 시장 요율에 따른 추정치다. 제공자별 할인은 반영하지 않으므로 실제 외부 청구서와 다를 수 있다. 추론 토큰은 완료 토큰 비용에 포함돼 청구되지만 별도로 보고되므로, 이중 계산 없이 비용 중 ‘생각’에 해당하는 부분을 볼 수 있다.

5분 만에 시작하는 Analytics API 첫 쿼리

Analytics API는 Explore에서 계산하는 동일한 데이터를 두 엔드포인트로 제공한다. 명시적으로 베타 기능인 만큼, 쿼리부터 보내기보다 먼저 지원 항목을 조회하는 흐름이 맞다.

관리 키가 필요한 이유

Analytics 엔드포인트에는 관리 키가 필요하다. 일반 추론 키를 쓰면 HTTP 403이 반환된다. 비용 제어 cookbook에 따르면 반대도 성립한다. 관리 키는 모델 요청을 보낼 수 없으므로 유출 시 피해 범위는 제한되지만, 조직 전체의 지출 분석은 노출된다. cookbook의 조언은 단순하다. 다른 모든 자격 증명과 동일한 수준으로 관리해야 한다.

쿼리 전에 meta부터 조회

GET /api/v1/analytics/meta는 현재 지원하는 지표, 차원, 필터 연산자, 집계 단위를 반환한다. 베타 지원 범위는 바뀔 수 있으므로 자동화를 실행할 때마다 먼저 조회하는 편이 좋다. 실제 쿼리 엔드포인트는 POST /api/v1/analytics/query다. 문서에 있는 cURL 예시는 다음과 같다.

curl -X POST https://openrouter.ai/api/v1/analytics/query \
  -H "Authorization: Bearer <management-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "metrics": ["request_count"],
    "dimensions": ["model"],
    "granularity": "day",
    "limit": 100,
    "time_range": {
      "start": "2026-08-01T00:00:00Z",
      "end": "2026-08-08T00:00:00Z"
    }
  }'

응답 행은 data.data 아래에 들어가며, metadata 블록에는 query_time_ms, row_count, truncated가 담긴다. cookbook에는 단일 행 쿼리가 17ms에 끝난 사례가 있어 호출 자체의 부담은 작다. 이 워크플로는 읽기 전용이며 기존 사용 비용 외에는 무료라고 설명된다. 문서상 오류 코드는 400(잘못된 쿼리), 401(인증 없음), 403(잘못된 키 유형), 408, 500이다.

과소비를 찾는 쿼리 4가지

공식 cookbook은 다섯 가지 레시피를 제공한다. 이를 순서대로 적용하면 반복 가능한 비용 추적 절차가 된다.

1. 가장 많은 비용을 태우는 모델은 무엇인가? cookbook의 첫 쿼리는 total_usage, request_count, tokens_total, cache_hit_rate를 model별로 묶고 지출 기준으로 정렬한다.

{
  "metrics": ["total_usage", "request_count", "tokens_total", "cache_hit_rate"],
  "dimensions": ["model"],
  "order_by": { "metric": "total_usage", "direction": "desc" },
  "limit": 10,
  "time_range": { "start": "2026-07-01T00:00:00Z", "end": "2026-08-01T00:00:00Z" }
}

여기서 핵심 파생 지표는 실효 백만 토큰당 비용이다. 계산식은 total_usage / tokens_total × 1e6다. 이를 차원 없이 같은 식으로 계산한 혼합 비용과 비교하면 된다. cookbook의 기준처럼 혼합 비용보다 크게 높은 배수의 모델은 가장 먼저 조사할 신호다. 25배에 달한 프리뷰 모델 이상 징후도 이렇게 발견됐다.

2. 어느 API 키가 원인인가? 정확한 모델 슬러그로 필터를 추가한 뒤 api_key_id 기준으로 그룹화한다. 결과에서는 이름이 사람이 읽을 수 있는 라벨로 해석되므로, $6,185 문제 중 $6,067를 차지한 batch-pipeline를 식별할 수 있었다. 해석된 키 이름으로 필터링하지 말고 api_key_id로 그룹화해야 하며, 반환되는 user_email로 내부 기록과 비용을 대조할 수 있다.

3. 비용은 구체적으로 어디에 쓰였나? 일별 지출을 다음 구성 요소로 나눠본다.

지표	의미
`usage_upstream`	순수 추론 비용
`usage_cache`	캐싱 절감액 또는 캐시 쓰기 비용
`usage_data`	할인액, 대체로 음수
`usage_web`	웹 검색 추가 요금
`usage_file`	파일 처리 추가 요금

프롬프트 대 완료 토큰 비율이 약 20:1이면 지나치게 큰 컨텍스트를 의심할 신호다. 추론 토큰 비중이 높다면 필요하지 않은 ‘생각’에 비용을 지불하고 있을 수 있다. 가장 좋은 캐싱 대상은 프롬프트 비중이 높고 캐시 적중률이 낮은 트래픽이다. 이미 캐시 적중률이 높다면 모델 구성을 살펴보는 편이 낫다. 프롬프트 비중이 높은 것은 예외가 아니라 일반적 현상이다. OpenRouter 공개 프로그래밍 카테고리 데이터를 분석한 자료에서는 해당 토큰의 93.4%가 입력으로 측정됐다.

4. 수정이 실제로 효과가 있었나? 쿼리 1을 주간 시계열로 다시 실행하되 api_key_id별로 그룹화한다. 공식 사례에서 batch-pipeline 키의 주간 비용은 5월 31일 주의 $1,402.50에서 6월 7일 주의 $11.20로 떨어졌다. 성공적인 모델 교체는 완만한 하락이 아니라 절벽처럼 나타난다.

Weekly spend on the batch-pipeline key before and after the one-line model swap

쿼리 1 다음 단계가 더 저렴한 모델로의 전환이라면, 그 결정은 OpenRouter의 라우팅 계층에서 실행된다. 자동 라우팅과 고정 라우팅의 차이는 OpenRouter auto router guide에서 다뤘다.

레퍼런스에 잘 드러나지 않는 베타 API 주의점 6가지

쿼리 형식만 맞으면 API는 문서대로 동작한다. 다만 아래 실패 패턴도 문서화돼 있기는 하지만 cookbook의 각주에 흩어져 있다.

차원 세 개를 쓰면 400이 반환된다. 한도는 두 개다. model × key × day 분석에는 여러 쿼리 또는 시간 집계 단위가 필요하다.
group_limit가 시간 버킷을 조용히 잘라낼 수 있다. 지정하지 않으면 OpenRouter가 안전한 값을 자동 계산한다. 너무 낮게 설정하면 시계열에서 몇 주간의 데이터가 사라질 수 있다. 차원을 지정하지 않은 경우에는 아예 무시된다.
카운트 지표가 때때로 문자열로 반환된다. 레퍼런스에는 숫자로 표시되지만 API는 문자열을 반환할 수 있으므로 둘 다 파싱해야 한다.
시계열 컬럼 이름이 모호하다. 쿼리 형태에 따라 같은 버킷이 date__day 또는 created_at__day로 나타난다.
사용하지 않은 비용 구성 요소는 0이 아니라 null이다. 집계 스크립트에는 null 검사가 필요하다.
metadata.truncated: true는 합계가 일부만 반환됐다는 뜻이다. limit(기본값 1,000)를 높이거나 기간을 좁혀 다시 실행해야 한다.

대시보드, API, 자체 파이프라인 중 무엇을 쓸까

기본 도구는 계정 단위의 질문을 충분히 처리한다. 직접 구축이 의미를 갖는 것은 그 경계를 넘어설 때다.

필요한 것	권장 도구
지출, 토큰, 캐시 적중률을 한눈에 확인	Activity Overview
무엇이 변했고 어디서 급증하는지 확인	Trends
일회성 분석과 공유	Explore + CSV/PDF 내보내기
정기 보고서, 알림, 내부 대시보드	Analytics API
다중 제공자 집계, 사용자별 예산, 맞춤형 이상 탐지	사용량 로그와 웹훅 기반의 자체 파이프라인

자체 구축 사례도 드물지 않다. 한 r/FinOps 사용자는 이렇게 썼다.

"모델 가격이 하룻밤 사이 몇 센트에서 3€로 뛰어서 Obsidian에 AI 비용 추적기를 직접 만들었다."

해당 스레드와 r/openrouter의 "Long context pricing should be more transparent" 논의는 같은 원인을 가리킨다. 라우팅, 캐싱, 추론 토큰, 긴 컨텍스트 요금 때문에 로컬 추정치는 실제 청구 금액과 어긋난다. Activity dashboard에 기록된 사용량이 기준 수치다. 자체 시스템을 운영한다면 자체 가격표가 아니라 이 기록과 대조해야 한다.

플랫폼을 6개월 사용한 개발자가 공유한 가벼운 귀속 방법도 있다. 요청에 X-Title 헤더를 붙이면 앱이나 실험마다 Activity에 별도의 이름으로 기록된다. 이미 하나의 라우터가 아니라 여러 제공자에 지출이 분산돼 있다면, AIReiter 같은 통합 API 구성을 이용해 집계 문제 자체를 줄이는 방법도 있다.

FAQ

Activity dashboard를 쓰려면 관리 키가 필요한가?

아니다. 대시보드는 일반 계정 로그인으로 사용하는 UI 기능이다. 관리 키는 Analytics API 엔드포인트(/api/v1/analytics/meta, /api/v1/analytics/query)에서만 필요하다.

OpenRouter Analytics API 호출은 무료인가?

cookbook은 분석 워크플로를 읽기 전용이자 무료로 설명한다. 호출당 비용을 내는 것이 아니라 자신의 사용 기록을 조회하는 방식이다. 다만 그 기록에 담긴 추론 사용 비용은 그대로 지불한다.

OpenRouter 활동 데이터는 얼마나 오래 보관되나?

기존 /api/v1/activity 엔드포인트는 이전 30개의 완료된 UTC 날짜를 제공한다. 새 Analytics API 문서에는 보관 한도가 명시돼 있지 않으며, 예시 쿼리는 한 달 범위를 사용한다. 따라서 장기 이력은 확인되지 않은 것으로 보고, 보관해야 할 데이터는 CSV로 내보내 두는 편이 좋다.

Activity 로그에서 프롬프트와 응답을 볼 수 없는 이유는?

프롬프트와 완료 세부 내용은 요청 시점에 비공개 입출력 로깅을 활성화한 요청에만 존재한다. 출시 공지도 이를 명확히 밝힌다. 설정하지 않았다면 과거 프롬프트 내용은 볼 수 없다. 사용량 합계는 기록되지만, 콘텐츠 기록은 옵트인이다.

베타 API를 운영에 넣기 전에 계산할 점

지금 소개한 기능은 모두 바로 활용할 수 있으며, 쿼리 1만으로도 5분 설정의 가치는 충분하다. 남는 위험은 변화다. 이 기능은 베타로 표시돼 있고 지원 지표와 차원은 달라질 수 있다. OpenRouter도 자동화에서 스키마를 신뢰하기 전에 /meta를 다시 읽으라고 안내한다. 필드 이름을 하드코딩하는 대신 cron 작업에 meta 검사를 넣어두면, API가 성장하는 동안에도 대시보드의 가시성을 유지할 수 있다.

함께 읽기: OpenRouter auto router guide · Best free OpenRouter models for programming · OpenRouter pricing guide