State: what you send Jev
TL;DR
stateis the single input every question in a request is evaluated against. It may be a string, a JSON object, or an array of text values — nothing else; no images, audio, or video. Prefer an object with descriptive field names. Budget: 64k tokens forstate+ all questions, and 32k tokens forstate+ the single longest question.
What it is
State is the content you ask a System One model to evaluate — a support message, a passage of text, or the current state of your application. You pass it in the state field of an API request, alongside the questions you want answered.
Each request evaluates one state against one or more questions. All questions see the same state and are evaluated independently. You can mix Choice, Score, and Noul questions in one request.
The docs' mental model: state is "the material you would present to a panel of experts before asking them to make a judgment."
Supported shapes
| Format | Useful for | Example |
|---|---|---|
| String | A message, article, or passage | "My card was charged twice." |
| Object | Named fields, related records, or application state | {"message": "My card was charged twice.", "order_id": "A-104"} |
| Array | A sequence of messages or records | ["Hi", "My customer number is TS1337.", "My card was charged twice."] |
The simplest state is a plain string:
state = "My card was charged twice."
In Python, pass the corresponding string, dictionary, or list directly to client.system_one(state=...).
Choose an object for most requests so each part of the state has a descriptive name and its relationships remain clear. A string is suitable when the use case is simple and requires only one piece of text.
A composite object is still one state
{
"ticket": {
"subject": "Duplicate charge",
"messages": [
{"from": "customer", "text": "I was charged twice for order A-104. Please refund the duplicate."},
{"from": "support", "text": "We are checking the charges."}
]
},
"order": {
"id": "A-104",
"charges": [
{"amount_usd": 49, "status": "captured"},
{"amount_usd": 49, "status": "captured"}
]
},
"refund_policy": "Duplicate charges are eligible for a refund."
}
This object is one state, even though it contains a conversation, an order, and a policy. Put related information together when the decision requires comparing those parts.
Limits and constraints
| Constraint | Value | Source |
|---|---|---|
| Total context per request | 64k tokens (state plus all questions combined) |
raw/docs/models.md |
| Per-question budget | 32k tokens for state plus the single longest question |
raw/docs/models.md |
| Input types | Text only: string, JSON object, or array of text values. No image, audio, or video input. | raw/docs/models.md, raw/docs/concepts__state.md |
| Language | English is the primary training language and where accuracy is best; other languages including CJK are accepted but not handled equally well | raw/docs/models.md |
Jev ingests the state once and evaluates every question against it in parallel, which is why the two budgets differ: the 64k budget covers state plus every question, while the 32k budget applies to state plus only the longest question. Practical consequence: a large state leaves each individual question a smaller allowance, and packing many short questions into one request is cheap under the 32k rule but still consumes the 64k total.
Pre-process non-text inputs (images, audio, video, binaries) into text or structured fields before sending them as state.
Best practices
- Separate content from questions. The state contains the content and supporting facts; questions define the judgments to make about that material. Keep the refund request and the policy in the state, then ask whether the customer requested a refund and whether the policy supports it.
- Send only relevant context. Include only what the current questions need; this helps the model avoid distractions and context rot. See How to build software with System One.
- Use nested JSON and name things. Descriptive keys let questions point at specific values. Reference a nested value from a question's
instructionswith a backticked dot-and-index path, e.g.`support.tickets[0].message`— include the backtick characters around each path inside the question text. - Do not rely on model weights for facts you own. Put current information from your own knowledge base into the state.
- Watch accuracy as the state grows. See Jev 1.13 jaggedness: known failure modes for how accuracy shifts with state size.
- Pay attention to confidence on non-English content; test on your own data before relying on Jev for a non-English workload.
Gotchas
- There is exactly one
stateper request. If you need two documents compared, put both inside one object — do not send two requests unless the decisions are genuinely independent. - Arrays are described as arrays "of text values" / "a sequence of messages or records". The conversation example in the docs nests objects inside an object; the array row's example is a flat list of strings.
- All questions see the whole state. There is no per-question scoping mechanism other than pointing at a path inside
instructions. - The 32k state-plus-longest-question limit is a separate ceiling from the 64k total: staying under 64k does not guarantee you are under 32k for a long question.
Related
- Primitives: Choice, Score, Noul — the questions asked about a state
- System One Models — what the model does with it
- How to build software with System One — decomposing state and questions
- Models, aliases, pricing, rate limits, context — context length, pricing, rate limits
- HTTP API: POST /v1/systemone and GET /v1/models — the request schema
- Jev 1.13 jaggedness: known failure modes — accuracy as state grows
- Speculative fan-out — packing many questions into one request
Sources
- raw/docs/concepts__state.md (https://docs.typesafe.ai/concepts/state)
- raw/docs/models.md (https://docs.typesafe.ai/models)