IronStratum Get an API key

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:

FactValueOwner of the number
PublisherKotoba Labsofficial model card
Parameters434Mthe 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 modelmicrosoft/deberta-v3-large, MITbase model card
ArchitectureDeBERTa-v3-large encoder, one pass, no text generationofficial model card
Context512 tokens total; the state is cut to 256official model card
LanguageEnglishofficial model card
LicenseApache 2.0, weights and codecard frontmatter and the Hugging Face record
Code and measurementskotoba-lang/typed-decisionsofficial model card
Runtime portofficial ONNX port, four variantsthe 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:

  1. choice: pick one option from a list you supply, up to 255 options.
  2. 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.
  3. 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:

  1. 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.
  2. Ask the identical question set over every piece, so the answers are comparable.
  3. 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:

SideWhat it carries
Requestthe 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
Responseper question: the typed decision, the full distribution, and a confidence value
Window law512 tokens total, state cut to 256; the caller chunks longer text and aggregates the per-piece answers
Metering basisinput 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.

SettingAccuracyBrierECE
in-domain (question types seen in training)0.8540.2130.022
banking77 intent, 77 options0.916
boolq yes-no0.879
sst5 level, 5 ordered0.599
out-of-distribution (new instructions, new option sets)0.6900.3990.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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

What the platform serves

Chat and reasoning models — context window, price per million tokens in and out and cached, capabilities
ModelContext$/1M in$/1M out$/1M cached inCapabilities
jev-batch5120.030.00—streaming

The same data GET /v1/models serves. A dash means the value isn't set.

Questions

What is open-jev-deberta-v3-large?
An open typed-decision model from Kotoba Labs. It is a 434-million-parameter finetune of the DeBERTa-v3-large encoder, published under Apache 2.0 with an official ONNX port. One piece of text, called the state, plus any number of typed questions go in. One forward pass returns a calibrated probability distribution for every question. Three question types exist. Choice covers up to 255 options. Score covers 2 to 10 ordered levels. Noul is a yes-no question. Nothing is generated, so an answer is always one of the options you supplied. The card states the boundary plainly. The model is an independent reproduction of the shape of TypeSafe AI's Jev. It is not affiliated with TypeSafe, and it uses none of their data or code.
Is this the batch classification used in SAP systems?
No, and the search results mix the two. In SAP S/4HANA, batch classification is a manufacturing term. It means assigning lot attributes to batches of material. When we checked the search results for a batch classification API, four of the top ten organic rows were SAP pages of that kind. This page is about text batch classification. That means many pieces of text, each carrying typed questions, scored by a language model in volume. If you arrived from the manufacturing side, that is a different job with different tools. The SAP documentation is the right place for it.
How does open-jev accuracy compare with Jev?
No like-for-like number exists, and the model card says so itself. Jev reports agreement with frontier models measured on private workflows. This model is measured on public gold labels. The two records are not comparable. Jev's weights are closed, which means nobody outside its publisher can put the same questions to both models. The record does state some numbers. On its own test set this model scores 0.854 accuracy on in-domain questions and 0.690 on out-of-distribution questions. On the third-party JevBench v1.4 board it ranked 56th. For an open model in this class with a published head-to-head against Jev, the sibling fast lane on this platform carries those figures.
What is the context limit, and how are longer documents handled?
The window is 512 tokens total. The card notes that the state, the text you submit, is cut to 256 tokens. The questions and their options share the rest. Longer documents are a chunk and aggregate job. Split the text into window-sized pieces. Ask the same questions over each piece. Then combine the per-piece distributions yourself, by majority, by weighted average, or by a rule you define. For scale, the platform's classification lanes that bill per page define a page as up to 2,000 tokens of submitted text. That spans roughly 4 to 8 of these encoder windows.
Can open-jev run in the browser?
Yes. The open-jev TypeScript library runs these models on-device, WebGPU where available and WebAssembly otherwise, with no server in the loop. The quantized build of this model is about 0.35 GB. The fp16 build is 0.88 GB and the fp32 build is 1.75 GB. One detail is worth knowing before you install. The library's default model is not this one. It is a smaller Qwen-based model with a longer 8192-token window. Pass the open-jev alias to load the DeBERTa model this page describes. The browser path serves interactive tools and single users. Server-side batch volume is the job this platform's lane is designed for.
Is there a hosted API for open-jev-deberta-v3-large?
We found no hosted service for it as of this page's verification date. The public ecosystem is a browser library, an official ONNX port for local runtimes, an official code and measurement repository, and unofficial weight mirrors. This platform has a lane planned under the alias jev-batch. Its row sits behind the public list, the rate is set, and no launch date is promised; this page is its written record. When the row joins the public list, the lane answers on the platform's chat route family with the typed-decision contract described on this page.
How do jev-batch, jev-fast, and jev-causal differ?
Three planned lanes, one job shape. jev-fast is the low-latency decision lane, built on the flagship open encoder of this class. jev-causal is the causal fallback, a small generative decision model for states and question shapes an encoder window cannot hold. jev-batch, this lane, is the batch text classification lane. It takes the same typed questions over document volume, where the encoder's one-pass-per-state economics matter most. Routing is flagship-first. The causal lane sits behind it for what the encoder cannot hold, and the batch lane carries volume work. All three belong to the platform's classification family, and none of them is currently offered.