client.models exposes retrieve()/delete() that 404 at runtime — expose list() only

[Khurdhula-Harshavardhan]

client.models exposes retrieve()/delete() that 404 at runtime — expose list only

src/client.ts:60 assigns the whole OpenAI models resource:

this.models = this.openai.models;

But the Interfaze server implements only GET /v1/models (list) — there is no GET /v1/models/{id} route. So client.models.retrieve(id) / client.models.delete(id) issue GET/DELETE /v1/models/{id}, hit the Next.js HTML 404, and throw NotFoundError at runtime. This also contradicts the client's own docstring ("unsupported OpenAI resources are intentionally absent", client.ts:26).

Test masks it: test/models.test.ts mocks a fictional list shape (object:"list", per-model owned_by/object:"model") and a successful retrieve() — none of which the server returns. The real /v1/models response is envelope-less with rich fields (id/canonical_slug/name/pricing/architecture, no owned_by). So the test hides both the missing route and the true model-object shape.

Fix: expose only list (e.g. this.models = { list: this.openai.models.list.bind(this.openai.models) } or a small typed wrapper), and update models.test.ts to the real server shape. retrieve() can be re-added once server #218 lands /v1/models/{id}.

[Abhinavexist]

Decision: keeping client.models as the full OpenAI models resource rather than narrowing to list(). Server #218 — which lands GET /v1/models/{id} and OpenAI-envelopes /v1/models — is going to be merged, so retrieve()/delete() become valid rather than 404; removing them now would be churn we'd immediately revert. Leaving this open as a tracker for the #218 deploy; no SDK change.