When connecting custom models in Cline, the key is both a pass and the boundary of cost and security. A carelessly created key commonly leads to unexpected quota consumption, unclear usage, old keys still running after someone leaves, or keys ending up in backups and repositories along with configuration files.

This article provides a checklist in the order of creation, multiple models, storage, rotation, permissions, teams, and troubleshooting. Interfaces and storage methods may change between versions; follow your current version and the official documentation.

Note: Cline is a trademark of Cline Bot Inc. This article is for technical explanation only and implies no affiliation, agency, or endorsement relationship with Cline Bot Inc. Product features, interfaces, and billing rules are governed by Cline's official documentation.

1. Clarify what "Cline API key" means

The term is often used for three different things:

  • Cline platform credentials: used for Cline's own account system or platform interfaces, with quota determined by Cline.
  • Model provider keys: issued by providers such as OpenAI, Anthropic, or Google and entered into the corresponding provider fields in Cline.
  • Gateway keys: issued by compatible services such as ZSQH AI Gateway, usually starting with sk-, calling multiple models through the OpenAI-compatible protocol.

This article covers the third type. It is not used to sign in to Cline and cannot call Cline platform interfaces. The correct entry point is OpenAI Compatible, not the dedicated fields for OpenAI, Anthropic, or Azure.

2. Create a key: define boundaries before copying

Before creating a key, decide who will use it, which project it is for, and the maximum it may consume.

  1. Open the ZSQH AI Gateway sign-up page and sign in to the console.
  2. Go to "API Keys" and create a new key.
  3. Include the user, device, and purpose in the name, for example cline-zhang-macbook-daily; do not just write test.
  4. Set a spending limit and expiration time. If the console supports model scopes, restrict the models available to the project.
  5. Confirm the balance and quota so you do not discover after configuration that calls cannot be made.
  6. Copy the key into a password manager; do not send it through chat tools or tickets first.

Record it in a format like the following, which makes rotation and handover easier:

Purpose: cline-zhang-macbook-daily
Base URL: https://ai.zhongshangqihang.com/v1
Key: sk-... (store only in a password manager)
Model: use the model ID currently shown on the "model pricing" page
Limit: set according to the project budget
Expires: 2027-01-31

A key is usually displayed in full only once. If lost, create a new one and disable the old key. Models and prices change; use model pricing as the reference.

3. How to configure multiple models

In the VS Code extension, the API Provider, Base URL, and model usually form one active configuration; switching models generally requires changing the settings or the task selector. Whether multiple configurations can be saved per project depends on the current version and official documentation.

More reliable multi-model management happens on the gateway side: use different keys for different scenarios and distinguish purposes through spending limits, model scopes, and logs. That way, even if a machine's configuration is altered, the impact stays contained.

Scenario Model tier Key policy Notes
Daily Q&A, small edits Lightweight fast model Personal dedicated key Low cost, limited capability on complex tasks
Main coding, agent tasks Primary coding model Personal dedicated key Must support tool calling
Architecture design, difficult debugging High-capability model Project key, approval as needed Higher cost; restrict the scope of use
Automation, CI, scripts Stable-version model Separate service key Separate limit; do not mix with personal keys
Temporary testing Low-cost model Short-lived key Set the shortest possible expiration

For command-line use, cline auth can configure the provider, key, model, and Base URL. Parameters may change between versions, so check the local help first:

export ZSQH_API_KEY="sk-... (injected from a password manager, not written into scripts)"
cline auth -p <provider-id> -k "$ZSQH_API_KEY" \
  -m <model-id> -b https://ai.zhongshangqihang.com/v1

Note that a key passed with -k may be saved as persistent configuration for that provider. Use this only on trusted machines, and confirm that shell history, process lists, and logs do not retain the plaintext value. The CLI supports isolating configuration directories with --config, --data-dir, or CLINE_DIR and CLINE_DATA_DIR.

4. Where the key is stored

Newer versions place global settings under ~/.cline/data/settings/:

  • providers.json: provider configuration, which the official documentation says includes API keys.
  • global-settings.json: general global settings.
  • cline_mcp_settings.json: MCP server settings, which may contain tokens for third-party services.

Project-level configuration is usually in .cline/ at the repository root, including rules, workflows, hooks, agents, and similar files. Different versions may use the VS Code secret store or a unified data directory; do not assume the key is always encrypted.

Treat these as local sensitive files:

  • Enable disk encryption and a screen-lock password, and restrict local permissions.
  • Do not put ~/.cline in public cloud storage, code repositories, or shared backups.
  • Before committing, check .vscode/, .cline/, .clinerules, and scripts to ensure no key is present.
  • Manage tokens in MCP configuration as secrets too.
  • Cover the settings page in screenshots, screen recordings, and remote support sessions.
  • Before syncing configuration, confirm the tool's scope and encryption method, then decide whether key files are included.

5. Rotation and revocation

Rotate every 90 days, or immediately after a team change, device replacement, or suspected leak. Rotation should run in parallel first and then switch, not delete and recreate.

  1. Create a new key with the same permissions, with a date suffix in the name.
  2. Replace the key in Cline settings, or update the CLI provider configuration.
  3. Send a test request and confirm that the gateway log shows a record for the new key.
  4. Watch the error rate and usage for a period to confirm that no client was missed.
  5. Disable the old key, keep it for a while, then delete it.

If a leak is suspected, reverse the order: disable or delete the key first, then investigate abnormal usage, sources, and time ranges, and then notify the team and check repositories and logs. Departures and device changes should be handled the same day, not postponed to the next audit.

Before rotating, inventory every place the key is used: the VS Code extension, CLI, CI, other editors, and temporary scripts. Replacing only the key in the IDE may leave the old key running in automated jobs.

6. Least privilege and team policy

  • One key per person: shared keys cannot distinguish usage and are hard to trace after a leak. Create a separate key for shared services.
  • One key per purpose: separate daily development, automation, and temporary testing so limits and suspension are easier.
  • Set limits: set spending limits, expiration times, and model scopes wherever possible; at minimum set the first two.
  • Centralize access: connect through a unified gateway where possible, retaining member, model, and usage logs for auditing and cost allocation.
  • Maintain a register: record only the key name, holder, purpose, creation date, and expiration date; never record the complete key.
  • Audit regularly: each month, check for keys unused for a long time, keys over budget, and unusual increases in authentication failures.
  • Onboarding and offboarding: include key creation, handover, and disabling in the onboarding and departure checklists.
  • Classify data: define which repositories may use which models and channels, and assess sensitive projects first.
  • Control agent permissions: auto-approve and YOLO mode amplify mistakes and prompt-injection risk; teams should define default permissions and exception approvals.
  • Review extensions and MCP: install only from trusted sources; hooks, plugins, and MCP servers may execute code or access the network.

Base cost estimates on model pricing. Do not judge whether something is expensive from the subjective feel of a single task; calculate from request volume, context length, and model tier.

7. Troubleshooting checklist

  • 401 or Invalid API Key: the key is wrong, disabled, or was pasted with spaces or line breaks. Delete it and copy it again in full.
  • 403: the quota is exhausted, the key lacks permission, or the model is outside the allowed scope.
  • 404 or Model Not Found: the Base URL path is wrong, or the model ID does not exist. Keep the address up to /v1 and do not add /chat/completions.
  • 429: rate limiting was triggered, or the key's spending limit was reached. Check console usage and limits.
  • Timeout: the endpoint is unreachable, there is a network path problem, or a proxy is blocking traffic. Confirm connectivity with a simple request first.
  • Context limit exceeded: check whether Cline's Context Window setting matches the model's real specification, and narrow the task scope.
  • Normal chat works but agent actions fail: suspect a model that does not support tool calling before blaming the key.
  • CLI works but the extension fails: they may read different configuration directories; check ~/.cline and the current project configuration separately.
  • Failure right after changing the key: confirm the save succeeded, and check the gateway logs for requests under the new key.

8. FAQ

Where does Cline store the key, and is it safe?

In newer versions it is in ~/.cline/data/settings/providers.json, which contains provider configuration and the API key; MCP settings may contain separate tokens. The official documentation does not promise encryption, so treat it as a sensitive file, enable disk encryption, and avoid syncing it to public locations.

Can one key be used for multiple models?

Usually yes, as long as the gateway allows that key to call those models. Whether the model scope can be restricted depends on console capabilities. If not, at least control the impact with spending limits and logs, and create separate keys for high-cost models.

How can a team share models without exposing keys?

Do not send the same key to everyone. A more reliable approach is for each person to create an independent key on the gateway, with a unified Base URL and model mapping, while administrators centrally manage limits, logs, and suspension. Create a separate key for shared services and restrict its limit.

Will rotating a key affect running tasks?

Requests already sent may not be affected, but subsequent requests will use the new key. Switch during off-peak hours, send a test request immediately after switching, and then disable the old key. For long-running tasks, confirm first whether they can be interrupted.

What should be done first after a key leaks?

Disable or delete the key first to contain the loss, then investigate abnormal usage and call sources. Do not confirm the leak path first. Afterward, check repositories, logs, chat records, and backups, and rotate other credentials if necessary.

Summary

Configuring a key in Cline is not complicated; the hard part is long-term management: traceable names, bounded limits, protected storage, and the ability to contain a leak. Start by signing up for ZSQH AI Gateway and creating a dedicated key for Cline. Once it works, tighten permissions according to team policy and review costs regularly against model pricing.

Related reading: