State and fan-out

state is the context mouse-1 reads before scoring your questions. You pass it in the top-level state field of POST /v1/systemone alongside a map of questions.

Every question in a request evaluates the same state in parallel and in isolation.

Structuring state

state accepts a plain string, a JSON object, or a JSON array up to 65,536 tokens.

Format	Best for	Example
String	A single message, log excerpt, diff, or passage	"Customer says: my card was charged twice for order #1042."
JSON Object	Named fields, agent state, tool proposals, and untrusted inputs kept in separate keys	{"task": "Clean build cache", "proposed_cmd": "rm -rf ./tmp/cache", "git_status": "clean"}
JSON Array	Ordered sequences of turns, events, or candidate items	[{"round": 1, "error": "TS2345"}, {"round": 2, "error": "TS2345"}]

Use a JSON object whenever your decision depends on comparing two or more pieces of context (for example, comparing a user's task against a proposed_command, or comparing a claim against a test_log). Naming each piece of evidence keeps its provenance clear and prevents untrusted text in one field from masquerading as instructions in another.

Referencing nested state fields by path

When state is a nested JSON object or array, point a question at specific fields using a backticked dot-and-index path inside instructions:

{
  "model": "mouse-1",
  "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 captured charges on the same order are eligible for an automatic refund."
  },
  "questions": {
    "refund_requested": {
      "type": "noul",
      "instructions": "Does `ticket.messages[0].text` request a refund?"
    },
    "policy_supports_refund": {
      "type": "noul",
      "instructions": "Does `refund_policy` allow the refund requested in `ticket.messages[0].text`, given `order.charges`?"
    }
  }
}

Keep only relevant context in state

Include the fields that bear on the questions you are asking, and omit unrelated repository dumps or full environment variables:

• Faster and cheaper: Latency and cost scale with state_tokens.
• Higher signal-to-noise: Focused states avoid diluting attention across thousands of irrelevant lines.
• Never silently truncated: If state exceeds 65,536 tokens, mouse-1 refuses the request with 422 state_too_long and bills $0 rather than silently truncating the tail of your input.

Speculative fan-out

In a single POST /v1/systemone request, mouse-1 runs a single prefill pass over state and scores up to 128 questions in parallel:

1. state is billed once: In a 2,000-token state, adding 5 extra questions adds only ~150 question_tokens + framing_tokens—making 6 questions in one call ~5× cheaper and ~5× faster than 6 sequential calls.
2. Questions are strictly independent: Question A never sees Question B or its answer. Adding, removing, or rewording one question never alters the probability distribution of any other question in the same request.
3. Ask speculative questions upfront: Include follow-up questions whose answers only matter on certain branches (for example, asking bug_severity and refund_requested in the same call as department), then ignore the unused answers in your if/switch logic.

const { answers } = await decide(
  {
    user_prompt: "Deploy the staging branch to production",
    git_status: "2 uncommitted files",
    ci_status: "passing",
  },
  {
    intent: {
      type: "choice",
      instructions: "What is `user_prompt` asking the agent to do?",
      criteria: {
        deploy: "Deploy or release to an environment",
        code_edit: "Modify or refactor source files",
        question: "Answer a question about the repository",
      },
    },
    is_production_target: {
      type: "noul",
      instructions: "Does `user_prompt` target a production environment?",
    },
    workspace_clean: {
      type: "noul",
      instructions: "Does `git_status` indicate a clean working tree with zero uncommitted files?",
    },
  },
);

if (answers.intent.choice === "deploy") {
  if (answers.is_production_target.noul >= 0.5 || answers.workspace_clean.noul < 0.8) {
    await promptHumanConfirmation("Production deploy with uncommitted files requires approval.");
  }
}

When to make a second request

Because questions in a single request are evaluated in parallel, make a second request only when the first answer is required to construct the second request's state or criteria—for example:

• Ranking 200 skills in Request 1, fetching the full documentation of the top 3 winners, and verifying them in Request 2.
• Walking a deep taxonomy tree level by level where the chosen top-level branch determines which child options to pass next.

5-minute prefix caching

When your harness evaluates a second request with a repeated state from the same account—typically within 5 minutes (300 seconds), best effort in GPU memory—the worker serves the cached tokens at the discounted rate:

• Structure for cache hits (rubric first, item last): JSON key order in state is preserved exactly as sent (sort_keys is not applied). Put shared rubrics, schemas, or policies first and the varying item last.
• Cached tokens are billed at $0.02 / 1M (an 80% discount from $0.10 / 1M, with no cache-write fee).
• Prefix cache entries live only in GPU memory, are scoped per tenant so another account can never probe your cache state, and are never written to disk (Zero Data Retention). You can track your actual cache hit rate in /console/usage.