콤보: 페일오버와 로드 밸런싱

콤보는 정해진 순서로 나열된 실제 공급자/모델 대상 목록 앞에 서는 하나의 가상 모델입니다. 클라이언트는 combo/<id>로 요청하고, opencodex는 대상을 하나 선택해 요청을 그 구체적인 provider/model로 다시 쓰며, 첫 번째 대상이 재시도 가능한 실패를 내면 다른 대상을 시도할 수 있습니다.

이 방식은 다음 두 경우에 유용합니다.

페일오버: 하나의 모델을 우선 사용하되, 예비 모델도 준비해 둡니다.
로드 밸런싱: 성공한 요청을 여러 모델이나 공급자에 걸쳐 가중치에 따라 나눕니다.

콤보는 일반 공급자 라우팅 앞단에 놓입니다. provider/model 선택자에 익숙하지 않다면 먼저 Model Routing을 읽으십시오.

60초 퀵스타트

이 예시는 Anthropic을 먼저, OpenAI를 나중에 두는 combo/main을 만듭니다. 두 공급자는 이미 존재하고 활성화되어 있어야 합니다.

ocx combo set main --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol

기본 전략은 페일오버이므로 일반 요청은 anthropic/claude-opus-4-8으로 갑니다. 그 시도가 재시도 가능한 실패를 내면 opencodex는 openai/gpt-5.6-sol로 넘어갈 수 있습니다.

가상 모델은 평소에 모델 ID를 넣는 자리 어디서나 사용할 수 있습니다.

{
  "model": "combo/main",
  "input": "Explain why the sky looks blue."
}

저장된 정의를 확인합니다.

ocx combo show main

콤보 이름 동작

ocx combo set <id>의 콤보 ID는 문자나 숫자로 시작해야 합니다. 그 뒤에는 문자, 숫자, ., _, -를 포함할 수 있고, 전체 길이는 64자 이하여야 합니다. 정식 모델 ID는 항상 combo/<id>입니다. 예를 들어 ID main은 combo/main이 됩니다.

콤보를 설정하면 combo/ 네임스페이스는 예약됩니다. 이름이 combo인 공급자는 그 자리를 차지할 수 없고, 콤보 ID도 이미 설정된 공급자 이름과 겹칠 수 없습니다.

선택적 alias를 쓰면 콤보의 공개 모델 이름을 따로 둘 수 있습니다. alias는 다음 조건을 따릅니다.

ID와 같은 문자를 사용합니다.
daily-fast처럼 단독일 수도 있고, team/daily-fast처럼 /를 하나 포함할 수도 있습니다.
combo일 수 없고 combo/로 시작할 수도 없습니다.
다른 콤보 alias와 중복될 수 없습니다.
일반적으로 gpt-, o1-, o3-, o4-, codex-로 시작하는 bare OpenAI 계열 이름일 수 없습니다. 명시적 nativeAlias: true Desktop 호환 모드만 예외입니다.

alias를 설정해도 정식 combo/<id> 형식은 계속 해석됩니다. 정식 조회가 alias 매칭보다 먼저 실행되므로, alias가 다른 콤보의 정식 ID를 가로챌 수는 없습니다.

콤보를 바꾼 뒤 대화 압축

클라이언트가 콤보를 바꾼 뒤 공급자 접두사 없는 모델 이름으로 압축을 요청하면, opencodex는 같은 대화에서 가장 최근에 응답을 성공적으로 마친 콤보를 기억해 사용할 수 있습니다. 모델 이름이 완료된 응답과 일치하고, 현재 설정에 해당 콤보와 대상이 남아 있어야 합니다. 압축 요청도 일반 콤보 선택과 페일오버를 따릅니다.

명시한 공급자·콤보 선택자와 설정된 콤보 별칭이 기억한 값보다 우선합니다. 실패·미완료·취소된 응답은 마지막 성공 기록을 덮어쓰지 않습니다. 기록은 프로세스 안에서 최대 256개 대화, 30분 동안 유지하고, 모델 이름 하나당 1 KiB·전체 64 KiB로 제한하며, 만료된 기록은 배경에서도 정리합니다. 모델 이름이 너무 커서 보관할 수 없는 응답은 이전 선택을 지우지 않고 그대로 둡니다. 기록은 계정 자격증명을 저장하지 않습니다. 유효한 대화 식별자나 기록이 없으면 일반 압축 라우팅을 사용합니다. 재시작하면 기록은 사라집니다.

전략 선택

페일오버: 순서가 있는 기본값과 예비값

failover는 설정 순서에서 가장 먼저 적합한 대상을 선택합니다. 대상이 적합하려면 해당 공급자가 존재하고, 활성화되어 있고, 쿨다운 중이 아니며, 요청에 붙은 특수 조건을 처리할 수 있어야 합니다. 이 전략에서는 가중치와 stickyLimit이 영향을 주지 않습니다.

다음 순서가 있다고 하겠습니다.

anthropic/claude-opus-4-8
openai/gpt-5.6-sol
google/gemini-3-pro

각 요청은 Anthropic에서 시작합니다. Anthropic에서 재시도 가능한 실패가 나면 그 요청은 OpenAI로 넘어갑니다. OpenAI에서도 재시도 가능한 실패가 나면 Google로 넘어갈 수 있습니다. 종결 오류가 나면 남은 대상은 더 시도하지 않고 즉시 멈춥니다.

라운드 로빈: 부드러운 가중 배치

round-robin은 smooth weighted round-robin을 사용합니다. 대상 가중치가 클수록 시간에 따라 더 큰 비중을 가져가지만, 그 몫이 한꺼번에 긴 덩어리로 몰리지는 않습니다. stickyLimit은 선택된 대상에 몇 번의 성공 요청을 붙여 둘지 정합니다.

성공 요청 두 번씩 묶는 2:1 콤보를 만듭니다.

ocx combo set balanced \
  --targets anthropic/claude-opus-4-8:2,openai/gpt-5.6-sol:1 \
  --strategy round-robin \
  --sticky 2

대상을 A(가중치 2)와 B(가중치 1)라고 하면, 처음 여섯 번의 가중 선택은 A, B, A, A, B, A입니다. stickyLimit이 2이므로 각 선택은 성공 요청 두 번 동안 유지됩니다.

성공 요청	1	2	3	4	5	6	7	8	9	10	11	12
대상	A	A	B	B	A	A	A	A	B	B	A	A

장기 비율은 여전히 2:1입니다. 재시도 가능한 실패가 나면 현재 sticky 배치를 끝내고, 그 대상을 쿨다운 상태로 보낸 뒤, 같은 요청에 대해 다른 적합한 대상을 선택합니다.

`random`: 요청마다 가중 추첨

random은 요청마다 적합한 대상 하나를 weight에 비례한 확률로 추첨합니다. 각 요청은 독립적으로 추첨되므로 round-robin의 결정적 패턴이나 고정성 없이 트래픽이 대상 전체에 분산됩니다. stickyLimit은 이 전략에 영향을 주지 않습니다.

`least-used`: 성공 횟수가 가장 적은 대상 우선

least-used는 이 opencodex 프로세스가 기록한 성공 요청 수가 가장 적은 적합한 대상으로 각 요청을 라우팅합니다. 재시작하면 횟수는 0부터 시작하며, 동률이면 설정 순서를 유지합니다. weight와 stickyLimit은 이 전략에 영향을 주지 않습니다.

`reset-window`: 가장 가까운 할당량 재설정 따르기

reset-window는 캐시된 공급자 할당량 스냅샷에서 가장 가까운 다음 기간 재설정(5시간, 주간, 월간 또는 사용자 지정)이 표시되는 적합한 대상으로 각 요청을 라우팅합니다. 이렇게 하면 가장 먼저 새로 충전되는 공급자를 사용합니다. 최신 할당량 데이터가 없는 대상과 동률인 대상은 설정 순서를 유지합니다. weight와 stickyLimit은 이 전략에 영향을 주지 않습니다.

이 순위 결정과 전송 전 공급자 제외에는 현재 단일 API 키의 전체 모델 추론에 적용되는 최신 한도 정보가 필요합니다. OAuth·현재 계정 요약, 호출자 인증을 전달하는 경로, 여러 키, 인증 정보나 목적지가 달라진 스냅샷은 이 사전 판단에서 표시 용도로만 사용합니다. Authorization, x-api-key, x-goog-api-key 헤더로 인증을 덮어쓰는 경우도 같으며, 검색 전용·MCP 전용 기간은 제외합니다. 적격 대상 중 적용 가능한 초기화 정보가 없으면 설정 순서를 따릅니다. 실제 계정 선택과 재시도에는 기존 제한이 계속 적용됩니다.

대상 실패 시 동작

콤보 실패는 홉 실패와 종결 실패로 나뉩니다.

결과	동작
HTTP 401, 403, 404, 408, 429, 또는 모든 5xx	대상을 쿨다운으로 보내고 다음 적합한 대상으로 넘어갑니다.
모델 수명 종료, retired, deprecated, sunset, decommissioned, 또는 더 이상 사용할 수 없다는 신호가 명시된 HTTP 410	해당 대상만 쿨다운으로 보내고 다음 대상으로 넘어갑니다. 관련 없는 410은 종결 오류로 유지합니다.
인증, 구독, 쿼터, 속도 제한, 과부하, 또는 상위 서버 오류로 분류됨	상태 코드만으로는 충분하지 않더라도 대상을 쿨다운으로 보내고 넘어갑니다.
클라이언트 취소(499), `origin_rejected`, cyber-policy refusal, context overflow, 또는 기타 invalid request	멈추고 오류를 반환합니다. 다른 대상을 써도 요청이 유효해지지 않기 때문입니다.
`user`를 명시적으로 거부하거나, `reasoning.effort`/`reasoning_effort`의 지원되지 않는 값 또는 모델별 이미지 입력 거부(`param: input`)를 나타내는 구조화된 HTTP 400	출력 시작 전에 쿨다운 기록 없이 다음 적격 대상으로 넘어갑니다. 선택적 매개변수 호환성을 참조하세요.
그 밖의 분류되지 않은 오류	멈추고 오류를 반환합니다.

cooldownMs가 설정되지 않으면 홉된 대상은 업스트림 폴백을 사용합니다. 업스트림 코드 1302 또는 1305인 요청 속도 제한 429는 5초, 그 외에는 60초입니다. 설정하면 사용 가능한 업스트림 Retry-After 또는 Codex 재설정 신호가 없을 때, 해당 요청 속도 제한 429를 포함해 cooldownMs가 적용됩니다. 숫자로 된 Retry-After 초와 HTTP-date 값을 허용하며, 모든 쿨다운은 최대 10분으로 제한됩니다. 우선순위는 강한 순서대로 명시적 Retry-After → Codex 재설정 헤더(x-codex-primary-reset-at, x-codex-secondary-reset-at, 또는 x-codex-tertiary-reset-at) → 콤보의 cooldownMs(설정된 경우) → 업스트림 속도 제한 코드 1302/1305의 5초 요청 속도 제한 폴백 → 60초 기본값입니다. 유효한 즉시 지시인 Retry-After: 0은 설정된 쿨다운으로 대체하지 않고 업스트림의 즉시 지시로 유지합니다.

현재 요청은 이미 시도한 대상을 다시 시도하지 않습니다. 이후 요청은 쿨다운이 끝날 때까지 해당 대상을 건너뜁니다. 이미 지난 시각을 가리키는 Retry-After HTTP-date도 Retry-After: 0과 마찬가지로 업스트림의 즉시 지시로 유지됩니다. waitForCooldownMs를 설정하면 이후 요청은 가장 먼저 적합해지는 대상의 쿨다운을 선택 시도마다 이 한도까지 기다린 뒤 새로 한 번 선택합니다. 따라서 여러 failover 홉을 거치는 요청은 총 hops × waitForCooldownMs까지 기다릴 수 있습니다. 기본값은 0입니다. 모든 적합한 대상이 쿨다운 중이고 대기 한도가 0이거나 가장 이른 만료 시각이 대기 한도를 넘으면 요청은 즉시 HTTP 503으로 종료됩니다. 이 combo_unavailable 503에는 가장 이른 잔여 쿨다운과 같은 Retry-After 헤더가 포함되며, 값은 올림해 정수 초로 표시되고 최소 1초입니다. 대기에 지터를 적용하지 않으므로 동시에 깨어날 수 있습니다. 요청이 중단되면 이 대기가 취소되고 정상 client_cancelled 응답이 반환됩니다. 취소 후 백업 대상을 디스패치하지 않습니다. 콤보 대상 쿨다운은 프로세스 로컬 콤보별 상태입니다. 네이티브 계정 라우팅에서 사용하는 계정 수준 Codex 쿼터 쿨다운과는 별개입니다.

스트리밍 요청에서는 상위 HTTP 상태만으로 최종 결정을 내리지 않습니다. OpenCodex는 선택한 하위 대상의 Responses SSE를 출력 시작 전의 제한된 구간까지만 버퍼링합니다. 텍스트, 추론, 도구 호출 또는 그 밖의 출력 이벤트가 시작되기 전에 재시도 가능한 response.failed 종결 이벤트가 오면 해당 시도를 실패로 기록하고 다음 적합한 대상을 시도할 수 있습니다. 출력이 시작되거나 버퍼 상한에 도달하면 현재 대상에 커밋하며, 이후의 스트림 실패를 다른 공급자에서 다시 실행하지 않습니다. 따라서 텍스트와 도구 실행이 중복되지 않습니다.

기본 reasoning effort

defaultEffort는 콤보 기본값이 null이 아니고, 선택한 대상의 지원 목록이 알려져 있으며 비어 있지 않을 때 생략된 reasoning.effort를 채웁니다. 설정값을 지원하면 그대로 사용합니다. 그렇지 않으면 설정값 이하의 가장 높은 지원 단계를 사용하고, 그런 단계가 없으면 가장 낮은 지원 단계를 사용합니다. 지원 목록이 없거나 비어 있으면 기본값을 생략합니다.

기본값 주입은 기존 effort와 다른 reasoning 필드를 보존합니다. 아래의 capability 정규화는 별도로 지원되지 않는 effort·thinking 제어를 제거할 수 있습니다. 기본값은 low, medium, high, xhigh, max, ultra이며, 필드를 생략하거나 null로 설정하면 주입하지 않습니다.

서로 다른 reasoning capability

reasoningEffortMode의 기본값은 "strict"입니다. 모든 대상의 effort 목록을 교집합으로 계산하므로 명시적 빈 목록도 반영합니다. "adaptive"는 빈 목록을 교집합에서 제외해 혼합 콤보에서도 선택기를 유지합니다. 알 수 없는 목록은 두 모드 모두 카탈로그 교집합을 제한하지 않습니다.

전송 시 명시적 빈 목록은 두 모드 모두에서 effort·thinking 제어를 제거하고, 알 수 없는 목록은 adaptive에서만 제거합니다. reasoning.summary와 다른 비-effort 필드는 보존하며, 알려진 비어 있지 않은 대상은 기존 방식으로 effort를 결정합니다. strict의 unknown 대상과 일반 native Chat의 unknown 선언은 그대로 유지됩니다. 기본값 주입은 기존 effort를 덮어쓰지 않지만, 이 capability 정규화는 지원되지 않는 제어를 제거할 수 있습니다.

암호화된 v2 서브에이전트 작업

Codex v2 서브에이전트에는 중요한 제한이 하나 있습니다(issue #92). 네이티브 부모 프로세스는 새로 생성된 작업자에게 보낼 작업을 네이티브 ChatGPT 백엔드용으로 생성한 암호문으로만 전달할 수 있습니다. 외부 공급자는 그 페이로드를 읽을 수 없습니다.

이런 요청에서 콤보는 재시도 가능한 실패가 나더라도 정식 네이티브 ChatGPT 경로만 적합 대상으로 남깁니다. 콤보에 복호화 가능한 대상이 하나도 없으면 opencodex는 전송 전에 멈추고 HTTP 400을 반환합니다.

{
  "error": {
    "type": "invalid_request_error",
    "code": "unreadable_encrypted_agent_task"
  }
}

이렇게 하면 읽을 수 없는 지시문이 들어 있는 요청이 해당 공급자에게 가지 않습니다. 읽을 수 있는 평문 작업은 일반 콤보 전략을 사용합니다.

복구 방법은 네 가지입니다.

자식에게 네이티브 ChatGPT 모델을 선택합니다.
콤보에 정식 네이티브 ChatGPT 대상을 추가합니다.
서로 다른 공급자 사이의 위임에는 v1 경로를 사용합니다.
호출자를 직접 제어할 수 있다면 작업을 평문 v2 agent_message content로 다시 보냅니다.

v1/base/v2 모드와 암호화된 작업의 전체 흐름은 Sub-agent Surface를 보십시오.

콤보 관리

대시보드

로컬 대시보드를 열고 Models → Combos를 선택합니다. 워크스페이스는 콤보를 만들고, 편집하고, 이름을 바꾸고, 제거할 수 있으며, 대상 선택기에서는 비활성 모델과 중첩 콤보를 제외합니다.

각 대상에는 사용 가능, 할당량 소진, 할당량 알 수 없음 실시간 배지도 표시됩니다. 편집기는 사용 가능한 모든 대상에 대해 설정된 인증 정보의 추론 한도가 소진되었다는 서버 확인이 현재 유효할 때만 할당량을 이유로 저장과 만들기를 차단합니다. 표시 전용 계정·모델·검색·MCP 할당량이나 누락되거나 만료된 라우팅 근거 정보는 이 차단을 일으키지 않습니다. 차단은 해당 한도의 초기화 시점이나 데이터 유효기간이 끝나면 해제되며 페이지가 활성화되거나 표시될 때 다시 확인됩니다. 새로 고침은 콤보 데이터와 할당량을 모두 다시 불러옵니다. 대시보드 편집기에서는 아직 cooldownMs나 waitForCooldownMs를 설정할 수 없습니다. 후속 UI 작업이 완료될 때까지 구성 파일이나 관리 API를 사용하세요.

CLI

주요 명령은 다음과 같습니다.

ocx combo list
ocx combo show <id>
ocx combo set <id> --targets provider/model[:weight],...
ocx combo remove <id> --yes

set은 --strategy, --sticky, --effort, --alias, --native-alias, --display-name, --rename-from도 받습니다. --native-alias에는 현재 지원되는 bare native alias와 비어 있지 않은 display name이 필요합니다. --effort, --alias, --display-name에 -를 지정하면 해당 값을 지울 수 있습니다. create와 update는 set의 별칭이고 delete는 remove의 별칭입니다. 모든 combo 하위 명령은 ocx route combo ...에서도 사용할 수 있습니다.

Management API

헤드리스 클라이언트는 /api/combos에 GET, PUT, DELETE를 사용합니다. GET은 정규화된 콤보 정의를 나열하고, PUT은 새 항목을 만들거나 교체하며(이름 바꾸기도 가능), DELETE는 id 쿼리 파라미터를 사용합니다. 인증과 요청/응답 세부 내용은 Management API reference에 있습니다. PUT 본문에서 cooldownMs 또는 waitForCooldownMs를 생략하면 해당 콤보에 이미 저장된 값이 유지됩니다. 변경하려면 값을 명시적으로 보내세요. 명시적 cooldownMs(60000 포함)는 요청 속도 제한 폴백을 덮어쓰므로 보낸 값 그대로 저장됩니다. 저장된 cooldownMs는 구성 파일을 편집할 때만 삭제할 수 있습니다. waitForCooldownMs는 PUT에서 0을 명시적으로 보내면 기본값으로 돌아갑니다. 희소 직렬화기가 이 기본값을 생략하기 때문입니다. 생략한 값은 유지되고, 대시보드에서는 아직 두 값을 설정할 수 없습니다.

전체 지속 설정은 Configuration을 보십시오.

구성 참조

콤보는 최상위 combos 객체에 저장되며, 콤보 ID로 키를 잡습니다.

{
  "combos": {
    "balanced": {
      "targets": [
        { "provider": "anthropic", "model": "claude-opus-4-8", "weight": 2 },
        { "provider": "openai", "model": "gpt-5.6-sol", "weight": 1 }
      ],
      "strategy": "round-robin",
      "stickyLimit": 2,
      "defaultEffort": "high",
      "alias": "team/balanced"
    }
  }
}

필드	필수	기본값	규칙
`targets`	예	—	설정된 `{ provider, model, weight? }` 대상의 비어 있지 않은 순서가 있는 배열이어야 합니다. 중복된 provider/model 쌍은 거부됩니다.
`targets[].weight`	아니요	`1`	1에서 10,000 사이의 정수입니다. `round-robin`과 `random`에서 사용되며, `failover`, `least-used`, `reset-window`에서는 무시됩니다.
`strategy`	아니요	`"failover"`	허용되는 값은 `"failover"`, `"round-robin"`, `"random"`, `"least-used"`, `"reset-window"`입니다.
`stickyLimit`	아니요	`1`	한 번의 `round-robin` 선택에 유지되는 성공 요청 수로, 1에서 100 사이의 정수입니다. `round-robin`에만 적용됩니다.
`cooldownMs`	아니요	미설정 → 업스트림 폴백(요청 속도 제한 429 코드 `1302`/`1305`는 5초, 그 외는 60초)	1에서 600000 사이의 정수입니다. 설정하면 사용 가능한 업스트림 `Retry-After` 또는 Codex 재설정 신호가 없을 때 요청 속도 제한 429를 포함한 대상별 쿨다운으로 적용됩니다. 설정하지 않으면 업스트림 폴백을 사용합니다.
`waitForCooldownMs`	아니요	`0`	0에서 600000 사이의 정수입니다. `combo_unavailable`을 반환하기 전에 가장 먼저 적합해지는 쿨다운 중인 대상을 기다리는 최대 시간입니다. 중단하면 대기가 취소됩니다.
`defaultEffort`	아니요	`null`	`low`, `medium`, `high`, `xhigh`, `max`, 또는 `ultra`입니다. 호출자가 effort를 생략하고 대상이 지원을 광고할 때만 적용됩니다.
`reasoningEffortMode`	아니요	`"strict"`	`strict` 또는 `adaptive`; 혼합 capability의 교집합과 대상별 제어 정규화를 선택합니다.
`alias`	아니요	없음	선택적으로 앞뒤 공백을 제거한 공개 모델 ID입니다. 위의 alias 규칙을 따릅니다. 빈 값은 alias 없음으로 저장됩니다.
`nativeAlias`	아니요	`false`	현재 지원되는 bare native alias가 routing/catalog 우선권을 갖도록 명시적으로 허용합니다.
`displayName`	아니요	없음	catalog 표시 전용 label입니다. `nativeAlias`가 true이면 필수입니다.

문제 해결

`combo/<id>`가 404를 반환하는 이유는 무엇인가요?

combo id를 찾을 수 없기 때문입니다. 응답은 HTTP 404와 invalid_request_error 유형을 반환합니다. ocx combo list를 실행하고, 철자와 대소문자를 확인하고, 관리 명령이 모델 요청을 받는 것과 동일한 opencodex 인스턴스에 기록했는지 확인하세요.

`combo_unavailable`이 발생하는 이유는 무엇인가요?

모든 대상이 현재 부적격 상태입니다. 예를 들어 프로바이더가 비활성화되었거나, cooldown 중이거나, 이 요청에서 이미 시도되었거나, 암호화된 v2 작업 때문에 제외되었을 수 있습니다. 대상 프로바이더 상태와 최근 업스트림 오류를 확인하세요. 쿨다운에서는 먼저 응답의 Retry-After 값을 따르세요. Codex 재설정 헤더도 cooldownMs보다 우선합니다. 두 업스트림 신호를 모두 사용할 수 없을 때 설정된 cooldownMs를 적용하고, 미설정이면 업스트림 폴백(요청 속도 제한 코드 1302/1305는 5초, 그 외는 60초)을 적용하며 모든 쿨다운은 최대 10분으로 제한됩니다.

alias가 거부된 이유는 무엇인가요?

먼저 alias 문법과 예약 이름을 확인하세요. 중복 alias나 잘못된 형식은 HTTP 400으로 거부됩니다. 첫 세그먼트가 설정된 Codex 계정 네임스페이스인 slash 포함 alias는 HTTP 409로 거부되므로 다른 alias 네임스페이스를 선택하세요. CLI와 대시보드는 서버의 정확한 검증 메시지를 표시합니다.

첫 번째 오류 뒤에 failover가 멈춘 이유는 무엇인가요?

대상별 오류가 아니라 종결 오류였기 때문입니다. 잘못된 입력을 수정하고, 너무 큰 context를 줄이고, 정책 거부를 처리하거나, 거부된 요청 origin을 바로잡으세요. combo는 이런 경우 다음 대상으로 넘어가지 않습니다.

선택적 매개변수 호환성

일반적인 400 오류는 종료되지만, user를 명시적으로 거부하거나 reasoning.effort/reasoning_effort의 지원되지 않는 값 또는 모델별 이미지 입력 거부(param: input)를 나타내는 구조화된 오류는 출력 시작 전에 다음 적격 대상으로 넘어갈 수 있습니다. 이 경우 쿨다운을 기록하지 않습니다. 보안 정책 거부, 취소 및 이미 시작된 출력은 재실행하지 않습니다.

Canonical compatibility details.