MimoGeneral

Description

MimoGeneral is an agentic environment for general knowledge work and terminal tasks. It ports the general configuration of Xiaomi's MiMo-V2.6-RL-oss dataset, which contains two task families that the environment dispatches on automatically:

• terminal_bench (64 tasks) — Terminal-Bench-style repository tasks. The agent works in /app; on submit the environment materialises the task's hidden test files, runs test.sh (an anti-hack guard plus a pytest suite), and reads the reward the harness writes to /logs/verifier/reward.txt. Self-contained and deterministic.
• general_agent (925 tasks) — enterprise knowledge-work tasks. The agent works in /work/workspace against a set of mock enterprise systems, each exposed as an MCP server started inside the sandbox, plus workspace documents, and writes a final answer to answer.md. Grading is a tier-weighted rubric over the task's verifier_meta.json.

Capabilities

• Diagnosing and fixing real repositories under a hidden test suite (terminal_bench)
• Querying structured enterprise systems through an MCP tool interface (general_agent)
• Reconciling documents and system-of-record data to reach a defensible conclusion
• Producing a rubric-graded written answer

Compute Requirements

Each task runs in an OpenReward sandbox booted from the task's public Docker image (65 distinct images across the corpus). The default machine size is 2 CPUs and 4 GB of RAM. terminal_bench runs with networking disabled; general_agent enables networking so the in-sandbox MCP servers and the rubric judge can operate.

License

MIT.

Tasks

There are 989 tasks, exposed as two splits:

• train — all 989 tasks (both families).
• test — the 64 terminal_bench tasks, which are self-contained and need no external data preparation; a convenient smoke subset (not a held-out evaluation set).

Reward Structure

Before grading, every process the agent started in the sandbox is stopped.

• terminal_bench: binary and verifiable. The environment clears /logs/verifier, materialises the hidden tests, runs bash /tests/test.sh under the task's verifier time limit, and reads the reward the script writes to /logs/verifier/reward.txt (1.0 on pass, 0.0 otherwise, including anti-hack-guard rejections). A run that exceeds the time limit scores 0.0; a run that writes no reward is a grader fault and raises. No LLM grader.
• general_agent: the reward is a weighted fraction of the rubric items in verifier_meta.json. Items are weighted by their explicit weight when present (including 0), otherwise by tier (critical > important > sanity).
  • method: "llm" items carry a question and a ground-truth anchor; a gpt-5-mini judge decides pass/fail per item from answer.md (called without a temperature parameter, 4000 output tokens, retried up to 4 times; a judge that still gives no verdict raises instead of scoring 0).
  • method: "rule" items run the task's own deterministic check_code (with its _helpers.py), the way the dataset's verify.py does, against the post-run state: the system databases and every added or changed workspace file are copied out of the sandbox, and the checks run on the environment server in a fresh interpreter with a timeout. The pre-run baseline that some checks diff against (state.db.pinned_backup) is the task's pristine database, not a file from the sandbox. Rule scores are fractional when a check returns one.

Fidelity note. The upstream general_agent LLM grader (office_gen.grade_rubric) is not published, so the llm-item judge here is a reconstruction by the General Reasoning team over the published rubric content. The rule items run the published check code. Differences from the dataset's sidecar verify.py: missing item weights default to tier weights here (upstream uses 1.0); LibreOffice formula recalculation (recalc_xlsx, used by a few checks) is not available on the grading server, so those checks read the workbook's cached values; and because the mock systems run inside the agent's sandbox rather than a separate container, the agent can also change their databases directly. The dataset's gate items and source-protection gate are not used by any task. terminal_bench grading is the upstream contract exactly.

Known Limitation (general_agent MCP servers)

Live testing confirmed the general_agent data path and grading work end-to-end: the per-task workspace and system databases upload into the sandbox, and the reconstructed rubric judge produces a discriminating per-item score. However, the MCP servers currently do not start, so the mcp_call tool is non-functional and the agent can only use the workspace files, not the connected systems. Root cause: the general-agent image ships mcp 2.x, but the dataset's vendored MCP stack (mcp_http.py servers and mcp_bridge.py client) is mcp v1 code (from mcp.server.fastmcp import FastMCP, which 2.x renamed) — and sidecar_entrypoint.py launches servers via an interpreter path that does not exist in the OSS image. The environment repairs the interpreter path and attempts to pin mcp<2 at setup, but the sandbox cannot reach PyPI (connection to pypi.org times out), so the downgrade fails and the v1 servers cannot import. Making mcp_call work requires a base image with mcp<2 (and the MCP tool dependencies) pre-installed. The test split (terminal_bench) is unaffected.

Data

Task metadata for both families is sourced from the general configuration of XiaomiMiMo/MiMo-V2.6-RL-oss and vendored as a parquet file; the terminal_bench test payloads are embedded in it. The general_agent per-task directories (workspace documents and MCP system databases) are large across the whole corpus and are not vendored — run prepare_data.py to download them from the dataset into the data mount (/orwd_data/envs on the platform, or general/data/envs locally). Docker images are public on Docker Hub as docker.io/xiaomimimo/mimo-v2.6-rl-oss:<tag>, resolved from the vendored image-mapping.jsonl; the OpenReward platform pulls them at run time.

Tools

• bash, view, str_replace, insert, create — shell and file editing.
• mcp_call (general_agent only) — query a connected system's MCP server; use tool="__list__" to discover a server's tools.
• submit — grade the task and end the episode. For general_agent, a submit with a missing or empty answer.md is not graded and does not end the episode; the agent is told where to write the answer and can submit again.

Other Environment Requirements

The environment boots a sandbox, so the session secrets must provide an OpenReward API key (api_key). general_agent tasks additionally require a judge API key for the rubric judge (openai_api_key or chat_api_key); terminal_bench tasks need no judge key.

Safety

terminal_bench agents edit code inside an isolated sandbox graded by a hidden suite with an anti-hack guard. general_agent agents interact only with mock enterprise systems inside the sandbox. Neither presents direct safety risks.

Citations

The tasks are from Xiaomi's MiMo-V2.6 open RL release:

@misc{MiMoV26RLoss,
  author       = {{LLM-Core Xiaomi}},
  title        = {MiMo-V2.6-RL-oss: Agentic RL Environments},
  year         = {2026},
  publisher    = {Hugging Face},
  howpublished = {\url{https://huggingface.co/datasets/XiaomiMiMo/MiMo-V2.6-RL-oss}}
}

The OpenReward environment (and the reconstructed general_agent rubric judge) is by the General Reasoning team:

@dataset{GRMimoGeneral,
  author    = {General Reasoning Inc. Team},
  title     = {MimoGeneral},
  year      = {2026},
  publisher = {OpenReward},
  url       = {https://openreward.ai/GeneralReasoning/MimoGeneral}
}