Jev 1.13이 깨지는 지점: TypeSafe 자체 한계 목록

Jev 1.13(typesafe/jev-1.13)은 2026-09-15에 출시되었는데, 이는 지난 7일 범위에서 2주나 벗어나 있으므로 그 출시 자체가 화젯거리는 아니다. 날짜가 붙은 사건은 2026-09-24다. 바로 그날 OrcaRouter가 typesafe/jev-1.13을 자사 카탈로그에 추가하고 모델 카드를 개설했다 — 제3자 게이트웨이에서 Jev를 서빙 지원한 최초의 사례로, 그 전 2주 동안에는 TypeSafe 자체 엔드포인트로만 호출할 수 있었다. 이것이 여기서 특정한 이유 하나 때문에 중요하다. Jev는 벤더가 자신이 실패하는 방식들의 목록을 공개한다는 점에서 이례적인데, 읽을 수만 있는 목록은 실제로 호출할 수 있는 모델보다 훨씬 건너뛰기 쉽다.

이 페이지는 TypeSafe 자체가 말한 내용으로 한정된 그 목록에 운영상의 한계와 청구서를 더한 것입니다.

TypeSafe는 자체적인 jaggedness 목록을 게시합니다.

docs.typesafe.ai에는Jev 1.13의 들쭉날쭉함이라는 제목의 페이지가 있습니다. 이 페이지는 명시적으로 jev-1.13에 적용되며, 검토 날짜는 2026-09-17이고, 벤더 자신의 설명으로 시작합니다: "Jev는 완벽하지 않습니다. 다음은 jev-1.13과 관련해 우리가 인지하고 있는 몇 가지 들쭉날쭉한 부분입니다. 이 중 상당수는 이후 버전에서 수정될 예정입니다." 이어서 아홉 가지 이름이 붙은 모드가 나오며, 각각에는 구체적인 사례와 "Instead:"라는 해결책이 딸려 있습니다. 아래 내용 중 추론된 것은 없고, 완화된 것도 없습니다 — 문구는 TypeSafe의 것이며, 회사가 자체 예시를 드는 경우 그 안의 숫자도 회사의 것입니다.

문자 그대로 읽으면: 그것은 당신이 쓴 질문에 답합니다

범위 한정어, 부정, 그리고 암시된 조건은 액면 그대로 읽힌다. 질문은 지시문에 있는 말에 따라 답변되는데, "반면 사람은 지시문 뒤에 있는 의도를 읽었을 수도 있다."

벤더의 진단이 유용한 부분입니다: 잘못된 답변을 보고 자신이 정말로 의도한 바를 설명하고 있는 자신을 발견할 때, 그 설명은 지침에서 빠져 있는 절반입니다. 해결책은 지침에 정확한 조건을 명시하고, 기준에 경계 사례를 넣고, 해석이 정말로 불가피한 경우에는 질문을 문자 그대로의 질문 두 개로 나누어 코드에서 결합하는 것입니다.

수학과 숫자: 그것은 계산기가 아닙니다

TypeSafe는 수학적 논리를 코드로 구현하라고 분명히 말한다. 그 아래에는 세 가지 구체적인 실패가 자리한다:

• 개수 세기는 신뢰할 수 없다. 여기에는 단어의 문자 수, 구절에서 특정 용어가 나타나는 횟수, 긴 목록의 항목 수가 포함된다. "모델은 세는 것이 아니라 답의 형태를 인식하며, 오류는 세는 대상의 크기가 커질수록 증가한다." 애초에 물어봐야 할지 판단하기 위한 공급업체 자체의 기준은 다음과 같다: 정규 표현식이나 파서가 단위를 찾을 수 있다면 그 개수는 코드에 속하며 모델은 아무것도 더하지 않는다.

• 수치적 표현은 의미론적 표현보다 성능이 떨어진다. 색상에 관한 질문에서 16진수 값을 사용하는 경우는 영어 색상 이름을 사용하는 동일한 질문보다 더 나쁘다. RGB 삼중항이나 16진수가 주어지면 Jev는 두 값이 서로 가까운지 안정적으로 판단할 수 없다. 같은 격차는 저수준 코드—어셈블리나 이진 인코딩 명령어—와 고수준 언어를 비교할 때도 나타난다. 코드에서 변환하거나 구간화하고, 진정한 판단이 필요한 부분에만 모델을 사용하라.

• 점수 출력은 정확한 값 크기를 담고 있지 않다. 공급업체는 Jev의 점수 레벨이 수치 보정에 취약하다고 밝힌다. 기댓값은 어떤 것이 임계값을 통과하는지 테스트하는 데 사용할 수 있지만, 가장 가까운 두 레벨 사이를 보간하여 그 숫자를 재구성하는 데 사용할 수는 없다. 이는 오용의 한 부류 전체—점수를 측정값으로 읽는 것—에 대한 단호한 불가다.

날짜 및 시간: 날짜는 수량이 아니라 텍스트로 읽습니다

두 날짜의 순서를 정하거나, 둘 사이의 간격을 측정하거나, 어느 한쪽이 특정 기간 안에 들어가는지 판단하는 일은 신뢰할 수 없으며, 형식이 뒤섞이고 상대적 참조가 섞이고 분기, 정산 기간, 발생 기간과 같은 도메인 경계가 등장하면 더욱 나빠진다.

권장되는 분할은 깔끔합니다. 추출은 판단의 영역이므로 모델에 맡기세요. 날짜의 각 구성 요소는 작은 닫힌 집합입니다 — 12개월, 31개의 가능한 날, 제한된 연도 범위 — 이로 인해 추출은 자유 형식 파싱이 아니라 열거된 선택지 중에서 고르는 일이 되고, 명시적인 "명시되지 않음"을 넣을 자리를 마련해 누락된 부분을 추측하는 대신 보고하게 해줍니다. 코드가 구성 요소를 조립하고, 그 이후의 모든 것—순서, 기간, 오프셋, 요일—을 담당합니다.

간접성: 이중 부정과 추가 경유는 정확도를 떨어뜨린다

이중 부정이나 여러 겹의 우회 표현이 담긴 지침은 더 신뢰성 있게 답변되지 않는다. 속성의 속성에 관한 질문이나 여러 단계의 추론을 요구하는 질문은 정확도를 떨어뜨린다. 해결책은 지침을 가능한 한 직접적으로 작성하고, 상태의 관련 부분을 설명하기보다는 이름을 붙이는 것이다.

무관한 세부 정보로 가득 찬 큰 상태는 정확성을 떨어뜨린다.

정확도는 결정과 무관한 내용으로 상태가 커질수록 떨어진다. 무관한 세부 사항은 방해 요소로 작용하고, 상태가 크면 입력의 어느 부분이 잘못된 답을 만들어냈는지 구분하기가 더 어려워진다. TypeSafe가 맺음말에 남긴 자체 경고는 직설적이다: “Jev는 컨텍스트 부패(context rot)를 겪기 때문에 상태에 있는 무관한 자료는 정확도를 떨어뜨린다.”

코드에서 먼저 검색하고 필터링한 다음, 질문에 필요한 필드만 전송하세요. 요청 전에 필터링하는 것이 불가능한 경우, 공급업체는 noul을 사용해 관련성을 기준으로 필터링한 후 남은 항목을 판단할 것을 제안합니다.

상태 내의 적대적 콘텐츠가 답변을 이동시킨다

상태는 데이터이며, jev-1.13은 기본적으로 이를 적대적으로 취급하지 않습니다. 주입된 지시, 의도적으로 오해를 유도하는 프레이밍, 또는 자신의 분류를 주장하는 텍스트는 결과를 바꿀 수 있습니다. 이것은 공급업체가 수정 사항을 향후 작업으로 명시적으로 규정하는 유일한 모드입니다 — "우리는 향후 이 부분을 개선할 것으로 기대합니다" — 그리고 당분간의 조언은 기준을 명확히 하고, 많은 사용자에게 선보이기 전에 통합을 철저히 테스트하라는 것입니다.

모순되는 지시와 기준은 그것을 혼란스럽게 만든다

지침과 기준이 서로 다른 것을 요구할 때, 모델은 혼란스러워할 수 있습니다. TypeSafe의 예시는 true가 no에 매핑되고 false가 yes에 매핑되는 noul인데, 이는 같은 질문을 일관되게 표현한 경우보다 성능이 더 나쁩니다. 지침은 기준을 지침의 확장으로 취급하고, 두 가지를 평범한 사람이 읽고 이해할 수 있는 언어로 정렬하라는 것입니다.

그것이 보장하지 않는 구조적 불변식

이 모드는 아무도 명시적으로 적어 두지 않은 가정 위에 구축된 시스템을 깨뜨릴 가능성이 가장 높은 모드입니다. Jev는 일반적인 의미에서 극도로 일관적입니다 — 의미상 유사한 입력은 양적으로 유사한 출력을 생성합니다 — 하지만 유지될 것이라고 기대할 수 있는 구조적 동일성은 보장되지 않습니다. 공급업체는 두 가지 구체적 사례를 게시합니다.

• 한 가지 질문, 두 가지 질문 유형. "고객이 환불을 요청하고 있나요?"를 noul로 물었을 때와 예/아니요 선택으로 물었을 때, 티켓 "핏이 마음에 들지 않아요. 여기서 제 선택지는 무엇인가요?"에서는 noul이 0.22, 선택은 예 0.01, 아니요 0.99, 신뢰도 0.97을 반환합니다. 이것들은 같은 질문에 대한 답입니다.

• 질문과 그 부정. "고객이 환불을 요청하고 있나요?"와 "고객이 환불이 아닌 다른 것을 요청하고 있나요?"를 티켓 "동일한 주문에 대해 두 번 청구되었습니다. 누군가 이 문제를 살펴봐 주실 수 있나요?"에 두 개의 nouls로 질문하면 0.72와 0.47을 반환합니다. 이들의 합은 1.19입니다.

해법들은 수사적이 아니라 작동적이다: 기대되는 구조적 불변성에 의존하지 말고, noul에서 조정된 임계값을 선택으로 옮기지 말며, 별개의 질문들 사이의 산술적 항등식에 모델을 맞추지 말라. 그 이유는 선택은 상대적이어서 어느 옵션인지를 정하는 반면, 각각의 noul은 절대적이고 그 모두에 대해 낮게 나올 수 있기 때문이다.

생성: 쓰도록 훈련되지 않았습니다.

jev-1.13은 텍스트를 생성하도록 학습되지 않았습니다. 선택지를 연쇄시켜 출력을 강제할 수 있지만, TypeSafe는 이 방식이 "잘 작동하지 않을 것이며 매우 느릴 것"이라고 직접 밝히고 있습니다. 추출의 경우, 지침은 정규 표현식이나 생성 모델로 후보 값을 뽑아낸 다음 Jev가 올바른 값을 선택하게 하거나, 답의 공간이 한정되어 있을 때에는 값 자체를 묻기보다 추출을 선택지들 중 하나를 고르는 문제로 바꾸는 것입니다.

선택형 질문의 선택지 255개 상한

선택형 질문으로서 Jev 통합은 들쭉날쭉한 모서리가 아니라 제품의 형태입니다. 이것들은 따로 분리해 둘 가치가 있습니다. 아무리 많은 프롬프트 작업도 이것들을 바꾸지 못하기 때문입니다:

• 텍스트 생성 없음. 산문이 아니라 결정을 반환합니다. 그것이 결함이 아니라 설계입니다.

• 대화는 없습니다. Jev는 채팅 모델이 아니라 구조화된 의사결정 모델입니다. 상태와 이름이 지정된 질문 세트를 보내면, 질문마다 하나의 구조화된 답변을 반환합니다. 턴을 주고받는 방식을 염두에 두고 설계할 필요가 없습니다.

• 멀티모달 입력이 없습니다. 입력은 텍스트만 가능합니다 — 문자열, JSON 객체 또는 텍스트 값의 배열이며, 이미지, 오디오 또는 비디오는 포함되지 않습니다. 비텍스트 자료는 상태의 일부가 되기 전에 텍스트 또는 구조화된 필드로 사전 처리되어야 합니다.

• 비스트리밍 응답. 단일 구조화된 응답이 있고 스트리밍 모드는 없습니다. 이것이 문제가 되지 않는 이유는 이를 언급할 가치가 있는 이유와 같습니다. 스트리밍할 것이 없기 때문입니다. 타입이 지정된 결정, 즉 확률이 있는 불리언, 집합 중 하나의 레이블, 또는 척도상의 수준은 토큰별로 드러낼 가치가 있는 부분적 형태가 없습니다.

• 영어가 기본 언어입니다. CJK 문자 체계를 포함한 다른 언어도 처리되지만, 동등한 수준으로 잘 처리되지는 않습니다. TypeSafe의 조언은 비영어 워크로드에 Jev를 의존하기 전에 자체 콘텐츠에서 테스트하고, 라우팅할 때 신뢰도를 활용하라는 것입니다.

선택형 질문의 선택지 255개 상한

선택 질문은 최대 255개의 레이블이 붙은 옵션 중 하나를 고르며, 그 상한선은 넘을 수 없는 엄격한 한계입니다. TypeSafe는 또한 대규모 선택 세트가 왜 더 느리게 실행되는지를 벤더 자신의 말로 설명합니다: "카디널리티가 더 높은 선택의 경우, 우리는 개별적으로 점수를 매긴 다음 명시적인 선택을 내리는 2단계 시스템을 사용합니다. 그래서 때때로 속도 저하가 발생합니다." 따라서 큰 옵션 세트의 지연 비용은 부수적인 것이 아니라 구조적인 것이며, 이는 벤더가 그 원인이 어디에서 비롯되는지 직접 알려주는 셈입니다.

2026-09-30에 모델 카드에서 확인한 typesafe/jev-1.13의 우리 자체 서빙 윈도우는, 우리 자체 트래픽 7일 동안 이것이 실제로 어떤 모습인지 보여줍니다: 중앙값 151 ms, p95 247 ms, 초당 출력 토큰 348개, 그리고 제공된 7,620만 토큰에 걸친 0.49%의 오류율입니다. 일별 중앙값은 좁은 범위에서 움직입니다 — 2026-09-24부터 2026-09-30까지 175, 170, 163, 161, 170, 147, 143 ms — 하지만 2026-09-28의 일별 p95는 2,448 ms로, 그 앞뒤 날들의 약 10배입니다. 우리는 그 하루치 이상치를 선택지 카디널리티 탓으로 돌릴 수 없고, 그럴 생각도 없습니다; 솔직한 해석은 꼬리가 존재한다는 것이며, 지연 시간에 민감한 워크플로는 중앙값이 아니라 꼬리를 기준으로 설계해야 한다는 것입니다.

입력 청구서가 전체 청구서입니다.

Jev에서는 출력에 대해 0으로 청구되며, 이는 때때로 "Jev는 무료다"로 해석되기도 합니다. 하지만 그렇지 않습니다. 입력은 과금되고, 출력 쪽에 아무것도 없다고 해서 대규모 상태가 무료인 것은 아니기 때문입니다. 벤더 가격은 백만 입력 토큰당 $0.042이며 — TypeSafe가 10억 토큰당 $42라고 명시하는 것과 같은 숫자입니다 — OrcaRouter는 제공자 정가를 0% 마크업으로 그대로 전달하므로, 벤더 가격 인하가 같은 날 여기에도 반영됩니다.

공급업체 자체 요율을 사용할 때, 그것이 현실적인 형상에 미치는 영향은 다음과 같습니다:

• 작은 요청입니다. 1,200토큰짜리 지원 티켓에 약 300토큰의 평가 기준과 질문을 더하면 1,500 입력 토큰이며, 이는 호출당 $0.000063입니다.

• 큰 요청입니다. 55,000토큰짜리 계약서에, 요청을 60,000토큰으로 끌어올리는 질문들이 더해지면 토큰 수가 40배가 되므로 호출당 $0.0025입니다 — 여전히 호출당 적은 금액이지만, 동일한 답 하나에 대해 첫 번째 경우보다 40배 더 큽니다.

• 대량 사용 기준. 호출당 60,000토큰, 하루 10,000회 호출이면 하루 6억 입력 토큰, 즉 0.6 billion이며, 따라서 하루 $25.20, 30일 한 달 기준 약 $756입니다. 동일한 호출 수를 1,500토큰 요청 기준으로 계산하면 하루 1,500만 토큰입니다: 하루 $0.63, 한 달 약 $18.90입니다.

마지막 두 줄 사이의 격차는 가격 책정 속임수가 아니라, 계량된 상태다. 그래서 컨텍스트 부패 섹션의 필터링 조언은 정확성을 위한 조치일 뿐만 아니라 — 상태를 잘라내는 것이 청구서를 움직이는 유일한 지렛대이기도 하다.

공표된 작동 한계, 그래서 아무도 추측할 필요가 없습니다

TypeSafe의 models 페이지는 구체적인 수치를 공개하므로, 기획자는 이를 추론할 필요가 없습니다:

• 처리량과 속도. docs.typesafe.ai/models.md에 따르면 초당 100K 토큰과 초당 40회 요청입니다. 두 한도 중 하나를 초과하는 요청은 429 Too Many Requests를 반환합니다. 공급업체의 클라이언트 SDK는 기본적으로 백오프를 적용해 재시도하며, 응답에 retry-after 헤더가 포함된 경우 이를 준수합니다.

• 한도는 변동됩니다. 공급업체는 용량이 확보됨에 따라 레이트 리밋이 동적으로 조정되며 "예고 없이 변경될 수 있다"고 밝히고, 커스텀 및 엔터프라이즈 플랜에서는 더 높은 한도를 이용할 수 있다고 합니다. 100K/40은 계약상 보장된 수치가 아니라 오늘 기준 수치로 보세요.

• 컨텍스트 예산. 요청 예산은 결합된 상태와 모든 질문을 합쳐 대략 64,000토큰입니다 — 모델 카드에는 65,536이 공개되어 있습니다 — 그리고 공급업체의 모델 페이지에서는 상태와 단일 최장 질문을 합한 값을 별도로 32,000토큰으로 제한합니다. 두 번째 수치는 상태 예산이며, 첫 번째 수치의 더 작은 버전이 아닙니다. 둘 다 실제이며 서로 모순되지 않습니다.

• 별칭은 예고 없이 바뀝니다. 현재 jev-latest와 jev-preview는 모두 jev-1.13.0을 가리키며, 벤더는 지금 사용 가능한 프리뷰 빌드가 없다고 밝힙니다. 별칭은 새 릴리스가 나오면 바뀌므로, 특정 버전을 기준으로 신뢰도 임계값을 조정해 두었다면 버전이 명시된 ID를 고정하고 원하는 일정에 맞춰 옮기십시오.

유스케이스가 어떤 모습이어야 하는지

처음부터 끝까지 읽어보면, 공급업체 자신의 목록은 좁지만 유용한 도구를 설명한다. Jev는 판단이 제한적이고 산술이 모델의 일이 아닐 때 적합하다. 이 레코드가 정책에 부합하는가, 이 마흔 개 레이블 중 어느 것이 적용되는가, 이것이 5단계 척도에서 어떻게 읽히는가 — 직접 필터링한 상태를 대상으로, 문자 그대로의 지시와 그에 부합하는 기준을 가지고, 그리고 모든 집계와 비교와 날짜 측정이 그 주변의 코드에서 수행되는 상태에서.

작업에 계산, 순서 정하기 또는 날짜 연산이 필요할 때, 여러 단계의 추론이 필요할 때, 입력 자료가 텍스트가 아닐 때, 상태는 건초더미인데 질문은 바늘일 때, 또는 소스에 관해 무엇 하나라도 적대적일 때 그것은 적합하지 않다. 그것들은 프롬프트의 빈틈이 아니다. 그것들은 모델이 작동하지 않는 지점이며, 그렇게 말하는 주체는 TypeSafe다.

연결하기 전에 알아두면 좋을 점이 하나 더 있습니다: Jev를 호출하는 방식에 있는 솔직한 차이입니다. OrcaRouter에서 카탈로그는 OpenAI chat-completions 형태가 아니라 전용 systemone 엔드포인트인 POST /v1/systemone을 통해 Jev에 도달합니다. 이는 작성하는 요청에 있어 실질적인 차이이며, Jev가 "자체적인 요청 형태를 사용한다"는 기존 주장의 올바른 버전입니다. 그 외의 모든 것은 계정의 다른 모든 모델과 동일합니다 — 200개 이상의 모델을 위한 키 하나, 저희가 부과하는 토큰당 요금 없음, 그리고 경로에 문제가 생기면 자동 페일오버가 제공됩니다. TypeSafe는 2026-09-21에 대기자 명단을 제거했습니다. 벤더의 자체 홈페이지는 여전히 Jev를 얼리 액세스로 설명하고 있으며, 자체 벤치마크 페이지는 여전히 보류 중으로 표시되어 있습니다. 따라서 이 페이지의 유일한 성능 수치는 저희가 직접 측정한 서빙 수치와 벤더 자체의 주장뿐이며, 후자는 벤더의 주장으로 표시되어 있습니다.