# Update an existing Kinra hosted connection > Use this one-time migration when Kin was connected with an early command from the Kinra console (console.kinra.ai). It moves the saved connection from concrete runtime names to the stable default and vision service ro… Use this one-time migration when Kin was connected with an early command from `console.kinra.ai`. It moves the saved connection from concrete runtime names to the stable `default` and `vision` service roles without replacing a saved API key. ## Before you start Run the migration on the tester's machine and user account. Kin stores this connection globally for that user, not in an individual project. Record the installed version, then check for the migration capability: ```bash kin --version kin connect --help | grep -- --refresh-profile ``` The initial `v0.3.11` release predates this option, but the option alone is not a sufficient readiness check either: some intermediate development builds can refresh the stable routes without labeling Vision, Utility, and Review calls for the service. Do not migrate with one of those builds. If the option is absent, update and check again: ```bash kin update kin connect --help | grep -- --refresh-profile ``` For an authorized Git-backed `dev` install, `kin update` ends with the version and source identity, for example `checkout updated — kin 0.3.12 @ …`. Continue only with tested checkpoint `349ae96` or a descendant. The operator can prove an exact checkout with: ```bash git -C /path/to/kin merge-base --is-ancestor 349ae96 HEAD ``` Exit status zero means the checkpoint is present. For an immutable wheel, continue only with a release newer than `v0.3.11` whose release notes include the hosted Vision/Utility/Review application-role contract. If neither condition is true, stop and ask the Kin operator for the current authorized build; do not replace the connection manually to work around an older client. Do not delete the old connection or put the API key on the command line. The refresh is designed to retain the existing credential. ## Run the migration Prefer the current **Connect Kin** command shown by `console.kinra.ai`. For the standard hosted connection, run: ```bash kin connect kinra-api \ --base-url https://api.kinra.ai/v1 \ --wire-api responses \ --model default \ --refresh-profile \ --reasoning-effort inherit \ --label "Kinra hosted inference" \ --vision-route kinra-vision \ --vision-model vision \ --vision-description "Kinra hosted vision" \ --vision-max-tokens 1024 \ --vision-reasoning-profile inherit \ --utility-route kinra-vision \ --review-route kinra-vision ``` The refresh makes one atomic settings change: - the primary model becomes the stable `default` role; - the `kinra-vision` route becomes the stable `vision` role; - Vision and Utility work use that route; - Kin's independent auto-mode Review classifier uses that route; - obsolete connection-local reasoning pins are removed; and - an existing ready credential for `kinra-api` is retained. Running the same command again is safe. Once current, it is a settings and credential no-op. ## Confirm the result Launch Kin and open `/models`: ```bash kin ``` Confirm these values: - **Main connection:** `Kinra hosted inference`, model `default`; - **Vision route:** `kinra-vision`, model `vision`; - **Vision job:** `kinra-vision`; - **Utility job:** `kinra-vision`; and - **Review job:** `kinra-vision`. Review is an explicit global trust and egress choice. It receives only the direct user request plus the exact sandbox operation/profile, can approve only one low-risk exact call, and otherwise fails closed to human confirmation. It does not create a reusable permission. The service-qualified `vision` profile is text-capable and keeps Review, Utility auto-titles, and image work off the main chat model. Kin labels each Responses side-call with its application role, letting the service retain image reasoning for Vision while keeping the bounded Utility and Review paths non-thinking. `Review` is the classifier for interactive root auto-mode. It is not the Utility/title job, and it is not used by strict, child, resumed, or headless Outpost turns. Assigning both jobs to `kinra-vision` selects one service model; their per-request role labels still give them separate prompts, output bounds, and inference policy. Send a normal test message. A successful response confirms that the retained credential and updated primary route work. An image test can separately confirm the vision route when needed. ## If it does not migrate - **`--refresh-profile` is unrecognized, or the build predates `349ae96`:** this client is not qualified for the complete migration. Run `kin update`, recheck the source identity and help output, and use a current authorized `dev` build or qualifying newer release before changing the connection. - **Kin asks for an API key:** no ready credential was found under the `kinra-api` provider id. Paste the tester's existing key into the masked prompt; never add it as a shell argument or to a project settings file. - **Kin reports an endpoint, wire, or route conflict:** nothing was changed. Open `/models` and inspect the existing connection. The automatic migration intentionally refuses a different endpoint, a non-Responses wire, another provider's route, or an arbitrary main-model replacement. - **The command was already run:** run it again. An already-current profile is deliberately a no-op. For the complete command behavior, see [`kin connect`](/docs/kin/reference/cli/#kin-connect). For the stable hosted API roles, see [Models & providers](/docs/kin/guide/models-and-providers/#current-kinra-hosted-contract). _Source authority: Kinra Site (src/content/docs/kin/getting-started/hosted-inference-migration.md)._