In this analysis
A larger question limit changes the request envelope without proving concurrency, semantic independence or partial-failure behavior.
A larger question batch can reduce repeated request setup while making more decisions share one delivery boundary. The Decisions API’s GA expansion therefore deserves an application-level reading: a higher limit changes packaging, but it does not automatically establish independence or failure isolation.
The limit changed during the release sequence
Sol and Luna launched on September 22, 2026. The changelog records Decisions beta on October 6, 2026. The October 22, 2026 GA announcement increased the question limit from 200 to 400. This is a documented capacity change, not a measured throughput result for any private workload.
Shared context can hide different evidence scopes
Imagine classifying a collection of support records against one policy. Shared instructions can be useful, but the records may belong to different product revisions. If the application places the wrong common policy above the entire batch, every correctly formatted answer can inherit the same mistaken assumption.
Keep question identity and governing evidence explicit. Grouping requests should not erase which source version applies to each item. A batch is an application packaging choice; it is not proof that all questions have the same semantic context.
Capacity is different from concurrency
A maximum question count does not tell an application how the provider schedules internal work or how long a particular batch will take. Those are implementation and workload questions requiring appropriate observation.
Likewise, a larger batch does not define the most useful review unit. A reviewer might accept some decisions and investigate others. Preserve their identities rather than replacing the collection with one unqualified success flag. This keeps application acceptance separate from transport completion.
A failure-boundary fixture
Prepare illustrative questions with ordinary inputs, conflicting evidence and a deliberately malformed case permitted only in the test environment. Observe how the selected client and endpoint report the outcome. Do not assume partial-result behavior that has not been documented or observed.
Retain returned question mappings and unresolved cases. If a retry is necessary, distinguish recomputing a decision from repeating a downstream action already applied from an earlier result. The latter belongs to the application workflow and needs its own state record.
What the expanded limit supports
The GA limit supports considering larger request groups. It does not justify universal batch sizes, promised latency reductions or a claim that one bad input cannot affect other results.
The retrospective lesson is to connect packaging with evidence scope and recovery. A useful batch record preserves each question’s identity, applicable context and accepted outcome, allowing the application to explain what the larger envelope actually changed.