jev-batch: open-jev-deberta-v3-large batch text classification, planned as a metered lane
jev-batch is this platform's name for a planned batch lane built on open-jev-deberta-v3-large. That is a 434-million-parameter open model from Kotoba Labs, a DeBERTa-v3-large encoder finetuned to answer typed questions about a piece of text. One state, the model's word for the text you submit, plus any number of typed questions go in. One forward pass returns a calibrated probability distribution for every question. Nothing is generated. The lane's row sits behind the public list on this platform. Nothing answers under the alias, and no date is promised. This page is the lane's written record. It carries the model's identity and measured record with every number's owner named, the window mechanics that shape document work, and the call shape the lane is designed to answer.
Last verified: 2026-09-25
What it is
The identity facts, each traced to where it comes from:
| Fact | Value | Owner of the number |
|---|---|---|
| Publisher | Kotoba Labs | official model card |
| Parameters | 434M | the Hugging Face record; the published fp32 weights file is about 1.74 GB, which is what 434 million parameters weigh at four bytes each |
| Base model | microsoft/deberta-v3-large, MIT | base model card |
| Architecture | DeBERTa-v3-large encoder, one pass, no text generation | official model card |
| Context | 512 tokens total; the state is cut to 256 | official model card |
| Language | English | official model card |
| License | Apache 2.0, weights and code | card frontmatter and the Hugging Face record |
| Code and measurements | kotoba-lang/typed-decisions | official model card |
| Runtime port | official ONNX port, four variants | the port's own card |
The contract in plain language. You send one state and a list of questions. Each question is one of three types:
- choice: pick one option from a list you supply, up to 255 options.
- score: place the text on an ordered scale of 2 to 10 levels you name; the answer is the expected level and can fall between levels.
- noul: a yes-no question; the answer is the probability of yes.
Every answer carries the full distribution over the options you supplied and a confidence value. The confidence value is the highest probability after temperature scaling. Because the model picks rather than writes, an answer is always one of your options. The card puts it as a structured-output error rate of zero by construction. For a pipeline, that is the whole appeal of the shape. No parsing failures at the answer layer, ever.
Two boundaries keep the record honest. First, this is not Jev. TypeSafe AI released Jev, the System One model, in September 2026 with closed weights and no self-host path. This model is an independent reproduction of that shape, and the card states the boundary itself. It is not affiliated with TypeSafe and uses none of their data or code. Its numbers are not comparable, because Jev reports agreement with frontier models on private workflows while this model is measured on public gold labels. Second, there is no public specification of Jev's interface. The official repository reconstructed the shape from public material. Wire compatibility with Jev is therefore a best-effort reproduction, not a certified match.
One warning before you download anything. The search results and the model hubs carry a crowd of unrelated repositories with openjev and open-jev in their names, from several different publishers. At least one unofficial mirror of this exact model sat in the top five results when we checked. Pin the publisher, com-kotobalabs, and the revision you tested. Weights that arrive by name alone are a supply-chain gamble.
A note on the title of this page. In SAP S/4HANA, batch classification means assigning lot attributes to batches of material. Pages about that manufacturing function own much of the search results for the bare phrase. This page is scoped the other way, to text. That means batch classification of documents and messages with a language model. The word text in the title is there to keep that promise.
Use cases
The lane's profile has four parts. A fixed question set, high volume, a cost that has to stay sane per text, and no free-form output wanted. The model's training domains map straight onto the work it is built for.
- Support-intent triage at volume. The card's own worked example is a banking support message asked three questions at once: which product area (a 10-option choice; the model saw a 77-option intent set in training), how positive the sentiment, and whether the customer is asking for a refund. One pass answers all three.
- Ordered-level scoring on reviews and feedback. The score type places text on a scale you define, two to ten levels, with the expected level returned between levels when the text sits between them.
- Yes-no checks over passages. The noul type answers reading-comprehension questions of the form: does this passage support this statement.
- Batch tagging for search and RAG ingestion. Label every chunk before or after embedding: topic, language register, policy flags, domain tags, all in the same pass over the same state.
- Second-opinion verification and escalation. Run the cheap encoder pass over a whole corpus and escalate only the rows whose confidence falls under your threshold to a heavier model. The confidence field exists for exactly this, with one caveat the card states: on unseen question shapes the model is over-confident by a small margin, so calibrate the threshold on your own data before you trust it.
Where it does not fit, from the card's own limitations. Documents that must be read whole rather than windowed are out; the context law is below. Any language other than English is out. Question shapes far from your measured set need testing first. It also cannot produce generated reasons or free text, because it does not generate at all.
The window, the page unit, and chunk and aggregate
The context is 512 tokens total, and the state is cut to 256 of them. Questions and their options share what remains. That split is the single most important fact about this model at document scale. It is documented nowhere in the ranking results except as a table row in a browser library.
For text longer than a window, the job is chunk and aggregate, and the mechanics are the caller's to own:
- Split the document into window-sized pieces. At the full 512-token window, a 2,000-token document needs four passes; if each pass holds the state to the card's 256-token cut, up to eight.
- Ask the identical question set over every piece, so the answers are comparable.
- Combine the per-piece distributions by a rule you define: majority over the chosen options, a weighted average of the score levels, a threshold on noul probabilities, or an escalation flag when pieces disagree.
For a sense of scale against platform units, one comparison helps. The classification lanes on this platform that bill per page define a page as up to 2,000 tokens of submitted text, rounded up. One such page spans roughly 4 to 8 of these encoder windows. Aggregate the distributions, not just the top answer per piece. A page where five windows agree at moderate confidence and three disagree sharply is a different fact than a page where eight windows agree.
The three-lane family
This platform plans three lanes for the Jev-class shape, and the split is deliberate. jev-fast is the low-latency decision lane, built on the flagship open encoder of this class. That is the one with a published head-to-head against Jev. jev-causal is the causal fallback. It is a small generative decision model for states too long for an encoder window and question shapes that need composition rather than selection. jev-batch, this page's lane, is the volume lane, where the encoder's one-pass economics matter most. Routing is flagship-first. The causal lane sits behind it for what the encoder cannot hold, and the batch lane carries the corpus-sized work. All three sit in the platform's classification family, written but not on the public list. The family page and the models index carry the catalog's state as it changes.
Browser, self-host, or a metered lane
Apache 2.0 means every road is open, and for this model the roads are unusually well built.
The browser road first. The open-jev TypeScript library runs this model on-device, WebGPU where the browser has it and WebAssembly otherwise, with typed answers in code. The quantized build is about 0.35 GB, fp16 is 0.88 GB, fp32 is 1.75 GB. Know the default before you install. The library loads a smaller Qwen-based model with an 8192-token window unless you pass the open-jev alias. That is a different model with different behavior, not a size setting.
The self-host road is next. The official repository publishes the training recipe, the corpus builder, the ablations, and the full measured record. The ONNX port ships four variants for ONNX runtimes. Pin the revision, use the publisher's repository, and hold the model to the card's own limits. Those limits are English text, measured question shapes, and recalibrated confidence.
The metered lane is what this page exists to describe. What a hosted batch lane sells over the weights is the runtime, the metering, and the operations around both. That means a route that stays up, a spend boundary that stops at the wallet, and a per-text cost you can put in a budget. This platform's lane is written, not open. The contract below is the design, and the row, the rate, and the date all arrive together or not at all.
The economics, stated without numbers because the tabs carry the contract, not the price; the starting rate rides this page's search listing until the row joins the public list. An encoder reads the state once and scores every question inside the same single pass. A generative route reads the prompt and writes an answer, token by token, for every question. At two questions the difference is small. At a fixed question set over a hundred thousand texts, the pass-per-state shape is the reason an encoder batch lane exists at all. It is why this lane sits at the volume end of the family.
API usage
The lane is designed to ride the platform's chat route family. The shape is an OpenAI-compatible POST /v1/chat/completions envelope, a console key in the Authorization Bearer header, and the typed-decision payload as the user content. That route is a design ruling, not a served fact. While the row sits behind the public list, requests for the alias jev-batch are refused, and no amount of well-formed payload changes that. What the tabs show is the working contract. An integration can be written and reviewed before the row joins the public list.
The contract:
| Side | What it carries |
|---|---|
| Request | the state as text; the questions as a typed list: choice with options (up to 255), score with 2 to 10 named levels, noul as a plain yes-no statement |
| Response | per question: the typed decision, the full distribution, and a confidence value |
| Window law | 512 tokens total, state cut to 256; the caller chunks longer text and aggregates the per-piece answers |
| Metering basis | input tokens, the same unit the family's other lanes use; the rate rides this page's search listing until the row joins the public list |
Three things the tabs deliberately omit. No price in the tabs, because the catalog surfaces publish the rate, never a typed-in page. No availability claim, because the lane is pre-launch. No date, because none has been set. The exact field surface of the adapter, whether the payload travels as a JSON string in the user message or as structured content blocks, is pinned when the row joins the public list. The envelope, the route, and the alias are fixed.
curl
curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "jev-batch",
"messages": [
{
"role": "user",
"content": "{\"state\": \"I was charged twice for the same order and nobody answers my emails. I want my money back now.\", \"questions\": [{\"type\": \"choice\", \"instructions\": \"Which product area is the message about?\", \"options\": [\"fees & charges\", \"refund & dispute\", \"card\", \"other\"]}, {\"type\": \"noul\", \"instructions\": \"The customer is asking for a refund.\"}]}"
}
]
}'
One state, two questions, one pass: the answer carries a decision, a distribution, and a confidence for each question. In production the state is one window of your document, and the questions array is the same fixed set for every window.
python
import json
import os
import requests
questions = [
{
"type": "choice",
"instructions": "Which product area is the message about?",
"options": ["fees & charges", "refund & dispute", "card", "other"],
},
{"type": "noul", "instructions": "The customer is asking for a refund."},
]
payload = {
"state": "I was charged twice for the same order and nobody "
"answers my emails. I want my money back now.",
"questions": questions,
}
resp = requests.post(
"https://api.ironstratum.com/v1/chat/completions",
headers={"Authorization": "Bearer " + os.environ["KEY"]},
json={
"model": "jev-batch",
"messages": [{"role": "user", "content": json.dumps(payload)}],
},
timeout=60,
)
resp.raise_for_status()
body = resp.json()
print(body["choices"][0]["message"]["content"])
print("usage:", body["usage"])
For a document job, wrap this in the chunk loop. Split to the window. Keep the question list identical across windows. Aggregate the distributions. Keep the per-window confidence so your escalation rule has something to read.
openai-sdk
The route is OpenAI-compatible, so the SDK you already run moves over with a base URL and a model id:
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.ironstratum.com/v1",
api_key=os.environ["KEY"],
)
payload = {
"state": "I was charged twice for the same order and nobody "
"answers my emails. I want my money back now.",
"questions": [
{
"type": "choice",
"instructions": "Which product area is the message about?",
"options": ["fees & charges", "refund & dispute", "card", "other"],
},
{"type": "noul", "instructions": "The customer is asking for a refund."},
],
}
response = client.chat.completions.create(
model="jev-batch",
messages=[{"role": "user", "content": json.dumps(payload)}],
)
print(response.choices[0].message.content)
print("usage:", response.usage)
Client code written against the OpenAI SDK needs two changes to point here: where it sends requests, and the model id. The API reference carries the route family's parameter surface.
Benchmarks
This platform has run no measurements on this model: no lane serves it here, so there is nothing of ours to measure. Two evidence layers follow, each dated and each labeled with who ran it.
The publisher's own record, from the model card, read 2026-09-24. Test set: 1,500 states and 3,508 questions. The out-of-distribution set holds 4,012 never-seen questions on the same states.
| Setting | Accuracy | Brier | ECE |
|---|---|---|---|
| in-domain (question types seen in training) | 0.854 | 0.213 | 0.022 |
| banking77 intent, 77 options | 0.916 | ||
| boolq yes-no | 0.879 | ||
| sst5 level, 5 ordered | 0.599 | ||
| out-of-distribution (new instructions, new option sets) | 0.690 | 0.399 | 0.035 |
The out-of-distribution detail rows read as follows. Negated boolq questions score 0.83. A new five-way split of the banking topics scores 0.61. New ordered level sets score 0.45 against a 0.26 majority baseline. That makes new level sets the weakest shape, barely above always-guessing-the-majority. Across three training seeds the in-domain score is 0.847 with a spread of 0.005. The out-of-distribution score is 0.678 with a spread of 0.012.
Speed comes publisher-measured on their hardware, labeled as such. On an M1 Max laptop CPU, four questions take 1.8 seconds. On an H100 in bf16, ten questions on one state take 28 milliseconds end-to-end, 25 of them the forward pass. At batch size 8 the rate is 518 questions per second. Those are their numbers on their machines. They are evidence of the shape's speed class, not a promise about any deployment.
The third-party record is JevBench v1.4, the class benchmark run by Benchmark Heaven, posted 2026-09-23. On that board open-jev-deberta-v3-large ranked 56th at 12.65, down from 42nd in v1.3. The operator's method notes for v1.4 list 308 fresh sealed decisions, an equal-weight harmonic mean, and separate speed and cost gates. The number that explains the gap is sealed accuracy of 29.5 percent against 52.4 percent on the public slice.
Read the three layers together, because they tell one story. Sealed decisions are questions nobody has seen. That is exactly the out-of-distribution weak spot the card names when it says the model reads the question only partly. In-domain, with question shapes like the ones it was trained on, it is strong, calibrated, and fast. Off the trained shapes, accuracy drops by 16 points by the publisher's own measurement and further on sealed third-party questions. Confidence runs hot by a small margin there. The honest buying rule is simple. Measure it on your questions, on your text, before you commit a corpus. Calibrate the confidence threshold on that same run. When this platform's lane lands, its own measurement program publishes with it. Those numbers will sit next to these with their dates attached.
Getting started
- Evaluate the model now. Read the model card with its full measured record, walk the official repository for the recipe and ablations, or run one decision in your browser with the open-jev library in a few lines of TypeScript.
- Join through the console's invite flow. The platform runs as an invite-only beta in this phase; the console signup holds the wallet, the keys, and the spend history.
- Cut a key when the account is active. Keys stand alone and are revocable on the spot, so one key per project keeps a leak to a rotation. The wallet balance is the ceiling on spend.
- When the row lands, the curl tab is the whole first call. A key, the alias, one state. The classification family page and the models index carry the catalog's state as rows arrive, and the API reference documents the route family the lane rides.