Update an existing Kinra hosted connection

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:

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:

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:

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:

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:

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. For the stable hosted API roles, see Models & providers.