Jev 1.13 해설: 모델이 문장 대신 레이블로 답하는 이유

Jev 1.13 (typesafe/jev-1.13)은 채팅 모델이 아니며, 이를 가장 빨리 이해하는 방법은 다른 모든 모델의 스펙 시트를 읽듯이 이 모델의 스펙 시트를 읽는 것을 멈추는 것입니다. TypeSafe는 2026-09-15에 이 모델을 회사가 System One 모델이라고 부르는 부류의 첫 번째 구성원으로 출시했습니다. 이 모델에는 상태 한 조각과 이름이 붙은 질문 세트를 주면, 질문마다 하나의 타입이 지정된 답변을 돌려줍니다. 즉, 당신이 제공한 목록에서 고른 레이블, 당신이 정의한 척도상의 레벨, 또는 확률이 붙은 참/거짓입니다. 산문도, 코드도, 설명도 없습니다. 이것은 출시 기사가 아닙니다. 모델 자체는 2026-09-15에 나온 것으로, 15일 되었고 이 블로그가 다루는 7일 범위 밖에 있으므로 자체 출시만으로는 이 블로그에 페이지를 얻지 못합니다. 범위 안에서 일어난 일은 OrcaRouter가 2026-09-24에 typesafe/jev-1.13을 자체 카탈로그에 추가하고 https://www.orcarouter.ai/models/typesafe/jev-1.13에서 Jev 1.13 모델 카드를 열었다는 것입니다. Jev가 TypeSafe 자체 엔드포인트를 통해서만이 아니라 제3자 게이트웨이를 통해 호출 가능해진 첫 사례이며, TypeSafe 외부의 누군가가 이 모델에 관해 게시한 첫 라이브 서빙 데이터입니다. 읽을 가치가 있는 변화는 이것입니다: 그 모델은 실행 가능하지 않던 곳에서 실행 가능해졌습니다.

그 변화의 실질적인 형태는 작고 구체적이다. 2026-09-24 이전에 Jev를 도입한다는 것은 두 번째 벤더 관계를 맺는 일이었다 — TypeSafe 계정, TypeSafe 키, TypeSafe 청구서, 그리고 작성해야 할 맞춤형 요청 형태까지. 그 이후에는 Jev가 스택의 나머지와 동일한 키 위에 자리한다: 200개 이상의 모델을 위한 단일 API, 0% 마크업(공급업체 목록 가격이 그대로 전달되므로 벤더의 가격 인하가 여기서도 같은 날 반영된다), 그리고 POST /v1/systemone에서 typesafe/jev-1.13으로 접근할 수 있는 모델. 여전히 고유한 형태로 호출한다 — 이 엔드포인트는 OpenAI chat-completions 경로가 아니며, 그렇다고 가정하면 결정이 아니라 404가 반환될 것이다 — 하지만 서명하는 계약과 교체하는 키는 이미 가지고 있는 것과 동일하다.

Jev가 어떤 종류의 모델인지

TypeSafe의 출시 글은 이를 한 문장으로 말한다. "우리의 첫 공개 모델은 Jev이며, 오늘부터 얼리 액세스로 사용할 수 있습니다." 그런 다음 이 글은 이 모델을 "프런티어 인텔리전스 함수 호출: 비정형 상태를 입력받아 타입이 지정된 확률적 결정을 출력한다"라고 규정한다. 이는 인터페이스에 대한 타당한 설명이며 중요한 설명이다. Jev에 관한 거의 모든 잘못된 기대가 그것을 소규모 언어 모델로 평가하는 데서 비롯되기 때문이다. 그것은 소규모 언어 모델이 아니다. 그것은 고정된 출력 문법을 가진 결정 모델이며, 그 문법이 곧 제품이다.

인터페이스에는 정확히 두 개의 입력이 있습니다. 상태는 판단 대상이 되는 재료입니다. 이메일, 지원 티켓, 로그 한 줄, JSON 레코드, 게임 좌표 배열 같은 것이죠. 질문은 이름이 붙은 항목들의 맵으로, 각 항목은 타입과 자체 지침을 가지며, 두 가지 구조화 타입의 경우에는 기준까지 함께 가집니다. 모든 질문은 바로 그 동일한 상태에 대해 평가되고, 답변은 하나의 구조화된 JSON 페이로드로 돌아옵니다. TypeSafe의 문서는 질문들이 동시에 그리고 독립적으로 실행된다고 설명하며, 튜닝이 아니라 그 설계에서 따라 나오는 두 가지 주장을 내세웁니다. 질문을 추가해도 응답 시간은 거의 달라지지 않는다는 것, 그리고 질문을 추가해도 컨텍스트 부패(context rot)가 생기지 않는다는 것입니다. 각 질문이 이전 질문들의 하위 단계가 아니라 독립적으로 판단되기 때문입니다.

TypeSafe 자체의 설계 지침은 다시 언급할 가치가 있습니다. 그것이 이 모델의 목적을 가장 명확하게 보여주는 설명이기 때문입니다. 각 질문은 원자적이고 범위가 잘 한정되어야 합니다 — "지식이 아주 풍부한 사람이라면 몇 초 안에 내릴 수 있는 종류의 판단"입니다. 어떤 결정에 확장된 추론이 필요하거나 여러 독립적인 요인을 진정으로 결합해야 한다면, 그것을 별도의 질문들로 나누고 여러분의 코드에서 다시 결합하세요. 그들의 예시: 하나의 "이 스타트업 피치를 평가하라" 프롬프트 대신, 시장 규모, 기술적 실현 가능성, 차별화에 대해 각각 따로 질문한 다음, 자신만의 가중치를 적용하세요. 이것이 중요한 이유는, 그러면 가중치가 다시 작성해야 하는 프롬프트 안이 아니라 변경할 수 있는 계수에 존재하게 되기 때문입니다.

이 모델은 리스크를 따지는 엔지니어에게 중요한 모든 측면에서 폐쇄적이다. Jev의 아키텍처, 파라미터 수, 학습 컴퓨팅, 가중치는 공개되지 않았다. TypeSafe GitHub 조직에는 가중치 저장소가 없다. 그곳의 공개 저장소 11개는 툴링, SDK, 워크플로, 그리고 무관한 포크 세 개이며, 그중 어느 것도 이 모델이 아니다.

"Typed"가 제품의 전부입니다

OrcaRouter 모델 카드에는 세 가지 기본 요소와, 더 중요하게는 각 요소의 한계가 공개되어 있습니다. Jev에게 묻는 모든 질문은 정확히 세 가지 형태 중 하나입니다:

• noul — 참/거짓 판단으로, 순수 불리언 대신 보정된 확률과 함께 반환되므로 "아마 참"과 "확실히 참"이 구별되는 값이다.

• 선택 — 최대 255개의 레이블이 지정된 옵션 중 하나를 고르세요. 각 옵션에는 고유한 기준 텍스트가 있어 모델이 당신의 레이블을 구분하는 기준을 알 수 있습니다.

• 점수 — 기준으로 제공된 수준 정의를 사용하여 2–10개 수준의 순서 척도로 평가합니다.

그 제한의 결과는 산문에서 파싱해 낼 것이 없고, 모델이 따르기를 바랐던 스키마에 대해 검증할 것도 없다는 것이다. TypeSafe의 출시 게시물은 그 보장에 대해 이례적으로 직접적이다: 그래프에 있는 "0%" 스키마 불일치 수치는 "경험적이지 않다. 스키마 일치는 보장되므로, 우리는 자신 있게 그래프에 0%를 넣을 수 있다."라고 말한다. 답변 공간이 당신이 제공한 닫힌 집합일 때, 반환된 값은 그 집합 안에 있거나 모델에서 나오지 않은 것이다 — 모델이 잘못된 형태로 그럴듯한 무언가를 써 놓았는데 당신의 정규식이 그것을 조용히 받아들인 제3의 결과는 없다.

세 가지 유형은 또한 평가자가 Jev를 채팅 모델을 평가하듯 평가할 수 없는 이유이기도 합니다. 비교할 MMLU-Pro 점수도, 읽어 볼 작문 샘플도, 살펴볼 추론 흔적도 없습니다. 의미 있는 유일한 질문은 입력한 답변이 맞는지, 그리고 그 답변에 붙은 확률이 정직한지입니다. 이 둘은 모두 측정 가능하지만, 오직 당신의 데이터와 레이블을 기준으로만 그렇습니다.

문서화된 한 가지 차이점은 해결하기보다는 짚고 넘어갈 가치가 있습니다: TypeSafe 자체 문서에는 0부터 인덱싱되는 Score 예제가 나오는 반면, OrcaRouter 카드는 척도를 2–10레벨로 공개합니다. 공급업체는 레벨을 문서화하고, 우리 카드는 2–10을 공개합니다. Score 위에 루브릭을 구축하고 있다면, 인덱스를 가정하지 말고 자신의 응답에 있는 레벨 정의를 읽으십시오.

청구할 출력 토큰이 없는 이유는 무엇인가요?

가격은 이 아키텍처를 가장 명확하게 드러내는 표현이다. Jev는 OrcaRouter에서 백만 입력 토큰당 $0.042의 비용이 들고, 출력 요율은 백만 토큰당 $0.000000이다 — 할인도, 출시 프로모션도 아니고, 측정 가능한 양이 존재하지 않는다는 뜻이다. 생성 모델은 자신이 쓰는 텍스트에 대해 과금된다; Jev는 텍스트를 쓰지 않는다. 그것은 레이블, 레벨, 확률을 반환한다. 출력 측에서 셀 것이 없으므로, 그쪽에는 아무것도 청구되지 않는다.

TypeSafe는 자사 홈페이지에서 같은 수치를 반대 방향에서 제시한다 — "입력 토큰 10억 개당 $42" — 그리고 여기에 비교 주장을 덧붙인다: "Claude Fable 5.1보다 입력 가격이 238배 더 낮음". 그 비교는 홈페이지의 다른 모든 것과 마찬가지로 벤더 자체의 주장이며, 누구도 재현하지 않았다. 하지만 그것이 근거로 삼는 계산은 독자가 자신의 청구서와 대조해 확인하기 쉬우며, 바로 이 점이 유용한 부분이다. 의사결정 워크로드의 볼륨은 거의 전적으로 얼마나 많은 상태를 투입하느냐에 따라 결정되며, 상태는 생성된 토큰과는 달리 저렴하다.

공급업체의 헤드라인 수치는 가격 표기보다 더 크게 내세워지므로, 여기에도 동일한 라벨이 붙어야 합니다. TypeSafe는 “193.6배 더 빠르고, 444.6배 더 저렴”이라고 광고하면서 이를 “System One 작업을 위한 워크플로”로 제한하는 각주를 달고, 그 아래에 구체적인 예시를 게시합니다: TypeSafe AI는 $0.000081에 0.114초 만에 완료된 반면, LLM은 $0.013880에 8.566초 만에 완료되었습니다. 출시 게시물 자체도 이러한 프레이밍 위험을 인정합니다 — 193.6배와 444.6배는 “실제 세계 개선 효과의 상당히 높은 쪽”에 있을 가능성이 있다고 설명하며 — 또한 나란히 비교한 데모가 공급업체가 “우리 모델을 유리하게 보이도록” 선택한 사람이 읽을 수 있는 키를 사용한 “매우 단순화된” 쿼리를 사용했다고 언급합니다. 이 수치 중 어느 것도 독립적으로 재현되지 않았으며, 공급업체 자체의 벤치마크 카드는 여전히 보류 중으로 표시되어 있습니다.

"캘리브레이션됨(calibrated)"이 의미하는 것, 그리고 RLCD란 무엇인가

TypeSafe는 자사의 훈련 방법에 스스로 이름을 붙인다: "Reinforcement Learning for Calibrated Decisions (RLCD)". RLCD는 TypeSafe의 자체 용어이며, 회사보다 먼저 존재했던 일반적인 머신러닝 약어가 아니다. 그 최적화 목표는 출시 게시물의 비교 표에 "calibrated decisions: answers with epistemically honest probabilities on System One tasks"라고 명시되어 있다. 같은 표가 대비시키는 대상은 RLHF와 RLVR이다. RLHF는 인간 선호 — 평가자들이 좋아하는 글과 채팅 응답 — 를 최적화하고, RLVR은 프로그램적으로 검증할 수 있는 출력을 최적화한다. RLCD는 세 번째 목표를 최적화한다: 답변에 붙는 확률이 모델 자신의 불확실성을 정확하게 진술하는 것이 되도록 하는 것이다.

실무적으로, “보정된(calibrated)”은 신뢰도에 관한 주장이지, 답이 맞는다는 보장이 아니다. 질문 세트에서 0.8이라고 말하는 보정된 모델은 그 세트 전체에서 약 80%의 경우 맞아야 하지만, 개별 질문에서는 여전히 틀릴 수 있다. 그 구분이 TypeSafe의 홈페이지 문구 “환각 제로 — 모든 Jev 결정에는 신뢰도 추정치가 함께 제공되므로, 소프트웨어는 신뢰도가 높을 때 행동하고 높지 않을 때 에스컬레이션할 수 있습니다.”를 정직하게 읽는 방식이다. 그것은 신뢰도 추정에 관한 주장이지 오류가 전혀 없다는 증명이 아니며, 여기에 균형을 맞추는 것은 우리 자체 데이터다: 2026-09-30에 끝나는 7일 동안 우리 카드는 OrcaRouter를 통과하는 Jev 트래픽에서 0.49%의 오류율을 측정했다 — 같은 기간의 더 이른 시점에는 0.57%로 나타났는데, 이는 고정된 테스트 세트가 아니라 라이브 플레이그라운드 트래픽의 롤링 7일을 기준으로 계산되기 때문이다. 두 사실은 같은 문단에 속한다: 신뢰도는 이 모델의 핵심이며, 그 모델은 여전히 우리 트래픽에서 약 200번의 호출 중 1번꼴로 실패한다.

캘리브레이션 이야기는 그렇지 않으면 버그처럼 보일 수 있는 레이턴시 동작도 설명합니다. TypeSafe의 출시 게시물은 다음과 같이 말합니다: "카디널리티가 더 높은 선택의 경우, 우리는 독립적으로 점수를 매긴 다음 명시적으로 선택하는 2단계 시스템을 사용하므로 가끔 속도 저하가 발생합니다." 255개 옵션 선택은 단일 정방향 비교가 아닙니다; 벤더가 점수를 매기고 나서 선택합니다. 대규모 레이블 집합에 대한 요청이 noul보다 눈에 띄게 오래 걸리는 것을 본다면, 그것은 문서화된 메커니즘이지 혼잡이 아닙니다.

오늘 당신은 그것을 어떻게 부르나요?

OrcaRouter에서 이 모델은 typesafe/jev-1.13이며, 카탈로그에서 "TypeSafe: Jev 1.13"이라는 이름으로 등록되어 있고, context_length는 65,536 토큰이며 지원되는 엔드포인트 유형은 단 하나, systemone입니다. OrcaRouter 키로 POST /v1/systemone을 호출할 때 model 필드, state 필드(문자열, 객체 또는 배열), 그리고 각 항목이 type(noul, choice 또는 score), 해당 instructions, 해당 criteria를 포함하는 questions 맵을 보냅니다. 응답은 단일 구조화 JSON 페이로드이며 스트리밍되지 않습니다. 선택할 수 있는 스트리밍 모드는 없습니다.

카드 자체에서 계약을 표현한 문구는 "텍스트 입력, 구조화된 JSON 출력"이며, 설계 기준이 되어야 하는 것은 공개된 한도입니다. 즉, 비스트리밍 방식이고, 결합된 상태와 질문을 통틀어 최대 약 64K 입력 토큰까지이며, 이 한도를 초과하는 요청은 모델에 도달하기 전에 거부됩니다. 카탈로그 항목에는 정가가 백만 입력 토큰당 $0.042로 기재되어 있고 완료율은 0으로 표시되어 있습니다. 이는 변경 없이 그대로 전달된 공급업체의 수치입니다. 즉, 우리가 가격을 책정하는 방식의 비례적 형태인 공급업체 정가 대비 0% 마크업입니다.

이 모델에는 두 가지 토큰 예산이 통용되며 서로 충돌하지 않으므로, 둘을 구분해 두세요. 65,536이라는 수치는 카드의 context_length이며, 상태와 질문을 합친 입력이 대략 64K라고 문서화되어 있습니다. 이전 OrcaRouter 글에서 인용한 "대략 32,000 토큰"은 상태 예산만을 가리킵니다 — 질문이 제 몫을 가져가기 전에 여러분의 자료가 사용할 수 있는 공간입니다. 요청의 예산을 산정할 때, 상태 예산은 여러분이 구성하는 페이로드를 제약하는 수치이고, 합산 수치는 전체 호출의 상한입니다.

Jev가 할 수 없는 것, 분명히 말하자면

그것은 산문을 쓰거나 요약하거나 번역하거나 대화할 수 없다. 그것은 사과해야 할 한계가 아니라 설계다. 출시 글에서는 Jev가 “문자열 생성을 포기한다”고 말하며, TypeSafe 자체의 jaggedness 페이지에서는 “Generation”을 명명된 실패 모드로 나열하고 그 옆에 “생성 모델을 사용하라”는 지침을 붙여 둔다. 강제 생성은 느리고 형편없다. 파이프라인에 작성된 요약이 필요하다면 Jev는 잘못된 구성 요소이며, 프롬프트를 아무리 잘 만들어도 그것은 달라지지 않는다.

그것은 생성 모델을 대체하는 것이 아니다. Jev가 속한 워크플로에는 두 개의 모델이 있다: 텍스트를 읽고 쓰고 추론하는 생성 모델, 그리고 그 옆에서 밀리초 단위로 타입이 지정된 호출을 수행하는 Jev. 이것이 공급업체 홈페이지의 모든 비용 비교에 담긴 솔직한 설명이다 — "LLMs" 열은 밀려나는 경쟁자가 아니라 같은 시스템의 나머지 절반이며, 이 조합이 흥미로운 이유는 의사결정 절반이 이제 자체 계약 뒤에 있는 것이 아니라 생성 절반과 동일한 키 위에 있기 때문이다.

그리고 "calibrated"는 정답을 의미하지 않는다. 그것은 답변에 붙는 숫자가 확률로 읽히도록 의도된다는 뜻이다. noul에 대한 0.62는 모델이 확신하지 못한다고 말해 주는 것이며, 이는 단순한 예/아니요라면 사라졌을 유용한 정보이다 — 그리고 그것은 '예'가 맞다는 약속이 아니다. 신뢰도를 바탕으로 한 에스컬레이션 로직이 의도된 패턴이고, 답변을 정답으로 취급하는 것은 아니다.

숫자를 정직하게 읽기

우리 카드의 모든 서빙 수치는 벤더의 벤치마크가 아니라, 최근 7일 이동 기간 동안 OrcaRouter의 플레이그라운드를 통과한 우리 자체 트래픽에서 나온 것이며, 이 글을 쓰는 동안에도 그 기간은 이동했습니다. 그러니 이를 사양이 아니라 측정값으로 보세요. 2026-09-30에 끝나는 7일간: 첫 토큰까지의 시간 중앙값 151ms, p95 247ms, 출력 처리량 초당 약 349토큰, 오류율 0.49%, 제공된 토큰 7,620만 개. 해당 기간의 일별 p50은 175, 170, 163, 161, 170, 147, 143ms로 완만하게 개선되는 흐름을 보입니다. 09-28의 p95 2,448ms는 그 계열에 있는 실제 하루치 이상치이며, 이를 표준으로 인용하는 것은 이것을 아예 빼버리는 것이 부정직한 것과 마찬가지로 잘못입니다.

트래픽 수치에 관한 한 가지 추가 주의점: 초당 349개의 출력 토큰은 생성 모델의 처리량처럼 들리지만, Jev가 생성된 텍스트를 만들어내지 않는다는 점을 기억하면 그렇지 않습니다. 이 측정기는 구조화된 페이로드에 대해 우리 playground가 응답 측에서 집계하는 대상을 측정하는 것이며, Jev를 채팅 모델과 비교하기보다는 날짜 간 성능 저하를 포착하는 데 유용합니다.

저건 우리 수치입니다. 벤더의 수치는 193.6x, 444.6x, $0.000081 계산 예시, 그리고 Claude Fable 5에 대한 238 비교입니다 — 모두 TypeSafe 자체 수치이며, 어느 것도 독립적으로 재현되지 않았고, 모두 자체 각주에 따라 특히 System One 작업 워크플로로만 제한됩니다. TypeSafe가 내세우는, 벤치마크가 전혀 아니면서 그 배수들보다 더 가치 있는 단 하나의 성능 주장은 구조적인 것입니다: 답변에 타입이 지정되어 있기 때문에 통합에는 파싱 단계도 스키마 검증 단계도 없으며, 그것은 어떤 지연 시간 표에도 나타나지 않는 비용입니다.

무엇이 열려 있고, 무엇이 열려 있지 않은가

2026-09-30에 확인한 결과, TypeSafe GitHub 조직은 11개의 리포지토리를 공개했습니다. 그중 어느 것도 Jev를 포함하지 않습니다. 모델을 통합하는 개발자에게 중요한 리포지토리들은 모두 MIT 또는 Apache-2.0입니다: skills (MIT), system-one-adapter-python (MIT, "LLM API를 기반으로 하는 드롭인 TypeSafeClient 대체품"으로 설명됨), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, 워크플로 코드는 evals.typesafe.ai에 게시됨), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io 및 pulumi-clickhouse. 스타 수와 푸시 날짜는 변동하므로, 나중에 이 글을 읽는다면 목록을 그대로 믿지 말고 다시 확인하세요.

열한 개 중 세 개는 관련 없는 프로젝트의 포크이며 Jev가 어떻게 작동하는지에 대해 아무것도 증명하지 않는다: 2025년 5월에 마지막으로 푸시된 vLLM 포크, 2025년 6월의 LLaDA 포크 — LLaDA는 관련 없는 확산 언어 모델 릴리스다 —, 그리고 ClickHouse Cloud용 Pulumi 프로바이더다. 포크 목록에서 아키텍처를 읽어내고 싶은 유혹이 든다. 그러지 마라: Jev의 설계에 관해 그 세 가지로부터 따라 나오는 것은 아무것도 없으며, 특히 LLaDA 포크의 존재가 아무리 그렇게 암시하는 듯 보일지라도 Jev는 확산 모델이 아니다.

"Jev는 오픈 소스인가"에 대한 솔직한 한 줄 답은 도구는 열려 있고 모델은 그렇지 않다는 것입니다. 이는 호스팅되는 프런티어 모델에서 흔한 구조이며, Jev를 염두에 두고 계획할 때 가정해야 하는 구조이기도 합니다: 공개된 가격, 문서화된 계약, 그리고 공개되지 않은 파라미터 수를 가진 API입니다.

공급업체가 Jev는 신뢰할 수 없다고 말하는 경우

TypeSafe는 jev-1.13에 대한 자체 jaggedness 페이지를 공개했으며, 마지막 검토일은 2026-09-17이고, 모델이 어디에서 무너지는지 밝히고 있습니다. 이는 이례적으로 솔직하며, 경쟁사가 아니라 공급업체 자체의 목록이기 때문에 한계 섹션을 시작하기에 적절한 곳입니다:

• 문자적 읽기 — 어구를 액면 그대로 받아들인다. 범위를 한정하는 표현, 부정, 함축된 조건은 추론되지 않으며, "당신이 쓴 질문에 답할 뿐, 당신이 의도한 질문에 답하지 않는다." 공급업체의 해결책은 모든 옵션에 대해 정확한 조건과 기준을 작성하는 것이다.

• 수학과 숫자 — 이것은 계산기가 아니며, 개수를 안정적으로 셀 수 없습니다. 산술 연산은 코드로 처리하세요.

• 날짜 및 시간 비교 — 날짜는 순서가 있는 수량이 아니라 텍스트로 읽히므로 정렬, 간격, 기간을 신뢰할 수 없으며, 형식이 뒤섞이면 더욱 그렇습니다.

• 간접성 — 이중 부정과 다중 홉 추론은 정확도를 떨어뜨립니다. 홉을 줄이고 관련 상태를 직접 가리키세요.

• 관련 없는 세부 정보로 가득 찬 큰 상태 — 무관한 내용이 방해 요소로 작용하고 상태가 커질수록 정확도가 떨어집니다. 먼저 필터링하세요.

• 적대적 콘텐츠 — 상태가 적대적으로 취급되지 않으므로, 주입된 지시나 오해를 유도하는 프레이밍이 답변을 바꿀 수 있습니다.

• 모순되는 지침과 기준 — 두 가지가 서로 다른 것을 요구할 때, 모델은 "혼란스러워질 수 있습니다."

• 상식적인 구조적 불변량 — P(noul)과 1 − P(not noul)이 일관적이라는 보장은 없습니다. 각 결정을 한 가지 방식으로만 물어보고, 항등식을 코드에서 강제하세요.

• 생성 — 이미 다룬 내용이며, 벤더 자체의 권장 사항도 생성 모델을 사용하는 것입니다.

이 중 두 가지는 특히 강조할 만하다. 적대적인 쪽이 중요한 이유는 Jev의 가치 제안 전체가 신뢰할 수 없는 자료를 판단하는 것이고, 지시를 담은 상태(state)는 답변을 바꿀 수 있기 때문이다. 당신의 상태가 사용자로부터 들어온다면, 그것은 다른 어떤 것과도 같은 형태의 프롬프트 인젝션 표면이다. 구조적 불변량 쪽이 중요한 이유는 "calibrated" 모델이 당신에게 그 확률들로 산술을 하도록 유도하는데, 벤더는 그 산술이 닫힌다고 가정하지 말라고 말하고 있기 때문이다.

출시 게시물이 약속하는 것과 약속하지 않는 것

이 글에서 인용된 거의 모든 공급업체 주장은 한 페이지로 거슬러 올라간다: Company News에 분류되어 2026-09-15 날짜로 올라온, 창립자 Diogo Almeida가 서명한 TypeSafe 자체의 발표다. 그 페이지를 직접 읽는 데 2분을 들일 가치가 있다. 한 줄의 표현이 그 이후 모든 것의 조건을 정하기 때문이다. "우리의 첫 공개 모델은 Jev이며, 오늘부터 얼리 액세스로 이용할 수 있습니다." 얼리 액세스는 공급업체 자체 플랫폼에서의 이용 가능성에 대한 공급업체 자신의 설명이며, 보기보다 좁은 진술이다. 즉 TypeSafe가 승인된 사용자에게 모델을 제공하겠다고 약속할 뿐, 다른 누가 그것을 제공할 수 있는지에 대해서는 아무 말도 하지 않는다. 바로 그것이 2026-09-24 카탈로그 추가가 메운 간극이며, 오늘 Jev를 평가하는 사람이라면 게시물보다 모델 카드가 더 중요한 이유다.

같은 페이지는 자신의 한계에 대해서도 똑같이 분명히 밝히고 있으며, 그래서 위에서는 이 내용을 요약하지 않고 그대로 인용했다. 이 페이지는 파라미터 수를 공개하지 않고, "새로운 모델 아키텍처" 외에는 아키텍처 설명을 제시하지 않으며, 학습 컴퓨트와 가중치 저장소도 공개하지 않고, 일반 제공 시기나 조건도 밝히지 않는다. 이런 결여가 바로 계획의 제약 조건이다. 한쪽에는 가격이 공개된 API가 있고, 다른 쪽에는 내부를 들여다볼 수 없는 스택이 있다. 이 글은 또한 모델을 스펙으로 쓸 만큼 솔직하게 규정하는데 — "프런티어 지능 함수 호출: 비정형 상태 입력, 타입이 지정된 확률적 결정 출력" — 이는 이 글에서 야망이 아니라 인터페이스를 설명하는 유일한 문장이다.

이 인터페이스가 제기하는 질문들

선택 집합이 255개 옵션보다 크면 어떻게 되나요? 상한이 적용됩니다 — 레이블이 지정된 255개 옵션이 선택 질문의 최대치이며, 카디널리티가 증가할 때 벤더가 취하는 방식인 2단계 점수 산정 후 선택 접근법은 대규모 레이블 집합에서 간헐적으로 발생하는 속도 저하의 문서화된 원인이기도 합니다. 분류 체계가 그보다 크다면, 설계상의 답은 이를 여러 질문으로 분해한 뒤 코드에서 재조합하는 것이며, 이는 TypeSafe가 복합 판단에 대해 제시하는 것과 동일한 조언입니다.

65,536 토큰 컨텍스트는 상태(state)가 65,536 토큰이라는 뜻인가요? 아닙니다. 공개된 예산은 상태와 모든 질문을 합쳐 대략 64K 토큰이며, 예전 자료에 나오는 "약 32,000 토큰"이라는 수치는 상태 예산만을 가리킵니다. 페이로드 예산은 합산 수치가 아니라 상태 수치를 기준으로 책정하고, 한도를 초과한 요청은 모델에 도달하기도 전에 거부된다는 점을 기억하세요.

이걸 어떻게 해야 할까요?

Jev 1.13은 한 가지 특정한 이유 때문에 볼 가치가 있으며, 일반적인 이유 때문은 아닙니다. 파이프라인의 어떤 단계가 현재 채팅 모델에게 레이블을 반환하도록 요청하고 올바른 형식으로 반환할 것이라고 신뢰하는 단계라면 — 라우터, 채점기, 정책 검사, 수천 개의 레코드에 적용되는 루브릭 점수 — 그 단계를 바로 이 모델이 대체합니다. 입력 토큰 100만 개당 $0.042이며 출력 쪽에는 과금되는 것이 없습니다. 작성된 답변이 필요한 단계가 있다면 Jev는 그 도구가 아니며, Jev 자체의 공급업체도 그렇게 말합니다.

지난주에 바뀐 것은 모델이 아니다. 바뀐 것은 그것을 시험해 보는 데 더 이상 두 번째 벤더 관계가 필요하지 않게 되었다는 점이다. 8일 전만 해도 Jev 평가를 하려면 별도의 계정과 별도의 통합이 필요했다. 오늘날에는 이미 200개 이상의 모델에 연결되는 키에 모델 ID 하나만 있으면 되고, 벤더의 정가는 그대로 전달되며, 타입이 지정된 답변은 다른 모든 것과 같은 곳에서 돌아온다. 이렇게 특이한 모델의 경우, 새로운 계약에 약정하지 않고도 자체 레이블로 시험해 볼 수 있는 능력이 결정의 대부분을 좌우한다.