Self-Managed Models

Self-Managed Models allows enterprise administrators to connect their own large language model (LLM) endpoints to Tabnine

Self-Managed Models allows enterprise administrators to connect their own large language model (LLM) endpoints to Tabnine. The feature is designed for organizations that want to use self-managed models while keeping the familiar Tabnine governance, orchestration, and user experience.

Model Modes in the Admin Console

When you open the Admin Console and go to the Models section. Beneath the “Self-Managed” panel you will see a list of all models your organization has configured, including their names, providers, and availability for Chat or Agent use.

Each model entry also shows whether it is set as the default for Chat or Agent. This makes it easy to see which models are active and how they are being used.

① Provider

To add a new self‑managed model, click Add model on the right side of the Models page.

This opens the Add AI Model wizard with Step ① Provider where you choose a provider, enter credentials, and define model details.

Select the AI provider you want to configure (for example, ChatGPT, Amazon Bedrock, Gemini Enterprise Agent Platform (formerly GCP Vertex AI), Azure AI Foundry, or an OpenAI‑compatible endpoint).

② Credentials

With Step ② Credentials, enter the authentication details required for that provider. For example, Amazon Bedrock requires a region, access key ID, secret access key, and an optional custom endpoint.

You can also load an existing credential configuration instead of entering new values.

Workplace Identity Federation for Cloud Providers (v6.4.0)

The Add AI Model wizard supports OAuth as an alternative to static API keys for authenticating with cloud providers. This is useful for enterprise environments where long-lived API keys are restricted by security policy, or where the organization mandates federated identity through SSO.

Provider	OAuth flow	Alternative to
Google Agent Platform	OAuth 2.0 / Google Sign-In	Service account JSON
Amazon Bedrock	AWS SSO / IAM Identity Center	Access key + secret

In the Add Model wizard, select a supported provider and advance to the Credentials step.

An authentication method selector appears (e.g., API Key vs. Sign in with Google). Select the OAuth option and click Sign In.

A browser-based sign-in window opens where you should complete the provider's sign-in flow (e.g., Google account selection, Azure AD login, or AWS SSO).

AWS Bedrock

AWS Bedrock

In Tabnine, choose Workload Identity Federation. You will need to fill in your region and IAM Role ARN (optionally your cross-region inference prefix, external ID, and custom endpoint). Open the AWS Management Console and search for IAM.

In the IAM navigation pane, select Roles. Select the IAM role you created for web identity federation.

On that role’s Summary page, locate the ARN field near the top of the page and copy it in the model wizard on Tabnine.

Google Agent Platform

Key Differences: AWS Bedrock vs. Gemini Enterprise Agent Platform (formerly GCP Vertex AI)

Aspect	AWS Bedrock	Google Agent Platform
Identity Federation	IAM + STS AssumeRoleWithWebIdentity	Workload Identity Federation
Token Endpoint	AWS STS	Google STS / OAuth 2.0 Token endpoint
Service Auth Model	IAM Roles & Policies	Service Accounts & IAM Bindings
OIDC Support	Via IAM OIDC Identity Providers	Via Workload Identity Pool Providers

Once finished, the wizard displays the authenticated identity (e.g., email or account name) confirming the connection.

Token Expiration and Reauthentication

If the OAuth token expires or is revoked by the provider, Tabnine surfaces a clear re-authentication prompt. Re-authenticate by repeating the Sign In flow from the Credentials step in the Edit Model wizard.

The existing static credential flow (API keys, access keys, service account JSON) remains available and is the default. OAuth is offered as an additional option alongside the existing method.

③ Model Details

With Step ③ Model Details, there are a number of technical details to fill in, toggle, or choose. When you are done, click Run Test to verify the connection, then save the model.

Main Model Details

Start by providing the Technical Model Name (the exact identifier used by the provider API) and an optional Display Name for users.

Then configure limits such as Maximum Content Length, Maximum Tokens Per Request, and Maximum Response Tokens.

To use it, complete the Credentials step with valid authentication. On entering the Model Details step, Tabnine calls your provider's model listing API and auto-populates available models (v6.3.0) a searchable dropdown. You can type to filter the list or select directly from it. You can also type a custom model name that does not appear in the dropdown.

Supported providers include OpenAI, Azure OpenAI / Azure AI Foundry, GCP Vertex AI, and Amazon Bedrock. If the model listing API call fails or returns empty, the field falls back to a plain text input.

These settings ensure Tabnine can connect securely to your provider, identify the correct model, and apply token limits that match your organization’s policies.

Toggles

You will see three options to toggle off or on:

Use Responses API: You may enable the OpenAI Responses API instead of the Chat Completions API. This is required for models that support extended thinking or structured output via the Responses endpoint (e.g. Codex models).

Supports Image Attachments: Enable this option only if this model supports image inputs (vision). When enabled, users can attach images to their messages.

Enable Thinking/Reasoning: This will configure how this model produces extended reasoning. When it is toggled off, the provider's built-in default is used (which may change between provider versions).

Custom Headers

When integrating Tabnine with an AI Gateway or proxy layer, you may need to attach additional metadata to every outbound LLM request.

Custom headers let you define static or dynamic HTTP headers that Tabnine injects into every request sent to a self-managed model's endpoint.

In the Custom Headers section, click Add Header. Enter a Header Name (e.g., X-User-Email) and a Header Value (from dynamic placeholders %EMAIL% or %TEAM%)

Dynamic Placeholders

Header values support dynamic placeholders that are resolved per-request from the authenticated user's session. Placeholders can be combined with literal text in a single value.

A dropdown in the header value field offers available placeholders to aid discoverability and prevent typos.

Placeholders are resolved server-side at request time using the authenticated user's session data. If a placeholder cannot be resolved (for example, if the user has no team assigned), it is replaced with an empty string.

Multiple placeholders and literal text can be composed in a single value — for example, user-%EMAIL% resolves to [e-mail].

Repeat to add additional headers as needed.

Example Configuration

An organization routing LLM requests through an AI Gateway for cost attribution might configure the following headers:

Header Name	Header Value	Resolved example
X-User-Email	%EMAIL%	[e-mail]
X-Team	%TEAM%	platform-engineering
X-Cost-Center	engineering-ai	engineering-ai (static)
X-Request-Source	tabnine-%TEAM%	tabnine-platform-engineering

Scope and Behavior

Custom headers are per-model; each self-managed model has its own set. Headers are attached to every outbound LLM request for that model regardless of which user or IDE triggers it, and apply across all clients: IDE plugins (VS Code, JetBrains, Eclipse) and the CLI. Custom headers do not override Tabnine's built-in authentication headers configured in the Credentials step; they are sent in addition to the standard auth headers.

Security Considerations

Header values containing %EMAIL% or %TEAM% transmit user-identifying information to the configured LLM endpoint. In self-hosted deployments, the customer controls the endpoint.

For Enterprise SaaS deployments routing through a third-party gateway, ensure the gateway's data handling policies are compatible with your organization's privacy requirements. Custom header values are stored in the Tabnine server configuration and can only be viewed or modified by admins.

Advanced Settings

Advanced pricing options will designate specific amounts for:

1. Input

2. Output

3. Input Cache

4. Output Cache

Next, you can add under Advanced Properties optional notes in the form of JSON objects with extra parameters to pass to the model (e.g. temperature, top_p, top_k, etc.)

Run Test

Finally, when you are done, click Run Test to verify the connection, then save the model.

④ Model Availability

Finally, Step ④ Model Availability (v6.4.0) allows admins to optionally restrict the model's availability to specific teams.

Use the team multi-select to assign the model to one or more teams. If no teams are selected, the model will be available organization-wide by default. Click Save. The model is created and associated with the selected teams via the updateTeamsFeatures API.

Managing Models and Defaults

Once you save your new model, it appears in the list of self-managed models. You can see which models are active, which are available for Chat or Agent, and which are set as defaults.

If you want to change the default model for Chat or Agent, you can do so directly from this list by clicking “Set default” next to the relevant model. Only one model can be the default for each use case at any time.

You cannot disable or remove a model that is set as a default without first changing the default to another model.

The Self-Managed models table on the Models page includes a Teams column. This column displays which teams each model is assigned to. If no restriction is set, the column shows All teams.

Editing and Deleting Models

Editing or deleting a model follows the same pattern as adding one. You can open the model’s settings to update provider details, token limits, or other configuration values.

You can remove a model entirely as long as it is not set as a default. If a model is the default for Chat or Agent, you need to assign another model as the default before deleting or disabling it.

All changes, including mode switches, additions, edits, and deletions, are logged for audit and analytics purposes. This supports your organization’s governance and compliance requirements.

Quotas, Reporting, and Security

Self-managed models affect how Tabnine handles quotas, cost controls, and reporting. Usage limits and reporting mechanisms apply to both Tabnine-managed and self-managed models.

If your organization tracks token consumption or costs, these metrics include activity from self-managed models. From a security perspective, Tabnine sends prompts and requests to the model endpoints you configure.

The user experience and governance controls remain the same. Users continue to interact with Tabnine through their usual interfaces, and all orchestration is handled as before.