fix: use InputsUnion1 for input item types instead of BaseInputsUnion

[devin-ai-integration]

Summary

Companion to OpenRouterTeam/openrouter-web#27314 (OpenAPI 3.1 nullability).

The hand-written src/lib code used models.BaseInputsUnion as the item type of the responses input array, but BaseInputsUnion is the full input union (string | Array<...>). It only compiled because the current generated type carries a trailing | any member — an artifact of a bare {nullable: true} union variant in the 3.0-style spec that Speakeasy turns into z.any(). The 3.1 spec change replaces that with an explicit type: 'null', removing the any escape hatch, and these item-typed positions stop compiling.

Fix: use models.InputsUnion1 (the element union of InputsUnion, which includes EasyInputMessage and FunctionCallOutputItem) wherever an input item type was meant:

-normalizeInputToArray(input: models.InputsUnion): Array<models.BaseInputsUnion>
+normalizeInputToArray(input: models.InputsUnion): Array<models.InputsUnion1>

-appendToMessages(current: models.InputsUnion, newItems: models.BaseInputsUnion[])
+appendToMessages(current: models.InputsUnion, newItems: models.InputsUnion1[])

plus the matching as models.InputsUnion1[] casts in model-result.ts where response output items are echoed back as next-turn input.

Compiles against both today's generated models (with | any) and the regenerated models from the 3.1 spec, verified via speakeasy run (v1.763.2) with the PR spec.

Link to Devin session: https://openrouter.devinenterprise.com/sessions/10bab5add638413090c7a6a74858843f

[devin-ai-integration]

Original prompt from luke.parke

SYSTEM:
=== BEGIN THREAD HISTORY (in #agents) ===
<most_recent_message>
Luke Parke (U0BF2BKT52N): @Devin Give me a report on the duplicated or repetitive models or schemas in the OpenRouter OpenAPI specification, determine which would best be broken out into references and then review the OpenAPI generation logic with that information, and draft a PR to improve that generation logic accordingly
</most_recent_message>
=== END THREAD HISTORY ===

Thread URL: https://openrouter.slack.com/archives/C07UF9XLTFF/p1783421587687529?thread_ts=1783421587.687529&amp;cid=C07UF9XLTFF

The latest message is the one right above that tagged you. The <most_recent_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.

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[perry-the-pr-reviewer]

⚠️ APPROVE unavailable on this installation — the maintainer GitHub App is not
configured with pull_requests: write, so the verdict below is posted as COMMENT.
Event-level approval (for branch-protection / review requirements) must be added out-of-band.

Perry's Review

Narrows the item type of appendToMessages/normalizeInputToArray from models.BaseInputsUnion (the full input union, string | array) to models.InputsUnion1 (the actual element union) — a preparatory fix ahead of an OpenAPI 3.1 spec regen that removes the | any escape hatch these positions were silently compiling through.

Verdict: ✅ LGTM

Details

Risk: 🟢 Low

CI: all passing ✅

Findings: none — verified InputsUnion1 is the correct element union of InputsUnion (matches normalizeInputToArray's actual return semantics), traced all call sites in model-result.ts (the two callers passing FunctionCallOutputItem[] already satisfy InputsUnion1[] without a cast; the two callers that needed the added as models.InputsUnion1[] casts pass broader OutputItems/response-output unions that legitimately need narrowing). No behavioral change — type-only.

Security: no concerns — no auth/streaming/logging/rendering/tenant-boundary categories touched.

Test coverage: existing appendToMessages unit tests already exercise this function; no new tests needed for a type-only change.

Unresolved threads: none

Details (footer)

Scope: first review (full)
Review: tier=trivial · model=claude-sonnet-latest · score=0.1