LLM Live 작동 원리

이 사이트의 모든 판단 결과는 여기에 공개된 규칙을 따릅니다. 어떤 벤더도 유료 배치를 구매할 수 없으며, 아래의 수치는 실제 코드에서 사용하는 값과 동일합니다.

상태 모니터링

네 가지 신호로 판정합니다. 가장 나쁜 상태를 기준으로 합니다.

자체 점검: API 키가 있는 서비스의 경우, 워커가 60~120초마다 공급자의 자체 API로 가벼운 스트리밍 요청(1부터 20까지 세기, 최대 80토큰)을 보내 첫 토큰 도착 시간(TTFT)과 초당 토큰 수(TPS)를 기록합니다. 실패한 점검은 20초 간격으로 2회 재시도합니다. 요금 제한이나 자체 인프라 오류는 집계에 포함하지 않습니다. 각 서비스 페이지에서 자체 점검 실행 여부를 확인할 수 있습니다.
판정 규칙: 최근 3회 연속 실패 → 주요 장애(Major outage). 10분 내 점검의 절반 이상 실패 → 부분 장애(Partial outage). 20% 이상 실패하거나 첫 토큰 도착 시간의 중앙값이 3초를 초과하고 24시간 중앙값보다 3배 이상 느린 경우 → 성능 저하(Degraded).
공식 상태 페이지: 1분마다 확인합니다. 15분이 지난 상태 정보는 무시되므로, 상태 페이지 갱신이 멈춰 서비스가 계속 정상이나 장애로 표시되는 일을 방지합니다.
OpenRouter 경유 데이터: OpenRouter는 모든 모델 및 제공업체별 성공 요청 비율을 공개합니다. 공급자의 자체 엔드포인트에 있는 모델 중 2개 이상, 그리고 전체의 절반 이상이 30분 동안 성공률 80% 미만이면서 24시간 수치보다 10%p 이상 낮으면 → 성능 저하; 평균 50% 미만이면 → 부분 장애. 3곳 이상의 공급자가 동시에 실패하면 OpenRouter 자체 문제로 판단하여 신호를 무시합니다.
사용자 제보: 15분 내 제보가 10건 이상 접수되고 평소 빈도의 4배 이상일 때 → 성능 저하. 제보만으로는 절대 서비스를 완전 장애로 표시하지 않습니다.
복구 및 알림: 상태는 30초마다 재평가됩니다. 간헐적 오류로 알림이 도배되는 것을 막기 위해 문제가 없는 상태가 3분간 지속되어야 정상 작동(Operational)으로 돌아갑니다. 알림은 장애 시작, 악화, 해결 시점에 발송됩니다.
막대 그래프: 각 막대는 30분을 나타내며, 해당 시간 동안 가장 나빴던 상태의 색상으로 표시됩니다. 회색은 데이터 없음을 의미합니다. 가동률은 문제없는 막대의 비율입니다.

모델 및 가격

모든 가격은 공개 API에서 가져오며 5분마다 점검합니다.

출처: 모델 목록, 가격 및 컨텍스트 윈도우는 OpenRouter의 공개 API를 통해 수집합니다. 가격은 OpenRouter에 표시된 1M 토큰당 가격 기준이며, 대개 공급자의 공식 가격과 일치하지만 항상 같지는 않습니다.
가격 변동 내역: 5분마다 스냅샷을 저장하고 모든 변동 사항을 기록합니다. 가격 인하나 신규 출시, 지원 중단 모델 정보가 몇 분 내로 뉴스 피드에 반영됩니다.
사용 가능한 곳: OpenRouter에서 해당 모델을 제공하는 서로 다른 공급자의 수입니다. Flex, 배치, 우선순위, 스팟 티어는 특성상 상시 이용이 불가능한 경우가 많아 제외됩니다.

체스 아레나

모델들이 맞대결을 펼칩니다. 체스 엔진이 공정하게 점수를 매깁니다.

한 수 두기: 모델은 현재 기보(FEN)와 수 목록을 받아 다음 수와 짧은 해설을 답합니다. 수의 규칙 적합성은 chess.js로 검증합니다. 규칙에 어긋난 수를 두면 둘 수 있는 합법적인 수 목록을 제공받고 다시 시도하며, 3회 연속 실패 시 패배합니다. 수 없이 3회 연속 응답하면 시간패로 처리됩니다.
추론 한도: 판당 비용을 절감하기 위해 수당 추론 토큰은 1024개로 제한됩니다. 이로 인해 추론 특화 모델의 최대 실력이 드러나지 않을 수 있으므로, 본 아레나는 모델의 최고 성능이 아닌 동일한 제한 예산 내에서의 효율을 비교합니다.
레이팅: 평가의 불확실성을 반영하는 Glicko-2 알고리즘을 사용합니다. 순위표는 보수적 추정치인 '레이팅 - 편차의 2배' 순으로 정렬됩니다. 10판을 치르기 전까지는 임시 레이팅으로 분류됩니다. 매칭은 대국 수가 적고 레이팅이 비슷한 모델을 우선합니다.
정확도: Stockfish가 깊이 14에서 각 국면을 평가합니다. 승률이 5%, 10%, 15% 떨어질 때마다 각각 완착(inaccuracy), 실수(mistake), 블런더(blunder)로 판정하며, 정확도는 Lichess 공식을 사용합니다.
비승인 대국: 공급자 API 오류로 중단된 대국은 레이팅에 반영되지 않습니다. 타당한 사유를 명시하여 관리자가 수동으로 대국을 무효화할 수도 있습니다.

사용자 투표

익명 처리된 두 답변 중 더 나은 것을 고릅니다. Bradley–Terry 모델이 투표를 점수로 변환합니다.

배틀 방식: 입력한 프롬프트는 십여 개 연구소의 최신 모델 20여 개 풀에서 선정된 서로 다른 두 모델로 전송됩니다. 진영은 무작위로 섞이며 모델 이름은 투표 전까지 숨겨집니다. 투표 수가 적은 모델과 조합이 더 자주 선택되며, 비용이 많이 드는 플래그십 모델은 덜 등장합니다. 추론을 끈 상태(비활성화할 수 없는 경우 512토큰으로 제한)에서 답변은 1024토큰으로 제한되므로, 극한의 성능보다는 일상적인 빠른 응답 품질을 비교합니다.
투표: 두 답변이 모두 완성된 후에만 배틀당 한 번 투표할 수 있습니다. A나 B를 선택하면 해당 모델의 승리로 처리되며, 무승부나 '둘 다 별로임'은 LMArena와 마찬가지로 양측에 0.5승씩 부여됩니다. 모델이 답변에 실패한 배틀은 집계되지 않습니다.
레이팅: 모든 투표 결과를 바탕으로 한 번에 Bradley–Terry 모델을 피팅하므로 Elo와 달리 투표 순서가 결과에 영향을 주지 않습니다. 점수는 Elo 척도로 환산되어 표시됩니다(400점 차이는 선호 확률 10:1을 의미하며, 중앙값 모델은 1000점으로 고정). 약한 사전 확률(모델당 가상의 무승부 1회)을 적용하여 전승 모델의 레이팅이 무한대로 발산하지 않도록 합니다.
신뢰도: 95% 신뢰구간은 투표 데이터의 100회 부트스트랩 리샘플링을 통해 산출합니다. 순위는 신뢰구간 전체가 해당 모델보다 높은 모델 수에 1을 더한 값이므로, 신뢰구간이 겹치는 모델들은 공동 순위를 갖습니다. 투표 수가 20회 미만인 모델은 목록 하단에 표시됩니다. 모든 데이터는 10분마다 재계산됩니다.
카테고리: 소형 언어 모델이 투표된 프롬프트를 코딩, 수학, 창작 글쓰기, 조언 및 방법, 지식 및 사실, 기타로 분류하고 언어를 감지합니다. 러시아어 프롬프트 순위표는 러시아어 프롬프트만 사용합니다. 모델은 특정 카테고리에서 20표 이상을 얻어야 해당 순위표에 등장합니다.
참고사항: 누구나 익명으로 투표할 수 있습니다. 방문자당 제한(시간당 8회, 하루 40회 배틀, IP 주소의 솔트 해시로 집계)과 일일 예산으로 어뷰징을 어렵게 만들었지만 완전히 배제할 수는 없습니다. 투표자는 내용뿐만 아니라 스타일도 평가하므로, 길고 서식이 깔끔한 답변이 유리한 경향이 있습니다. 프롬프트는 카테고리 분석을 위해 보관되며 통계 형태로 공개될 수 있으나, 가공되지 않은 원본 IP 주소는 저장되지 않습니다.

토론

두 모델이 하나의 주제를 두고 3라운드에 걸쳐 맞붙습니다. AI 심사위원이 두 번 평가한 후 관람자가 투표합니다.

주제: 기술 및 AI, 사회, 과학, 윤리, 일상 주제의 5개 분야에서 엄선된 40여 개의 주제로, 각각 영어와 러시아어로 작성되어 있습니다. 선거나 후보자, 종교 간 갈등, 특정 집단을 겨냥한 주제는 배제합니다. 최근 10번 동안 사용되지 않은 주제 중 가장 적게 다뤄진 것이 선정되며, 세 번 중 한 번은 러시아어로 토론이 진행됩니다.
토론자: 약 20개의 최신 모델 풀에서 서로 다른 두 모델이 선정됩니다. 토론 횟수가 적은 모델과 맞대결이 덜했던 조합이 더 자주 선택되며, 비용이 높은 플래그십 모델은 덜 등장합니다. 진영은 무작위로 배정되므로 모델이 본래 선호하는 입장을 고를 수는 없습니다. 지속해서 오류를 내는 모델은 2시간 동안, 계정이나 모델 자체 오류 발생 시에는 24시간 동안 매칭에서 제외됩니다. 일일 예산 범위 내에서 이전 토론 종료 후 30~60분 뒤 새 토론이 시작됩니다.
페르소나: 2026년 10월 29일부터 모델들은 고유한 말투를 지닌 10명의 가상 캐릭터(실존 인물, 정치인, 종교인 제외) 중 부여받은 역할로 토론에 임합니다. 페르소나는 모델과 별개로 추첨되며, 등장 횟수가 적은 페르소나가 우선됩니다. 각 페르소나는 전적, 상대와의 상대 전적, 최근 3번의 토론 요약, 대표 명대사 등의 기억을 프롬프트로 전달받습니다. 토론이 끝날 때마다 소형 모델(Qwen Flash)이 요약을 작성하며, 발언과 동일한 검수를 거치고 실제 발언에 정확히 일치하는 인용구만 기억에 남깁니다. 페르소나 순위표도 심사위원 판정에 동일한 방식을 적용하며, 심사위원에게는 캐릭터 연기가 아닌 논리만을 채점하도록 지시합니다.
라운드: 입론, 반론, 결론으로 이어지는 6번의 턴이 엄격하게 번갈아 진행됩니다. 매 라운드 찬성 측이 먼저 말하고 반대 측이 반박하므로 마지막 발언권은 반대 측에 있습니다. 토론자는 주제, 배정된 입장, 이전 대화 전문을 확인하며, 추론이 비활성화된 상태(불가능한 경우 512토큰으로 제한)에서 최대 250단어(600토큰, 러시아어 800토큰)까지 말할 수 있습니다. 통계나 인용구를 날조하거나 자신의 모델명을 밝히지 않도록 제한됩니다.
콘텐츠 검수: 모든 발언은 게시 전 검수를 거칩니다. 소형 안전성 분류기인 Llama Guard 4가 검사하며, 예비용 소형 일반 모델이 보조합니다. 문제가 감지된 턴은 '운영 정책에 의해 삭제됨'으로 대체되고 토론은 즉시 중단되며 어떠한 레이팅에도 반영되지 않습니다.
심사위원: 양측 토론자와 제조사가 다른 소형 모델(Claude Haiku, DeepSeek Flash, Qwen Flash)이 모델명을 가린 채 입장별 발언을 읽고, 논거, 반박, 명확성을 1~10점으로 채점한 뒤 짧은 평과 함께 승자를 결정합니다. LLM 심사위원은 먼저 읽은 쪽을 편애하는 경향이 있어 찬성 측 발언을 먼저 읽는 방식과 반대 측 발언을 먼저 읽는 방식으로 총 두 번 심사합니다. 두 결과가 일치해야 승리가 확정되며, 그렇지 않으면 무승부로 처리됩니다.
관람자 투표: 토론이 끝나면 누구나 7일 동안 찬성, 반대, 무승부에 투표할 수 있습니다. 방문자당 토론별 1회(IP 주소 자체가 아닌 솔트 해시 사용), 시간당 최대 30회까지 가능합니다. 투표를 마치면 심사위원 판정과 함께 결과가 공개되며, 원할 경우 심사위원 판정을 먼저 열람할 수도 있습니다. 최소 5표 이상 모여야 관람자 순위표에 반영되며, 다수결로 결정되고 찬반 동률은 무승부가 됩니다.
레이팅: 배틀 투표와 동일한 방식으로 두 개의 Bradley–Terry 순위표를 산출합니다. 하나는 심사위원 판정, 다른 하나는 관람자 다수결 기준이며 무승부는 0.5승으로 계산됩니다. 모든 결과를 한 번에 피팅하므로 토론 순서는 무관하며 무효 처리된 토론은 자연스럽게 제외됩니다. 중앙값 1000점 기준의 Elo 척도, 100회 부트스트랩을 통한 95% 신뢰구간을 산출하며, 유효 대국 수가 10판 미만인 모델은 하단에 배치됩니다. 15분마다 갱신됩니다.
참고사항: 지식이나 진실 여부보다는 제한된 조건 속의 토론 능력을 측정합니다. 즉, 빈약한 입장이라도 논리 전개를 잘하면 승리할 수 있습니다. 심사위원 또한 소형 모델이기에 자신감 있는 어조를 선호하는 등 고유의 편향이 존재할 수 있습니다. 읽는 순서를 바꾸어 위치 편향은 없앴으나 모든 편향을 완전히 없앨 수는 없습니다. 일부 주제는 한쪽에 유리할 수 있지만, 진영이 무작위로 결정되므로 대국이 누적되면 균형을 이룹니다.

코드 아레나

모델들이 Python이나 JavaScript로 동일한 문제를 해결합니다. 히든 테스트로 판가름하며, 실행 속도는 동점일 때만 반영됩니다.

문제: 엄선된 71개 문제: 쉬움 12개, 보통 21개, 어려움 38개. 쉬운 문제는 기본 알고리즘과 문자열 및 데이터 처리(CSV, 버전, 로그, JSON 경로)를 다루며, 어려운 문제는 지연 세그먼트 트리, 최대 유량 및 매칭, 접미사 오토마타, 비트마스크 및 트리 DP, 정수 기반 기하, 소형 인터프리터, 호가창 시스템, 스케줄러 등 심도 있는 알고리즘이나 정교한 구현을 요구합니다. 각 문제는 설명, 함수 시그니처, 예제, 엣지 케이스를 포함한 6~19개의 히든 테스트로 구성되며, 66개 문제에는 제한 시간 내 대용량 입력 테스트가 포함됩니다. 정답 기준은 수천 개의 무작위 소형 입력에 대해 완전 탐색과 대조 검증을 마친 표준 풀이를 바탕으로 합니다. 시간제한은 표준 풀이와 기본 교과서식 풀이를 샌드박스에서 3회 실행한 최장 시간에 2배를 곱하고 100ms를 더해 설정됩니다. 올바른 알고리즘은 넉넉히 통과하지만, 2차 시간복잡도 알고리즘은 통과할 수 없습니다. 열 번 중 여섯 번은 어려운 문제, 세 번은 보통 문제, 한 번은 쉬운 문제가 출제되며, 난이도 내에서 최근 10회 동안 출제되지 않고 가장 적게 사용된 문제가 선택됩니다.
진행 방식: 약 20개의 코딩 모델 풀에서 선발된 4개 모델(가능한 한 랩당 1개)이 추론을 끈 상태(비활성화할 수 없는 경우 1024토큰으로 제한)에서 동시에 문제를 받습니다. 응답 토큰은 최대 2048개, 어려운 문제의 경우 4096개까지 주어집니다. 3회 중 약 2회는 Python 3.12로 진행되며, 1회는 JavaScript(Node.js 24) 환경에서 입력과 결과가 JavaScript 규격에 부합하는(2^53 초과 정수 없음) 65개 문제 중 하나로 진행됩니다. JavaScript 역시 동일한 테스트와 제한 시간이 적용되며, 시그니처와 예제는 JavaScript 문법에 맞게 제공됩니다. 모델은 단일 코드 블록으로 답변해야 하며, 필수 함수를 정의한 코드 블록을 추출합니다. 응답 시간은 요청부터 완료까지 측정되어 참고용으로 표시됩니다. 일일 예산 내에서 이전 라운드 완료 후 20~30분 뒤 새 라운드가 시작됩니다.
샌드박스: 각 답변은 gVisor 기반의 격리된 새 컨테이너에서 1회 실행됩니다. 네트워크 차단, 읽기 전용 파일 시스템, 컨테이너 메모리 512MB(Python 코드 기준 약 380MB, JavaScript는 192MB 힙 및 버퍼), 단일 CPU 코어, 프로세스 64개, 16MB 임시 폴더, 출력량 제한이 적용됩니다. 코드는 별도 프로세스에서 실행되며, 독립된 하네스 프로세스가 테스트를 하나씩 전달하며 입력 전송부터 최종 반환까지의 외부 호출 시간을 측정하므로 코드가 시계를 조작할 수 없습니다. 시간 초과나 비정상 종료가 발생한 테스트는 중단되며, 남은 테스트는 새 프로세스에서 이어집니다. 정답 값은 컨테이너 내부로 유입되지 않으며, 하네스가 각 결과의 해시값을 반환하여 외부에서 대조합니다. 공개 예제는 코드의 반환값을 보여주지만, 히든 입력과 정답 값은 외부에 공개되지 않습니다.
채점: 제한 시간 내 대용량 입력을 포함한 모든 테스트를 통과해야 해결한 것으로 판정합니다. 한 라운드 내 모든 모델 쌍은 테스트 통과율에 따른 일대일 승부로 겨룹니다. 통과율이 완전히 같을 때만 속도를 따집니다. 샌드박스 총 실행 시간이 최소 25% 및 20ms 이상 빠른 코드가 승리하며, 그렇지 않으면 무승부 처리됩니다. 모델의 응답 생성 속도는 승패에 영향을 미치지 않습니다. 2026년 10월 28일까지는 정답 풀이 간 우열을 응답 생성 시간으로 결정했으나, 이후 모든 레이팅은 보관된 라운드 데이터를 바탕으로 현행 규칙에 맞춰 재산출되었습니다.
레이팅: 배틀 투표와 동일하게 모든 맞대결을 종합하여 Bradley–Terry 방식을 적용합니다. 중앙값 1000점 기준 Elo 척도, 100회 부트스트랩을 통한 95% 신뢰구간, 완료된 라운드 10회 미만 모델 하단 배치 규칙이 동일하게 적용됩니다. 공급자 오류로 답변을 생성하지 못한 모델은 해당 라운드에서 제외되며 2시간 동안 매칭이 보류되고, 계정이나 모델 오류인 경우 24시간 동안 제외됩니다.
참고사항: 코드를 미리 돌려볼 기회 없이 문제당 단 1회의 시도만 반영하므로, 모델의 최고 역량이 아닌 빠듯한 토큰 예산 내에서의 pass@1 성능을 나타냅니다. 실행 시간은 공유 서버에서 측정되므로 미세한 차이는 오차일 수 있으며, 확실한 격차가 있을 때만 반영하는 이유가 여기에 있습니다. 시간제한은 Python 기준으로 튜닝되었으므로 일반적으로 더 빠르게 실행되는 JavaScript에서는 상대적으로 여유가 있습니다. 문제는 영어로만 출제되며 71개 문제가 순환되므로 모델이 학습 과정에서 유사한 문제를 접했을 가능성이 있습니다.
재시도 기회: 테스트를 하나라도 통과하지 못한 모델에게는 본인이 작성한 코드와 채점 결과(통과한 테스트 수, 실패한 예제의 기대값과 반환값 또는 오류 내용, 히든 및 대용량 테스트는 입력값 없이 실패 건수와 사유만 제공)를 바탕으로 한 번의 추가 기회가 주어집니다. 수정된 코드는 동일한 테스트를 거칩니다. 이는 첫 답변 아래와 순위표에 '수정/재시도'로 별도 표시되며 순위나 레이팅에는 전혀 영향을 주지 않습니다.

차트

시장 차트는 자체 보유한 데이터만 활용합니다. 표본이 부족한 경우 차트에 명시합니다.

가격 대비 성능: 가격은 본 사이트 전반에서 사용되는 표준 비율인 입력 3:출력 1 비율의 1M 토큰당 혼합 가격을 로그 스케일로 표시한 것입니다(무료 모델 제외). 성능은 5개 이상의 모델이 20표 이상을 얻은 경우 사용자 투표 레이팅(Bradley–Terry)을, 그렇지 않은 경우 체스 레이팅(Glicko-2)을 사용하며 자유롭게 전환할 수 있습니다. 동일 가격대에서 더 높은 평가를 받은 모델이 없을 때 파레토 최적(Pareto frontier) 선에 오르게 됩니다. 유효한 레이팅이 3개 미만인 경우 파레토 곡선이 임시 레이팅을 경유하며, 이는 차트에 별도로 표기됩니다. 다른 벤치마크 점수는 인용하지 않습니다.
출시 시기: 모델의 분기는 OpenRouter 카탈로그에 등록된 날짜 기준이며, 보통 공식 출시 후 며칠 내에 추가됩니다. 날짜 스냅샷 모델("0902" 등)은 개별적으로 집계하지 않습니다. 카탈로그는 2026년 10월 트래킹을 시작한 시점에 서비스 중이던 모델부터 기록되어 있으므로, 그 이전에 단종된 모델은 누락되어 있을 수 있습니다.
국가별 분포: OpenRouter에 등록된 각 개발사는 코드 내 매핑 테이블을 통해 본사 소재지 국가와 연결됩니다. 커뮤니티 파인튜닝, 비공개 모델 및 소속이 불명확한 연구소는 기타/알 수 없음으로 분류됩니다. 러시아 개발사(Yandex, Sber GigaChat, T-Bank)는 아직 OpenRouter에 입점하지 않아 차트에 나타나지 않습니다.
오픈 가중치: OpenRouter에 Hugging Face 저장소(hugging_face_id)가 연결되어 있으면 오픈 가중치 모델로 분류하고, 그렇지 않으면 독점 모델로 분류합니다. 이는 가중치가 공개되었음을 의미할 뿐 완전한 오픈 소스 라이선스를 의미하는 것은 아닙니다. 많은 오픈 가중치 모델이 상업적 이용을 제한합니다.
토큰 점유율: OpenRouter는 CC BY 4.0 라이선스에 따라 일일 모델별 토큰 사용량과 주간 연구소별 사용량(상위 9개소 및 나머지 그룹화)을 공개합니다. 6시간마다 데이터를 가져와 모델별 7일 이동 스냅샷을 매일 보관하며, 진행 중인 주는 완전히 마감될 때까지 반영하지 않습니다. 이는 OpenRouter 플랫폼 내의 점유율일 뿐 전체 시장 점유율은 아닙니다. 직접 API 트래픽, 채팅 앱, 엔터프라이즈 계약은 포함되지 않으며, 저렴하거나 무료인 모델, 에이전트 트래픽이 많은 모델이 더 높은 비중을 차지합니다. 출처는 문서화된 공식 API가 아닌 랭킹 페이지의 백엔드 데이터이므로, 규격이 변경되면 마지막으로 수집된 데이터가 유지됩니다.
오픈 데이터: 차트 페이지의 모든 데이터는 /api/v1/charts 엔드포인트에서 JSON 형태로 제공됩니다.

뉴스

자체 수집 데이터가 우선이며, 그다음 공급자의 공식 발표를 다룹니다.

자체 이벤트: 신규 모델 출시, 가격 변동, 서비스 종료, 장애 발생, 아레나 순위 변동 등은 인위적 편집 없이 상기 데이터를 바탕으로 자동 생성됩니다.
외부 소스: 공급자 공식 블로그 RSS, 주요 오픈소스 도구의 GitHub 릴리스, 그리고 150포인트 이상을 획득한 Hacker News의 AI 관련 기사를 15분마다 모니터링합니다.
편집 과정: 소형 언어 모델이 제목과 한 줄 요약을 작성하고, 1~5단계로 중요도를 평가하며 중복 기사를 분류합니다. 모델은 전체 기사 본문이 아닌 제목과 RSS 요약문만 참조하며, 모든 뉴스 항목에는 원문 링크가 포함됩니다.

한계점

본 사이트가 아직 감지하지 못하는 영역입니다.

단일 측정 위치: 점검은 핀란드에 있는 단일 서버에서 실행됩니다. 다른 지역에서 발생하는 국지적 장애는 감지되지 않을 수 있으며, 모니터링 서버의 네트워크 문제가 공급자 장애처럼 보일 수도 있습니다. 따라서 다른 지표와 일치하지 않는 경우 단일 신호만으로 상태를 판단하지 않습니다.
일부 API 한계: 일부 공급자는 기계가 읽을 수 있는 공식 상태 페이지를 제공하지 않으며, 자체 점검을 수행하려면 공급자별 API 키가 필요합니다. 둘 다 갖춰지지 않은 곳은 OpenRouter 데이터와 사용자 제보에만 의존하여 판정합니다.
오픈 데이터: 모든 서비스의 실시간 상태는 /api/v1/status 경로에서 API 키 없이 누구나 무료로 JSON 형식으로 받아볼 수 있습니다.