[UriZafrir]

What and why

Closes #32.

The client already supports five backends; the extension could not select one, because src/extension.ts called createTypeSafe() bare. This adds the selection and makes the text the user consents to match where the data actually goes.

• PI_TYPESAFE_BACKEND picks the backend (default typesafe). An unknown name is a configuration error at session start, not a silent fallback to TypeSafe.
• PI_TYPESAFE_MODEL overrides the backend's default model, written in the backend's own id form (jev-1.14; mapped to typesafe/jev-1.14 on OpenRouter).
• The consent line and /typesafe status name the host, key variable, and model actually used. Previously the disclosure was the fixed api.typesafe.ai sentence, which would have stated a false destination once routing changed.
• /typesafe login and /typesafe logout decline on a backend that reads its key from the environment instead of the TypeSafe store, and say which variable to set.
• Four exports added to src/index.ts (BACKEND_ENV, MODEL_ENV, backendFromEnvironment, modelFromEnvironment), each documented in docs/api.md as CONTRIBUTING requires.

Verification

• npm ci and npm run check pass (build, typecheck, 175 offline tests; 169 before, 6 added).
• Changed behavior has offline tests, per CONTRIBUTING. New cases in tests/backends.test.ts cover the readers, including blank, unknown, and whitespace-padded values. New cases in tests/extension.test.ts load the extension through Pi's native loader under an override and assert the request URL goes to openrouter.ai and never api.typesafe.ai, that an invalid name rejects before any request, and that login/logout do not prompt.
• Documentation updated: the README sentence that stated the tool always uses TypeSafe, plus docs/api.md.

Live testing: not applicable to the transport or response validation, which are untouched. The new tests assert the destination host at the fetch boundary instead. I did also confirm the routing by hand in a Pi session with PI_TYPESAFE_BACKEND=openrouter, where the tool returned a real judgment from typesafe/jev-1.13-20260917.

Compatibility and release notes

Additive. With PI_TYPESAFE_BACKEND unset the extension behaves exactly as before — same host, same key store, same model — so existing installs are unaffected. The one behavioral difference is that /typesafe login and /typesafe logout now decline on a non-TypeSafe backend instead of storing a key the session would not read.

This changes a documented guarantee (the README sentence above), so if single-backend-only was deliberate, close it and I will rework the disclosure instead. No version bump, per CONTRIBUTING.

[DevMortimer]

Thanks — the destination side of this is right. With PI_TYPESAFE_BACKEND=openrouter a request goes to openrouter.ai/api/alpha/decisions, an unknown name raises a startup callout and a configuration error on the tool, and login/logout decline naming the right variable. Three things need to change before this merges; I reproduced each against bc4d1e2.

1. The consent line and status name a model that is not sent. disclosureFor and backendLine (src/extension.ts:25, :32) and the status line (:177) print model ?? defaultModelId(backend) — the caller's bare id — while the request carries mapModel(requested) (src/client.ts:227). With PI_TYPESAFE_BACKEND=openrouter PI_TYPESAFE_MODEL=jev-1.14:

• the dialog says … as model "jev-1.14" …
• the request body carries "model": "typesafe/jev-1.14"

tests/extension.test.ts:362 already asserts the body carries typesafe/jev-1.14, and line 365 asserts the status says Model: jev-1.14, so the test pins the mismatch rather than catching it. Mapping the id in those three places and asserting printed model equals body model closes it.

2. README.md:117 still promises one destination. “Only the state and questions you … submit, to https://api.typesafe.ai only.” Under the override the request went to openrouter.ai on the wire. This is the sentence the privacy section rests on, so it needs the same treatment as the disclosure: name the host /typesafe status reports, or name the override explicitly.

3. An inherited property name passes the backend check and breaks the whole extension. backendConfig reads DECISIONS_BACKENDS[name] (src/backends.ts:112), so any Object.prototype key satisfies the “unknown backend” check. With PI_TYPESAFE_BACKEND=toString — and the same for constructor, __proto__ and hasOwnProperty — backendFromEnvironment returns the name and registration throws TypeError: model.includes is not a function. Pi then reports Failed to load extension, so there is no tool, no /typesafe command and no callout at all. Object.hasOwn(DECISIONS_BACKENDS, name) before the return, plus those four names in the existing throw test, fixes it.

Smaller, not blocking:

• With the default backend and PI_TYPESAFE_MODEL set, the enable dialog still prints the fixed sentence with no model named.
• The status line names the model twice: model "jev-1.14" and Model: jev-1.14.
• With an invalid name, login still prompts and logout still deletes the stored TypeSafe key, although no judgment can be sent.

Everything else in the description holds: with both variables unset the host, key store, model and dialog text are unchanged, the four exports are documented in docs/api.md, the per-backend variables and decline messages are right, and npm ci && npm run check passes with 175 tests.