입력 100만 토큰당 0.042달러에 출력은 무료, 판단만 하는 모델 Jev

33,561. 개발 업체 FullStack이 기업 3만 3,561곳을 “소프트웨어를 만드는가, 자체 엔지니어링 팀이 있는가, 경쟁사가 아닌가”로 걸러 내는 데 걸린 시간은 4분, 질의 요금은 1.13달러였습니다. 그 일을 한 모델이 TypeSafe AI의 Jev이고, 요금표의 핵심은 두 줄입니다. 입력은 100만 토큰당 0.042달러, 출력 토큰은 무료. Jev는 글을 쓰지 않고 질문마다 선택지별 확률과 확신도만 돌려주는 판단 전용 모델이라 출력 쪽 요금이 붙을 일이 거의 없습니다. 다만 이 모델 주변에는 193.6배, 444.6배, 70~500밀리초 같은 숫자가 함께 돌아다니고, 숫자마다 잰 사람과 조건이 다릅니다. 이 글은 기준일 10월 27일(날짜는 UTC 기준)에 그 숫자를 하나씩 집어 누가 무엇을 쟀는지 따라갑니다.

0.042달러는 입력 토큰에만 곱해진다

Jev에게 보내는 요청은 상태(state) 하나와 질문 여러 개입니다. 아래는 고객 메시지 한 통에 세 가지를 묻는 요청으로, 형식은 공식 문서를 따랐습니다.

curl --silent https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "model": "jev-latest",
  "state": {"message": "I was charged twice this month and nobody answers my emails."},
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this message",
      "criteria": {"billing": "Charges, invoices, refunds", "support": "Product help", "sales": "New purchases"}
    },
    "anger": {
      "type": "score",
      "instructions": "How upset the customer is",
      "criteria": ["Calm", "Annoyed", "Furious"]
    },
    "wants_refund": {"type": "noul", "instructions": "The customer wants money back"}
  }
}
JSON

질문 유형은 세 가지입니다. Choice는 선택지 1255개 중 하나를 고르고, Score는 순서가 있는 210단계 서술 위의 위치를 확률 가중 평균으로 돌려주며(그래서 1.4처럼 단계 사이 값이 나옵니다), Noul은 예/아니오 확률을 01 숫자 하나로 줍니다. 1.14에는 이미지 속 위치를 상하좌우 01 비율로 돌려주는 Box도 생겼지만 이미지 기능과 함께 프로덕션용이 아닌 시험 단계입니다. 응답은 질문 ID별 답과 사용량으로 구성됩니다. 값은 문서 형식을 따른 설명용입니다.

{
  "model": "jev-1.14.0",
  "answers": {
    "team": {"type": "choice", "choice": "billing", "confidence": 0.86,
             "probabilities": {"billing": 0.91, "support": 0.07, "sales": 0.02}},
    "anger": {"type": "score", "score": 1.4, "confidence": 0.31,
              "legend": {"0": "Calm", "1": "Annoyed", "2": "Furious"},
              "probabilities": {"0": 0.03, "1": 0.54, "2": 0.43}},
    "wants_refund": {"type": "noul", "noul": 0.88}
  },
  "usage": {"input_tokens": 312, "output_tokens": 58}
}

청구 대상은 맨 아래 usage의 입력 312토큰입니다. 출력 58토큰에는 요금이 붙지 않습니다. 이 한 건을 0.042달러 단가에 곱해 보면 아래와 같습니다.

이 비용은 편집부가 단가에 토큰 수를 곱한 계산값이고, 상태가 길어질수록 입력 토큰과 비용이 같은 비율로 늘어납니다. 요청당 문맥은 64k, 질문당 32k이며, TypeSafe-Danger-Zone-Long-Context: true 헤더를 보내면 262k까지 늘어나지만 느려지고 정확도가 떨어진다고 문서가 적습니다. 현재 모델 ID는 jev-1.14.0(10월 14일 출시)과 jev-1.13.0이고, 별칭 jev-latest와 jev-preview가 모두 1.14.0을 가리킵니다. 모델 문서에는 폐지 예정 항목이 없고 1.14 이후 새 버전도 올라오지 않았습니다. 시작하려면 콘솔(console.typesafe.ai/keys)에서 키를 만들어 환경 변수 TYPESAFE_API_KEY에 넣고, Python 3.10 이상이면 typesafe-sdk, Node.js 20 이상이면 @typesafe-ai/sdk를 설치합니다. 코드 없이 보려면 콘솔 플레이그라운드에 상태와 질문 JSON을 붙여 넣으면 됩니다.

한 달 새 같은 규격을 내놓은 곳이 다섯이다

9월 15일 얼리 액세스로 시작할 때 Jev는 “판단만 하는 모델”이라는 분류(회사는 System One 모델이라 부릅니다) 자체를 처음 내세운 모델이었습니다. 그 뒤 한 달 사이에 같은 일을 하는 모델이 줄줄이 나왔습니다. Cloudflare가 10월 1일 Clef와 Clef-flash를 Workers AI에 올렸고, 같은 날 Amazon이 내 컴퓨터에서 돌아가는 Strands Decider 2B(Qwen3.5-2B 기반, Apache 2.0)를 공개했으며, Perplexity가 pplx-decider를, OpenAI가 10월 6일 Decisions API를 공개 베타로 열었으며, Liquid AI는 d1을 냈습니다. 같은 시기 TypeSafe는 대규모 투자를 받았다고 보도됐는데, 한 경제지 보도를 인용한 매체들은 시리즈 A 약 8억 7,000만 달러에 기업 가치 75억 달러라고 전했고 회사는 포천 500대 기업의 약 3분의 1이 쓴다고 주장하지만 고객 이름은 공개하지 않았습니다.

이 중 가격과 점수가 함께 공개된 네 점을 놓아 봅니다. 가로는 입력 100만 토큰당 가격(로그 눈금), 세로는 각 제공사가 낸 Decision Index 0.3 점수입니다.

그림 1. 가격과 점수는 제공사가 직접 낸 값(Clef 계열은 Cloudflare, Perplexity는 모델 카드, Jev는 같은 점수판의 값)이고 가격은 출시 시점이다

Jev는 왼쪽 가운데에 있습니다. 가격은 여전히 가장 싼 축에 속하지만, 같은 점수판에서 Perplexity Decider v1.1이 더 싸고(0.02달러) 더 높은 점수를 냈고, Clef는 5.7배 비싼 값(0.24÷0.042, 편집부 계산)에 3.3점 높습니다. 점수판은 평가 세트 버전이 바뀌면 숫자가 움직입니다. 같은 Perplexity 모델이 모델 카드에서는 61.56 대 Jev 57.9, 점수판에서는 62.8 대 60.1로 적혔고 순위 방향은 같았습니다. 종류별로 보면 Perplexity 쪽 표에서 Knowledge는 Jev가 51.4 대 48.18로 앞서고 Tools는 Jev 75.1 대 Perplexity 78.88로 뒤집힙니다. Cloudflare가 자체 보고한 값을 옮긴 한 개발자의 글도 같은 결이어서, 은행 질문 분류인 BANKING77에서는 Clef가 94.2 대 79.7로 크게 앞서고 추론 중심인 GPQA Diamond에서는 Jev가 78.3 대 48.0으로 앞섭니다. 짧은 분류와 라우팅은 작고 싼 모델도 따라왔고, 추론이 들어간 판단은 아직 Jev가 낫다는 해석이 가능한 값이지만 모두 제공사 자체 보고라 내 데이터로 확인해야 합니다.

OpenAI의 Decisions API(POST /v1/decisions, 모델 GPT-6 Luna)는 입력 100만 토큰당 0.10달러에 출력 무료이고 Predicate·Choice·Score 세 형태의 답을 돌려줍니다. 같은 모델을 Responses API로 부르는 것보다 약 10배 빠르다고 OpenAI가 밝혔습니다. Clef 계열은 Qwen 기반 오픈 모델(Apache 2.0)이고 요청·응답 형식이 Jev와 같습니다. 출시 가격은 Clef 0.24달러, Clef-flash 0.09달러이며 출력은 청구하지 않습니다.

193.6배와 171배 사이에서 읽을 것

TypeSafe 홈페이지의 문구는 “193.6배 빠르고 444.6배 싸다”입니다. 아래 그림은 이 숫자와, 같은 모델을 다른 곳에서 잰 배수(LLM 값÷Jev 값)를 한 축에 놓고 오른쪽에 잰 주체를 적었습니다.

그림 2. 헤드라인 두 개를 뺀 배수는 공개된 원값을 편집부가 나눈 계산이다

막대가 길수록 회사가 직접 정리한 숫자이고, 외부가 잰 값은 한 단계씩 낮아집니다. 홈페이지 시연 1회는 Jev가 0.000081달러에 0.114초, 비교한 LLM(GPT-6 Terra)이 0.013880달러에 8.566초여서 비용 171배, 시간 75배입니다. 헤드라인 444.6배·193.6배는 이 시연이 아니라 TypeSafe 능력팀이 짠 네 개 워크플로의 평가에서 나왔고, 그 평가는 정답을 사람이 매기지 않고 GPT-6 Astra와 Fable 5.1 두 모델 답의 평균을 기준으로 삼습니다. 회사 스스로 이 방식이 두 회사 모델에 유리할 수 있다고 적었고, IT 매체 The Register는 비교 자체가 공정하지 않다고 지적했습니다.

회사가 같은 글에 단 단서도 배수의 일부입니다. 속도는 노트북에서 잰 값이고, 지금 가격은 보조를 받은 값일 수 있으며 장기 유지는 증명되지 않았다고 밝혔습니다. 시연 입력은 짧고 정보가 촘촘해 Jev에 유리했고 그 질의는 얼리 액세스 사용자에게만 공개됐습니다. “환각 0%“에는 실증이 아니라 스키마가 보장한다는 설명이 붙는데, 출력이 늘 정해진 형식에 맞는다는 뜻이지 판단이 늘 옳다는 뜻은 아닙니다.

70밀리초, 114밀리초, 524밀리초는 서로 다른 시계다

지연 숫자는 더 조심해서 읽어야 합니다. 같은 “밀리초”라도 서버 안에서 잰 것인지, 호스팅 API까지 왕복한 것인지, 몇 건을 합친 것인지가 다릅니다. 아래 그림은 로그 눈금 하나에 여덟 값을 올렸습니다. 파랑이 Jev, 초록이 Cloudflare Clef 계열, 주황이 LLM입니다.

그림 3. 가로 축이 로그라 한 칸이 10배다. 점은 단일 값, 막대는 보고된 범위

Jev의 70500밀리초 막대와 LLM의 3329초 막대는 서로 닿지 않을 만큼 멀지만, 같은 Jev의 점도 114밀리초(시연 1회), 171밀리초(FullStack 135건 중앙값), 524밀리초(커뮤니티 점수판의 왕복 중앙값)로 4.6배 폭이 있습니다. Cloudflare가 잰 Clef-flash 39밀리초와 Clef 209밀리초는 같은 눈금에서 Jev 쪽 점과 겹쳐서, “수백 밀리초”는 이 분야 모델의 공통 영역으로 읽는 편이 맞습니다. 결국 이 그림에서 얻을 것은 LLM과의 간격이 크다는 사실이고, 몇 밀리초 앞섰다는 비교는 같은 장비와 같은 네트워크에서 내가 직접 잰 값이 아니면 의미가 없습니다.

135건을 가른 시험에서 보이는 비용

외부에서 돌려 본 시험은 FullStack의 내부 시험 하나뿐입니다. 이들은 Jev와 Claude Opus 5.5에 같은 정의와 같은 입력을 주고 비교했고, 통제된 벤치마크가 아니라고 스스로 밝힙니다. 첫 시험은 기술 리더의 LinkedIn 게시물 135건이 영업 신호인지 분류하는 일이고, 두 모델이 갈린 10건은 사람이 눈을 가리고 판정했습니다.

측정	Opus 5.5	Jev
정확도	129/135 (95.6%)	131/135 (97.0%)
전체 비용	0.615달러	0.0034달러
게시물 1,000건으로 환산한 비용	약 4.56달러	약 0.025달러
전체 시간	24.6초	2.9초
오류의 성격	6건 모두 “AI”나 “엔지니어링”을 언급만 한 글을 영업 신호로 본 오탐	4건 모두 확률 0.41~0.55인 경계선 근처

1,000건 환산 비용은 편집부가 135건 비용을 7.4배 키워 계산했고, 비용 비율은 약 181배입니다(그림 2의 FullStack 막대). 정확도 차이 2건은 표본이 작아 우위의 증거가 아니라고 FullStack이 직접 밝혔습니다. 눈여겨볼 점은 Jev의 오류 4건이 전부 확률 0.41~0.55에 몰려 있다는 것입니다. 틀린 답이 “자신 있게 틀린 답”이 아니라 반반에 가까운 답이었으니, 문턱을 두면 사람에게 넘겨 걸러 낼 수 있었다는 뜻입니다.

고객 사례도 한 건 있습니다. 인재 매칭 서비스 Jack & Jill은 후보 심사 단계에서 Gemini 3.1 Flash Lite를 Jev로 바꿨고, 회사 보고에 따르면 후보 1,000명 심사 비용이 0.755달러에서 0.092달러로 88% 줄고 중앙 처리 시간은 20.3초에서 10.3초로 절반이 됐으며, 채용 담당자 유지율은 94.6%와 93.9%로 통계적 차이가 없었습니다. 모두 회사가 정리한 수치이고, 그림 2에서 이 사례의 배수가 8.2배와 2.0배로 가장 작은 것은 비교 상대가 최전선 LLM이 아니라 이미 가벼운 모델이었기 때문입니다.

3만 3,561개를 깔때기에 부으면

두 번째 시험은 맨 앞에서 본 33,561곳입니다. 회사 이름, 홈페이지 제목과 설명, 몇 가지 기업 정보만 넣고 세 질문을 한 요청에 담았으며, 4분에 1.13달러가 들었고 전체 모델 비용은 약 1.5달러였습니다. 편집부가 나눠 보면 한 곳당 약 0.00003달러입니다. 왼쪽은 판정이 갈린 양이고, 오른쪽은 눈을 가리고 검토한 표본의 정답률입니다.

그림 4. 왼쪽 깔때기는 3만 3,561곳 중 68%가 no로 빠진다. 오른쪽 점선은 동전 던지기(50%)

yes 판정은 8,461곳(25.2%), review 2,289곳(6.8%), no 2만 2,811곳(68.0%)입니다. 걸러 낸 양은 분명한데 검증은 좌우가 다릅니다. yes로 뽑은 40건 중 37건(93%)이 맞았고, no로 버린 24건 중에는 13건(54%)만 맞아 11건은 놓친 후보였습니다. 이미 목표 목록에 있던 1,389개 계정에서는 2.54.9%가 잘못 탈락했는데, 이는 편집부 계산으로 약 3568곳입니다. FullStack은 모델이 정의를 틀리게 적용했다기보다 준 정의가 실제 시장보다 좁았다고 분석했습니다. 그래서 이런 선별은 yes의 정답률만이 아니라 no 쪽 표본도 사람이 열어 봐야 하고, 버려진 쪽 54%라는 숫자가 그 이유를 보여 줍니다.

확신도 0.4가 나오는 계산

확신도는 “정답일 확률”이 아닙니다. 문서가 정의한 것은 확률 분포가 한곳에 몰린 정도입니다. Choice는 선택지가 n개일 때 (최고 확률 − 1/n) ÷ (1 − 1/n)이고, 1등만 보기 때문에 (0.6, 0.3, 0.1)과 (0.6, 0.2, 0.2)가 둘 다 0.4입니다. 같은 최고 확률 0.6이라도 선택지가 둘이면 0.2, 셋이면 0.4, 다섯이면 0.5가 됩니다. 아래 곡선이 그 관계입니다.

그림 5. 문서의 Choice 확신도 공식을 편집부가 그린 곡선. 선택지가 적을수록 같은 1등 확률이 낮은 확신도가 된다

곡선은 모두 (1, 1)에서 만나고, 아래쪽 왼쪽 끝은 1/n에서 0입니다. 그래서 확신도 문턱 0.6을 선택지 두 개짜리 질문에 쓰면 1등 확률이 0.8은 되어야 통과하고, 선택지 열 개짜리에는 0.64면 통과합니다. 질문 설계가 달라지면 같은 문턱의 의미가 바뀝니다. Score는 인접한 단계에 걸친 확률을 먼 단계보다 덜 깎아서 이웃한 두 단계에 반반으로 나뉜 (0, 0.5, 0.5)는 0.25이고, 양 끝에 갈라진 (0.5, 0, 0.5)는 0입니다. 응답 예시의 Score 1.4와 확신도 0.31은 Annoyed(0.54)와 Furious(0.43)에 확률이 퍼진 결과입니다. Noul에는 확신도 필드가 없어서 필요하면 |2p − 1|로 직접 계산합니다. 문서가 보정(calibration)이라 부르는 성질은 개별 답이 아니라 예측 묶음 전체에서 재는 것이어서, “0.9면 90% 맞는다”로 읽지 말고 내 데이터에서 구간별 정답률을 재야 합니다.

문턱 숫자는 정책이 정한다

문서의 요리책(cookbook)에는 같은 확률을 상황별 문턱에 대어 행동을 가르는 예가 나옵니다. 값은 모두 예시이고 도메인에 맞춰 정하라고 문서가 강조합니다.

상황	질문	문턱	행동
음성 은행 명령	의도(Choice)	확신도 0.6 미만	사람 상담원
음성 은행 명령	잔액 조회	0.6 이상	바로 보여 줌
음성 은행 명령	송금 승인	0.6~0.85 / 0.85 초과	사용자 확인 / 자동 승인
지원 티켓 한 건	질문 5개 동시	심각도 1.5 초과이고 재현 확률 0.6 초과	엔지니어링으로
지원 티켓 한 건	환불 요청(Noul)	0.7 초과	결제팀에 환불 표시
입출력 가드레일	위험 항목 Noul + 심각도 Score	엄격: 검토 0.35, 실행 0.70, 심각도 2.0	통과·검토·차단
입출력 가드레일	같은 확률, 완화 정책	실행 0.85	변형 탈옥 문구(0.74)는 엄격이면 차단, 완화면 검토

가드레일 예(jev-1.12로 8월 15일 실행)에서 멜라토닌 복용량 질문은 의료 조언 확률 0.55라 사람 검토로, 약물 복용량 요구는 0.95에 심각도 2.0이라 차단으로, 소설 속 독살 장면은 심각도 0.8이라 통과로 갈렸습니다. 같은 확률이 정책에 따라 다른 결정이 된다는 점이 핵심이고, 모델은 확률만 주고 어디까지 허용할지는 코드가 정합니다. 질문을 병렬로 처리하니 문서가 “투기적 팬아웃”이라 부르는 방식(일단 다 묻고 필요한 답만 쓰기)이 응답 시간에 거의 영향이 없습니다.

함수 선택 예는 숫자가 더 많습니다. 거래 분석 함수 10개와 인자 28개를 질문으로 바꾸면 명령 하나에 질문 54개가 만들어지고, 확신도는 그중 가장 불확실한 판단을 기준으로 삼습니다. 시험한 14개 명령 중 “엔비디아 거래가 하루 중 언제 가장 많은가”는 0.53으로 가장 낮았고 롤링 상관관계 명령은 0.91이었습니다. 선택지가 아주 많은 분류체계는 한 번에 고르지 않고 계층을 내려갑니다. 가지마다 Choice를 묻고 상위 3개 경로를 유지하는 빔 탐색이 시험한 4개 분류체계 모두에서 기대한 항목에 닿았고, 가장 높은 것만 따르면 2개에서만 맞았습니다.

문서가 먼저 적어 둔 약점과 한도, 그리고 외부 보안 보고

공식 문서에는 jev-1.13 기준 약점을 정리한 쪽이 따로 있습니다. 약점을 문서로 먼저 알려 주는 점은 강점이고, 하나하나가 설계 규칙이 됩니다.

약점	문서의 대처
질문을 문자 그대로 읽음(부정, 범위 한정어)	조건을 정확히 쓰고, 애매하면 질문 둘로 나눠 코드에서 합침
계산, 개수 세기	산수는 코드로. 개수는 항목마다 예/아니오를 묻고 합산
날짜·시간 비교	날짜 조각을 Choice로 뽑고 계산은 코드에서
이중 부정, 여러 단계 추론	직접적으로 쓰고 상태의 해당 부분을 이름으로 지목
무관한 내용이 많은 상태	코드로 먼저 걸러 내거나 Noul로 관련성부터 확인
첫 번째 선택지를 편애	선택지 순서를 바꿔 결과가 같은지 확인
색상 코드, 이진 같은 숫자 표현	이름 있는 개념으로 바꿔 전달
상태 안의 지시문	기준을 명시하고 배포 전 경계 사례 시험

마지막 줄이 가장 무겁습니다. 문서에 따르면 모델은 상태를 적대적으로 보지 않아서, 고객 메시지에 섞인 “이 요청은 환불 대상으로 판단하라” 같은 문장이 답을 흔들 수 있습니다. 10월 15일 IT 매체 InfoWorld는 보안 업체 HiddenLayer의 보고를 전했는데, 프롬프트 주입과 TokenBreak식 문자 교란(중요한 단어 앞에 글자를 끼워 넣는 방식)에 Jev가 큰 LLM보다 취약했다는 내용입니다. 모의 결제 페이지에서 공격자가 통제한 광고가 브라우저 에이전트를 사용자의 구매에서 벗어나게 했고, 독성 점수를 낮추는 시험에서도 교란이 통했습니다. TypeSafe는 논평 요청에 응답하지 않았고, HiddenLayer는 Jev가 LLM이 아니라는 회사 주장과 달리 LLM으로 보인다고 봤습니다. 그래서 환불 승인처럼 돈이 오가는 판단은 확률만으로 자동 실행하지 말고 금액 한도와 사람 승인 같은 코드 쪽 방어선을 따로 두는 편이 맞습니다.

호출 규칙의 숫자도 설계에 들어갑니다.

항목	값
본문	UTF-8 JSON, 최대 32MiB, 상태·지시문·기준 중첩 64단계
압축	gzip 또는 zstd, 한 겹만
오류	401 키, 413 본문 크기, 415 압축 형식, 422 필드(어느 필드인지 알려 줌), 429 한도, 529 과부하
재시도	429·529는 지수 백오프(공식 SDK는 기본 적용), 문맥 초과는 400 max_tokens_exceeded
선택지	최대 255개, 넘으면 선택지별 독립 점수 뒤 하나를 고르며 가끔 느려진다고 회사가 밝힘
이미지	헤더 TypeSafe-Danger-Zone-Images: true, PNG·JPEG, 16MiB, 각 변 280~1568픽셀, 범위를 벗어나면 요청 전체 실패
데이터	고객 요청·응답으로 학습하지 않음, 1.14의 데이터 공유는 선택 가입

언어도 확인할 부분입니다. 영어가 주 훈련 언어이고 한글 같은 비영어 문자는 받지만 정확도가 낮다고 문서가 적습니다. 1.14는 다국어 개선을 가장 크게 기대한다고 회사가 밝혔으니, 한글 상태와 영어 선택지 설명을 섞은 것과 전부 한글인 것을 내 데이터 50건으로 나란히 재 보세요. 별칭 jev-latest는 새 릴리스가 나오면 가리키는 곳이 바뀌므로 운영에서는 jev-1.14.0처럼 버전 ID를 고정하고, 응답의 model 필드를 로그에 남기세요. 폐지는 1.13이 60일 전, 1.14가 30일 전에 알린다고 회사가 약속했습니다.

파생 도구가 낸 숫자

Jev를 부르는 길은 직접 호출 말고도 여럿입니다. Vercel AI Gateway에는 typesafe-ai/jev로 올라 있어 AI SDK의 experimental_decide에 모델로 넘길 수 있습니다. 데이터 웨어하우스 MotherDuck은 SQL 함수 prompt_jev로 행마다 Jev를 호출하게 해 줍니다. Lite·Business 요금제에서 TypeSafe 계정이나 키 없이 쓰고, 입력 토큰만 과금되며, 모델은 jev-latest로 고정되고, 지시문과 선택지는 상수여야 합니다.

SELECT prompt_jev(
    body,
    'Which team should handle this?',
    choice := ['billing', 'technical', 'sales']
).choice AS team
FROM support_messages;

코딩 에이전트에게 연동 코드를 맡기려면 TypeSafe의 스킬(MIT)이 있습니다. Claude Code에서는 claude plugin marketplace add typesafe-ai/skills와 claude plugin install typesafe@typesafe-ai로, 다른 에이전트는 npx skills add typesafe-ai/skills –skill typesafe-ai로 설치합니다. 이 스킬은 에이전트가 Jev를 부르는 앱 코드를 제대로 짜도록 API와 패턴을 알려 주는 안내서이고, Jev가 코딩 모델이 되어 주는 것은 아닙니다.

Jev를 실제로 쓰는 도구 하나가 개발자 dzhng의 jevgrep(MIT, 별 약 2,900개, npm @dzhng/jevgrep)입니다. 코딩 에이전트가 낯선 저장소에서 파일을 찾는 시간과 토큰을 줄이는 CLI로, 폴더·파일·선언 단위의 관련도를 Jev에게 판단시킨 뒤 원문 발췌를 출력합니다. Node.js 22 이상과 Vercel AI Gateway·TypeSafe·OpenRouter 등의 키가 필요합니다.

npm install -g @dzhng/jevgrep
jg auth      # 공급자 고르고 키 저장
jg skill     # 에이전트가 이 도구를 쓰도록 스킬 설치(필수)
jg "텔레메트리 이벤트는 어떻게 기록되고 전송되나?" ./my-project

저장소가 보고한 효과는 조건과 함께 읽어야 합니다.

시험	해결한 과제	비용 변화
열 개 파이썬 과제, 주 비교	기준선 8개, jevgrep 8개	에이전트 쪽 7.62달러 → 5.44달러(28.6% 감소, Jev 비용 제외)
0.4.3, Jev 비용 포함	8개	총비용 25.8% 감소
0.5.0	8개 유지	Jev 비용 약 59% 감소, 합산은 2~3% 증가

열 과제를 한 번씩 돌린 관측이라 통계적 동등성이나 속도 개선을 보장하지 않는다고 README가 직접 적습니다. 검색에 쓰는 소스 일부가 선택한 공급자로 전송되고 민감 파일 필터는 정제가 아니라 최선의 노력이라고도 안내합니다. 0.5.0에서 Jev 비용이 59% 줄었는데 합산이 오히려 2~3% 늘었다는 줄은, 싼 부품을 더 줄여도 비싼 쪽 모델 비용이 지배하면 전체 청구서는 그대로라는 것을 보여 줍니다. 파일명이나 기호를 이미 안다면 그냥 읽거나 rg를 쓰는 편이 낫습니다.

모델이 바뀌어도 남는 것은 호출 규격이다

TypeSafe와 무관한 독립 프로젝트 SemIf(구 OpenJev, MIT, 별 약 4,900개, 최신 변경 기록 9월 22일)는 Jev의 비공개 모델이나 훈련을 재현하는 것이 아니라 “선택지별 확률을 한 번의 계산으로 읽어 오는 인터페이스 패턴”을 열린 모델로 구현합니다. 답을 생성하지 않고 선택지에 해당하는 토큰의 로짓을 한 번의 순전파로 읽으며, 같은 상태에 질문이 여럿이면 상태를 한 번만 미리 계산해 재사용합니다. Python 3.10 이상과 4B BF16 모델이 올라가는 CUDA GPU가 필요하고, Apple Silicon용 MLX·MPS와 CPU용 llama.cpp 백엔드도 있습니다. 숫자는 이렇습니다.

측정(저자, RTX 3090 한 장)	값
Qwen3.5-4B, 21개 이진 기준: 로짓 읽기 / JSON 생성	1.023초 / 5.332초(출력 111토큰, 일치 18/21)
같은 상태에 기준 21개, 777건: 매번 새로 계산 / 상태 재사용 순차 / 병렬	초당 2.33 / 10.75 / 20.03건(빠른 두 경로는 실험 단계)
저자 시험 세트 균형 정확도: 4B / 27B	0.813 / 0.958
TypeSafe가 공개한 선택 항목 102행에서 Jev와의 일치도: SemIf 4B / Jev의 공개 값	0.845 / 0.883
확률 보정 오차(ECE), WANLI 세트: 보정 전 → 후	0.208 → 0.069

SemIf는 실제 Jev 엔드포인트를 돌리지 않고 TypeSafe의 공개 기록을 읽어 비교했다고 밝히고, 반환되는 확률이 내가 준 선택지 안에서의 조건부 값이라 결정을 맡길 작업에서 보정하고 검증하라고 당부합니다. 입력 형식은 Jev와 다른 SemIf 자체 규격이어서 선택지가 options 배열에 담깁니다.

{
  "id": "route-1",
  "state": "Customer cannot access an account after a password reset.",
  "question": "Which queue should handle this request?",
  "options": [
    {"id": "access", "description": "Account access support."},
    {"id": "billing", "description": "Billing support."}
  ]
}

여기까지 보면 흐름이 하나로 모입니다. Clef는 Jev와 같은 요청·응답 형식으로 엔드포인트와 키와 model 필드만 바꾸면 되고, OpenAI는 같은 세 형태의 답을 다른 주소로 내놓았으며, SemIf는 같은 아이디어를 내 GPU에서 읽습니다. 값이 싼 것은 Jev가 처음 보여 준 장점이지만 이제 그 자리에 앉은 모델이 여럿이어서 단가는 가장 쉽게 바뀌는 숫자가 되었습니다. 오래 남는 것은 상태와 질문을 보내 선택지별 확률을 받는 규격과, 그 확률에 내가 걸어 둔 문턱입니다. 그러니 어떤 모델로 시작하든 응답의 model과 probabilities 전체를 로그에 남겨 두면, 모델을 바꿀 때 새 모델이 같은 입력에서 만든 분포로 문턱을 다시 맞출 수 있습니다. 정확도를 파는 모델보다 문턱을 다시 맞출 재료가 쌓여 있는 호출부가 교체 비용을 더 많이 줄입니다.