[RFC]: Support openjev/openjev in System1-Omni — community help wanted #95

Motivation

Add support for openjev/openjev, a Qwen3.5-based decision model for text, web state and screenshots. It exposes typed choice, score and noul answers by reading candidate-letter scores at the first output position.

This is a separate checkpoint and inference contract from the already supported ZefanCai/Open-Jev-27B-v1.1 (#54, #55). That worker uses an independent prompt per candidate and a trained scalar head; it cannot load this release as a replacement.

This RFC invites community feedback and contributors for a native integration. The upstream vLLM + helper setup provides a reference implementation.

Proposed Change

Initial scope and reference

Start with a native Rust/CUDA text worker for choice, score and noul. Use one prompt per question and an explicit initial limit of 52 options and 16,384 prompt tokens. Reject unsupported inputs and larger option sets clearly. Screenshot execution and the helper's multi-pass handling of more than 52 options are follow-up milestones, unless contributors propose including them in the first slice.

Freeze the following sources when implementing:

• System1-Omni baseline: main at 7f39ac4.
• Model, tokenizer and helper: openjev/openjev at ac97900.
• Contract reference: helper/shim.py and serving guide. Use the guide's explicit calibration and instruction-rendering settings rather than the helper's different defaults.

Execution and ownership

• Add a distinct model processor/executor and recipe. Preserve existing Open-Jev-27B-v1.1 identifiers and behavior.
• Reuse the shared Qwen text backbone and CUDA operations. Cua-S1's selected-letter projection is a useful starting point, but this checkpoint has untied output weights: read the candidate rows from lm_head.weight, not the input embeddings.
• Preserve the helper's prompt layout, exact candidate token IDs, option order, instruction/state rendering, calibration, confidence, score expectation and token accounting. Return scores for every requested candidate; raw top-K vocabulary results are insufficient.
• Keep prompt preparation and response calibration in the processor, weight loading/forward/readout in the executor, and reusable hardware operations in the backends. Use the current serial runtime and worker interface; adding this model does not require implementing the planned shared dynamic batcher.
• Serve POST /v1/systemone and real GET /health behind the existing frontend. Readiness follows checkpoint initialization and a successful warmup inference.

Alternatives and impact

vLLM + upstream helper: the shortest reference path and a possible external-worker recipe. Frontend readiness needs an adapter because the helper does not expose the worker's /health contract.

Native worker: reuses project execution infrastructure and allows focused optimizations. Numerical fidelity must be established before optimization or speed claims. Selecting LM-head rows may avoid a full-vocabulary projection; actual memory and latency require measurement. Native screenshot support additionally needs the vision encoder and image processing.

The existing public request envelope can remain unchanged. Unsupported modalities and limits must be documented. This RFC makes no native performance claim.

Validation and acceptance

• CPU fixtures match the pinned helper's prompts, token IDs and response calculations, including all question types, structured instructions, option ordering, boundary cases and errors.
• Reserved-GPU checks compare complete native text decisions with the pinned reference. Declare numerical tolerances first and report probability drift, discrete disagreements and worst cases.
• Compare implementations on the same checkpoint, GPU, precision, requests, concurrency and cache policy. Use repeated measured runs under the benchmark protocol; retain raw results and separate preparation, startup, warmup and inference. The upstream FP8 recipe and a native BF16 implementation must not be presented as an isolated runtime comparison.
• Add setup, launch, example requests, limits and validation evidence; update supported-model documentation after integration lands.

Community help wanted

Contributors are welcome to take a small part:

• Contract and fixtures: reproduce the helper's prompt/readout/calibration behavior; CPU-only work is useful.
• Rust/CUDA integration: checkpoint loading, selected LM-head projection and shared Qwen execution.
• Independent validation: reproduce correctness and serving measurements on available NVIDIA hardware.
• Multimodal follow-up: vision preprocessing/execution and screenshot parity.
• Recipes and examples: clear installation, first-request walkthrough and an agent use case.

Please comment with the area you would like to help with, any relevant hardware, and your proposed first step. Design review and small PRs are welcome; nobody needs to own the entire integration.

Feedback Period

Initial feedback through 2026-10-13; contributions and follow-up discussion remain welcome afterward.

Feedback requested: native-text-first scope versus an external-worker recipe first; initial option limits versus immediate multi-pass compatibility; and how to share selected-letter projection without conflating model-specific contracts.

Anything else

Related: #83 (model tracker), #54/#55 (existing scalar-head Open-Jev integration), #85 (shared-observation proposal), and #87 (demo for the existing Open-Jev worker).

The upstream model card lists CC BY-NC 4.0 for the weights and Apache 2.0 for the helper/serving files. Preserve the relevant attribution and license notices.

Preparation for this RFC inspected repository code, checkpoint metadata and helper source. No model weights were loaded, no GPU inference or benchmarks were run, and no implementation is claimed.

Before submitting a new issue

• Searched existing issues and PRs and reviewed the architecture, contribution guide, supported-model documentation and RFC template. No issue or PR specifically tracking openjev/openjev support was found.