feat: allow omitting reasoning effort so the model default applies

[ayush-or]

TL;DR

reasoningEffort becomes optional end to end. When it is omitted the harness sends no reasoning object at all, so the model or router default applies. The CLI still defaults to high, and --reasoning-effort default is the explicit opt-in to omit it.

What changed?

• GenerateConfig.reasoningEffort, InferenceOverrideSchema.reasoningEffort, and the search solver/request option types are now optional.
• Responses request builders only include reasoning when an effort is set (previously always reasoning: { effort }):

  ...definedValues({
    reasoning: effort !== undefined ? { effort } : undefined,
  })

• CLI: --reasoning-effort default maps to undefined. Omitting the flag still resolves to high. The ORI agentReasoningEffort derivation is skipped when effort is unset.
• Tests: config schema accepts a missing effort, Responses and search bodies have no reasoning key when unset, CLI default produces a config without reasoningEffort. Explicit-effort tests are unchanged.

Why?

Benchmarking a router that picks its own effort (e.g. openrouter/jev) requires a request with no reasoning.effort pinned. Today omission is impossible: the config schema rejects it and the request builder always sends an effort. A Temporal run without the field failed before launching any child workflow.

This partially reverses #62 (ECO-3608), which made explicit effort mandatory. The default remains explicit high for every existing entry point, so existing runs are unaffected. Omission is opt-in only.

How to test

bun test src/cli src/providers/responses-model.test.ts src/benchmarks/search/core/request.test.ts src/benchmarks/benchmark-config.test.ts

Expected: all pass, including leaves reasoning effort unset for --reasoning-effort default and omits reasoning when no effort is requested.

Full validation run locally: bun run format:check, bun run check, bun run typecheck, bun test (1508 pass), bun run build.

Benchmark impact

None for existing callers, the CLI default is still high and explicit values are sent unchanged. Runs that opt in via --reasoning-effort default (or a Temporal config with the field omitted) will send no reasoning object, which changes the model's reasoning behavior and therefore scores and cost for those runs only.

Note the Temporal BenchmarkConfig schema in openrouter-web still defaults a missing reasoningEffort to high. A follow-up there is needed before an omitted effort reaches this code in production.

Reviewer focus

• Whether reversing the ECO-3608 requirement as opt-in omission is acceptable.
• definedValues usage in responses-model.ts and search/core/request.ts drops the key entirely rather than sending effort: undefined.

Checklist

• Tests cover changed behavior
• Public API or configuration changes are backward compatible, or the break is documented
• Benchmark changes document dataset provenance and licensing (n/a)
• No credentials, private results, or restricted dataset contents are included
• Documentation is updated where needed (no docs reference --reasoning-effort)

Link to Devin session: https://openrouter.devinenterprise.com/sessions/8caab1dda9764cc38dbbba486bc04687
Open in Devin Desktop: https://openrouter.devinenterprise.com/desktop/session/8caab1dda9764cc38dbbba486bc04687?variant=devin
Requested by: @ayush-or

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access that start with 'DevinAI' or '@devin'.

• Disable automatic comment, CI, and merge conflict monitoring

---

Original prompt from Ayush

SYSTEM:
<latest_message>
Ayush Patel (U0B8L6RNMA9) [ts=1789780083.530159]: @Devin!router_benchmark, 2 epochs of gpqa diamond, openrouter/jev , no spend/acu limit
</latest_message>

=== BEGIN THREAD HISTORY (in #agents) ===
Ayush Patel (U0B8L6RNMA9) [ts=1789780083.530159]: @Devin!router_benchmark, 2 epochs of gpqa diamond, openrouter/jev , no spend/acu limit
=== END THREAD HISTORY ===
Channel ID: C07UF9XLTFF
Thread URL: https://openrouter.slack.com/archives/C07UF9XLTFF/p1789780083530159?thread_ts=1789780083.530159&amp;cid=C07UF9XLTFF

The <latest_message> is the message that you should use to guide your goals + task for this session, and you should use the rest of the slack thread as context.
A [ts=...] marker on a Slack message is that message's timestamp. To act on a specific message with the slack tool (e.g. adding an emoji reaction via the reaction command), pass that value as timestamp along with the Channel ID — no extra lookup call is needed.

@playbook:playbook-67bd60e6265449979d13f557104b2ef7