N/llm Module Adds ReasoningEffort Enum to Control GPT OSS Token Usage

What changed

Starting in 2026.2, the N/llm module includes a new llm.ReasoningEffort enum with three values:

• ReasoningEffort.LOW — Minimal reasoning. Fastest responses, lowest token/AI Unit cost. Use for straightforward, time-sensitive tasks.
• ReasoningEffort.MEDIUM — Balanced reasoning. This is the default when no value is specified. Suitable for general-purpose tasks requiring some analysis.
• ReasoningEffort.HIGH — Thorough reasoning. Highest quality for complex, multi-step problems at the cost of more tokens, more AI Units, and longer response times.

The enum is passed via the options.modelParameters.reasoningEffort parameter (or the top-level reasoningEffort shorthand shown in the docs) on both llm.generateText(options) and llm.generateTextStreamed(options).

Scope: This applies only to GPT OSS models. Other model families exposed through N/llm will ignore the parameter. The feature is limited to server-side script types (Scheduled, Map/Reduce, Suitelet, RESTlet, User Event, Workflow Action, etc.).

Governance & cost implications

Higher reasoning effort increases internal chain-of-thought token generation, which means higher NetSuite AI Unit consumption per call. Oracle's documentation does not publish exact multipliers, so you should benchmark AI Unit usage at each level against your allocation before choosing HIGH for high-volume workflows.

Code example

const response = llm.generateText({
  prompt: "Summarize this sales order for the customer.",
  reasoningEffort: llm.ReasoningEffort.LOW
});

What to do

1. Audit existing N/llm calls. Any script already calling llm.generateText or llm.generateTextStreamed against a GPT OSS model is implicitly using MEDIUM reasoning. No breaking change, but you should evaluate whether LOW is sufficient to reduce AI Unit spend.
2. Set reasoning effort explicitly in production scripts rather than relying on the default. This makes cost expectations clear to future maintainers and prevents surprises if Oracle changes the default.
3. Benchmark AI Unit consumption. Oracle does not document the token-cost ratio between LOW, MEDIUM, and HIGH. Run a representative prompt at each level and compare the AI Units consumed (visible in the AI Usage dashboard) before committing to HIGH in scheduled or high-volume scripts.
4. Gate HIGH reasoning behind business logic. For scripts that handle both simple and complex inputs, consider branching: use LOW/MEDIUM for routine cases and HIGH only when complexity warrants it.
5. No client-side support. This enum is server-script only. If you have client scripts making LLM calls through a Suitelet proxy, the reasoning effort must be set in the Suitelet, not the client script.