> For the complete documentation index, see [llms.txt](https://docs.tabnine.com/main/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tabnine.com/main/getting-started/tabnine-plugin-for-opencode/sign-in-and-models.md). # Sign-in and Models Once the Tabnine plugin for opencode is [installed](/main/getting-started/tabnine-plugin-for-opencode/install.md), signing in connects the CLI to your Tabnine account and loads your organization's models. This page covers how to sign in from the command line or interactive TUI, where credentials live, and how to choose and pin a model. {% hint style="info" %} **Already signed in?** On a fresh install, the installer starts the sign-in for you. If you completed it there, you can skip to [Which models you see](#which-models-you-see). {% endhint %} ### Sign in You can sign in from the command line or from inside a running TUI session. Both routes lead to the same two Tabnine login methods. #### Start sign-in from the command line {% stepper %} {% step %} ### Run the login command ```bash tabnine auth login ``` {% endstep %} {% step %} ### Select the provider At the **Add credential** screen, under **Select provider**, choose **tabnine (plugin)**. {% endstep %} {% step %} ### Select a login method At the **Login method** menu, choose one of the methods described in [Choose a login method](#choose-a-login-method). {% endstep %} {% endstepper %} #### Start sign-in from the TUI {% stepper %} {% step %} ### Start a session Start a session with `tabnine`. {% endstep %} {% step %} ### Open the connection flow Open the command palette with **Ctrl+P** and run **Connect provider**, or type `/connect` at the prompt. {% endstep %} {% step %} ### Select Tabnine and a login method In the provider list, select the Tabnine provider, then choose one of the methods described in [Choose a login method](#choose-a-login-method). {% endstep %} {% endstepper %} #### Choose a login method Both routes present the same two methods. **Login with Tabnine (browser)** {% stepper %} {% step %} ### Start browser sign-in Choose **Login with Tabnine (browser)**. The CLI tells you: "Complete sign-in in your browser; this will finish automatically." {% endstep %} {% step %} ### Complete sign-in in your browser The CLI detects it automatically, so you don't need to copy anything back. {% endstep %} {% step %} ### Restart running sessions Restart any running `tabnine` session so your models load. See [After signing in, restart](#after-signing-in-restart). {% endstep %} {% endstepper %} {% hint style="info" %} **Taking too long?** The browser flow times out after 5 minutes with the message "Tabnine authentication timed out after 5 minutes. Please try again, or set TABNINE\_TOKEN for non-interactive auth." Run the command again, or use a token as described next. {% endhint %} **Paste Tabnine access token (PAT)** If a browser isn't convenient, paste a Tabnine personal access token (PAT) instead. PATs are created and managed in the Tabnine admin console. {% stepper %} {% step %} ### Select PAT authentication Choose **Paste Tabnine access token (PAT)**. {% endstep %} {% step %} ### Paste your token At the **Tabnine access token** prompt, paste your token. Tokens look like `t9u_…` or `t9ci_…`. Submitting an empty value shows "An access token is required." {% endstep %} {% endstepper %} ### Environment-variable authentication For scripts, CI, or shared machines, set a credential in the environment instead of logging in interactively: * **`TABNINE_TOKEN`** – a Tabnine PAT. The CLI behaves like a signed-in user, with no browser interaction. This is the recommended variable and has the highest priority. * **`TABNINE_JWT`** – a pre-formed JWT, used verbatim (legacy). * **`TABNINE_REFRESH_TOKEN`** – a raw refresh token. For example: ```bash TABNINE_TOKEN=t9ci_xxxxxxxx tabnine run "summarize this repo" ``` At startup, the highest-priority environment credential is applied, **overwriting any prior interactive login**. When none of these variables is set, your existing login is untouched. For end-to-end CI usage, see [Scripts and CI](/main/getting-started/tabnine-plugin-for-opencode/scripts-and-ci.md). ### Where your sign-in is stored Credentials are stored in opencode's native `auth.json` under the provider id `tabnine`, in the **shared** opencode data directory: `${XDG_DATA_HOME:-~/.local/share}/opencode/auth.json`. Because this directory is shared, one Tabnine sign-in covers both the Tabnine copy of opencode and your own opencode install (if you added the Tabnine plugin there during install). You stay signed in until your session or PAT is revoked. ### Sign out To sign out, run: ```bash tabnine auth logout ``` At the **Select provider** prompt, pick your **tabnine** credential, or skip the picker with `tabnine auth logout tabnine`. The CLI prints "Logout successful" and removes the `tabnine` entry from the shared `auth.json`, so this signs you out of both the Tabnine copy of opencode and your own opencode install. {% hint style="info" %} **Using environment variables?** If `TABNINE_TOKEN`, `TABNINE_JWT`, or `TABNINE_REFRESH_TOKEN` is set, the credential is re-applied at the next startup. Unset the variable to stay signed out. {% endhint %} ### Advanced: callback and host settings These environment variables adjust the sign-in flow. Most users never need them: * **`TABNINE_LOGIN_CALLBACK_HOST`** - the bind host for the local sign-in callback server. Default: `localhost`. * **`OAUTH_CALLBACK_PORT`** - pins the callback server to a fixed port; otherwise an ephemeral port is used. An invalid value fails with `Invalid value for OAUTH_CALLBACK_PORT: ""`. Note the exact name: unlike the other variables, it has no `TABNINE_` prefix. * **`TABNINE_HOST`** - points the CLI at a different Tabnine host. The host is resolved in this order: the `host` plugin option in your config (written when a host is set at install time) → `TABNINE_HOST` → the default `https://console.tabnine.com`. Setting `TABNINE_HOST` (or `--host`) during install writes that host into your config; the installer prints that `TABNINE_HOST` was used and does not prompt. A non-interactive install with neither set writes no `host` option, so a later `TABNINE_HOST` stays effective. See [Install](/main/getting-started/tabnine-plugin-for-opencode/install.md) for more details. ### Which models you see The Tabnine plugin locks the CLI to Tabnine-served models: the model picker and the `models` command only ever show `tabnine/*` entries. No other providers, API keys, or catalogs appear. At startup, the plugin discovers the agent-capable models available to your account and adds them to the list. {% hint style="info" %} **Who controls this list?** Model availability is governed by your organization: admins enable models and set quotas and licenses in the Tabnine admin console. PATs are managed there too. See [Models](/main/administering-tabnine/managing-your-team/settings/models-settings.md), [Personal Access Tokens](/main/administering-tabnine/managing-your-team/settings/access-tokens.md), and [Cost Control](/main/administering-tabnine/managing-your-team/settings/agent-settings.md). {% endhint %} ### Model keys Models are keyed by a readable slug of their display name, prefixed with the `tabnine/` provider id. For example, the model **Claude 4.5 Sonnet** becomes `tabnine/claude-4-5-sonnet`. If two models slug to the same key, numeric suffixes (`-2`, `-3`, …) keep them distinct. ### List and choose a model To list the models available to you: ```bash tabnine models ``` To choose a model for a single non-interactive run, pass `--model tabnine/`: ```bash tabnine run "explain this function" --model tabnine/claude-4-5-sonnet ``` You can also pass `--model` when starting an interactive session: ```bash tabnine --model tabnine/claude-4-5-sonnet ``` The opencode [model selection](https://opencode.ai/docs/models/) flow is unchanged by the Tabnine plugin; only the catalog is limited to `tabnine/*` entries. **opencode reference:** Choosing a model is a standard opencode feature; see the opencode [Models docs](https://opencode.ai/docs/models/). #### Switch models from the TUI Inside a running session you can change the model without restarting: * Run `/models` (titled **Switch model**) to open the model picker. * Press the leader key (**Ctrl+X**), then **m**, to open the same picker. * Press **F2** to cycle to the next recently used model, or **Shift+F2** to cycle back. These are opencode's default [keybindings](https://opencode.ai/docs/keybinds/), which you can remap in your config.
**opencode reference:** The TUI and its model-switcher keybindings are standard opencode features; see the opencode [TUI docs](https://opencode.ai/docs/tui/) and [Keybinds docs](https://opencode.ai/docs/keybinds/). ### Pin a default model To always start with a specific model, set the `model` key in an opencode config file: ```json { "$schema": "https://opencode.ai/config.json", "model": "tabnine/claude-4-5-sonnet" } ``` Choose where to put the `model` key based on the scope you want: * **Everywhere (all sessions):** set it in the Tabnine copy's config at `~/.tabnine/opencode/config/opencode.json`. This is the file the `tabnine` launcher points at. * **One project only:** set it in an `opencode.json` in that project's root. The nearest project file wins among project configs. The Tabnine config is merged after project files, so it overrides them when both set `model`. When no default is pinned, opencode picks for you: the most recently used model that's still in the list, or, if there isn't one, the first model of the provider by its internal sort order. ### When no models are available (placeholder models) When no real model can be loaded, the model list shows a single placeholder entry that tells you what to do: * **`tabnine/login-required`** – a "Login required" entry that tells you to run the login command. You're signed out: run `tabnine auth login`, then restart. * **`tabnine/models-unavailable`** – a "Models unavailable" entry that tells you to check your Tabnine host and token. Model discovery failed or returned no agent-capable models: check that your token is valid and your Tabnine host is reachable. Placeholders can't call tools, and chatting with one fails at the Tabnine endpoint. They exist only to keep the provider visible and point you at the fix. The CLI also prints a one-line notice to stderr, beginning with `[tabnine] No Tabnine models available`, stating the concrete reason. {% hint style="info" %} **About the command in those messages:** the placeholder and stderr texts say `opencode auth login`, but in the Tabnine distribution the installed command is `tabnine`. Run `tabnine auth login`. {% endhint %} ### After signing in, restart Model discovery runs when the CLI starts. If you signed in while a session was running, or after seeing the `login-required` placeholder, **restart `tabnine`** to replace the placeholder with your real models. Next, see the built-in Tabnine servers in [MCP Servers](/main/getting-started/tabnine-plugin-for-opencode/mcp-servers.md), [Scripts and CI](/main/getting-started/tabnine-plugin-for-opencode/scripts-and-ci.md) for non-interactive usage, or [Troubleshooting](/main/getting-started/tabnine-plugin-for-opencode/troubleshooting.md) for common fixes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.tabnine.com/main/getting-started/tabnine-plugin-for-opencode/sign-in-and-models.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.