Kilo Code runs in VS Code, JetBrains and the CLI

Kilo Code provides a VS Code extension, a native JetBrains plugin and a command-line interface. Its current JetBrains documentation describes the v7 plugin without a Node.js requirement. These options let teams use their preferred editors, while still testing each integration’s behaviour.

  • One config file: kilo.jsonc holds providers, models and token limits for all three surfaces, so a setup you debug in VS Code is the same file your JetBrains colleagues read.
  • One provider model: any OpenAI Chat Completions endpoint can be attached as a custom provider, which is the integration point this guide uses.
  • One model reference format: models are addressed as provider_id/model_id everywhere, in the picker, in the config and in the CLI.

Share provider and model settings across editors, but keep credentials out of the repository. This example reads the key from LYCEUM_API_KEY. Each participant supplies their own configured key in the environment used by Kilo. Shared settings do not make every editor integration or workflow behave identically.

The integration point is an OpenAI-compatible endpoint. Kilo Code connects to any provider that speaks the OpenAI Chat Completions format, which is what lets an enterprise team point the agent at open-weight models billed per token instead of per-seat closed-model licences. We compared the economics in detail in our guide to the best open model APIs for agentic coding; this article stays on the wiring.

Installing Kilo Code and creating a Lyceum key

You need two things before anything connects: the extension or plugin in your editor, and an API key from the dashboard. Both take a few minutes. Follow Kilo's installation page on the day you install, since the distribution channels move.

  1. Open VS Code and go to Extensions (Ctrl+Shift+X / Cmd+Shift+X).
  2. Search for "Kilo Code".
  3. Click the dropdown arrow next to Install and select Install Pre-Release Version. The pre-release label is a Marketplace distribution channel, not a stability warning: the current build ships there.
  1. Open Settings, go to Plugins, and open the Marketplace tab.
  2. Search for "Kilo Code" and install the plugin.
  3. Enable automatic plugin updates so the JetBrains plugin tracks current releases.

Then create the key. Sign in to the dashboard, open the API keys section, and generate a key. Store it in your password manager or secrets manager rather than pasting it into shared chat; the key is what bills tokens to your account. With the editor side installed and the key in hand, the rest of the setup is one provider entry and one config file.

Adding Lyceum as a custom OpenAI-compatible provider

Kilo Code stores provider configuration in its Settings dialog. Open Settings (the gear icon), go to the Providers tab, scroll to the bottom and click Custom provider.

  • Provider ID: a unique identifier of your choice, for example lyceum. It becomes the provider_id in the provider_id/model_id format.
  • Display name: a human-readable name shown in the UI, for example Lyceum.
  • Provider API: select OpenAI Compatible. This is the setting for OpenAI Chat Completions-compatible endpoints.
  • Base URL: exactly https://api.lyceum.technology/openai/v1
  • API key: your Lyceum key, for example lk_your_api_key_here.

With a valid endpoint and key, Kilo can fetch models from the provider’s OpenAI-compatible model-list route. For this base URL, that is https://api.lyceum.technology/openai/v1/models. Search for the intended model ID, or enter it manually when discovery is unavailable. A valid URL does not guarantee a complete list during temporary backend or capacity problems.

For this guide, pick moonshotai/kimi-k2.7-code from the picker. It is a coding-focused model with a 256K-token context window and tool calling, hosted in eu-north1. If you want the broader comparison across Moonshot's lineup before committing, we cover where to run Kimi models in Europe separately. The same custom-provider pattern, by the way, is what we documented for terminal agents in Using Lyceum Models in opencode: Custom Provider Setup.

Setting context and output limits in kilo.jsonc

The Settings dialog does not expose token limits. For those you edit the kilo.jsonc config file directly, where every model field is optional and merges over the built-in defaults when the model ID matches the catalog.

{
  "provider": {
    "lyceum": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://api.lyceum.technology/openai/v1",
        "apiKey": "{env:LYCEUM_API_KEY}"
      },
      "models": {
        "moonshotai/kimi-k2.7-code": {
          "name": "Kimi K2.7 Code",
          "limit": {
            "context": 262144,
            "output": 16384
          },
          "tool_call": true
        }
      }
    }
  },
  "model": "lyceum/moonshotai/kimi-k2.7-code"
}

The context value records the model’s 256K window as 262,144 tokens. The output value of 16,384 is the response budget chosen for this example, not a claim about the model’s maximum. The company catalogue lists $1.25 per million input tokens and $4.50 per million output tokens. Check the current dashboard for the cached-input rate before estimating a bill.

Set limit.output to a response budget within the provider’s limits. The 16,384-token value here is an example, not a guarantee of task quality or a total spend cap. Repeated requests and reasoning can still consume more tokens. The model reference lyceum/moonshotai/kimi-k2.7-code must use the same provider ID as your configuration.

Limits left at zero and other setup traps

Limits resolve from your model configuration, then the built-in catalogue, then a fallback. When neither source supplies a context limit, context defaults to 0 and automatic compaction is disabled. The conversation can then exceed the provider’s limit. Set explicit context and output values for this custom model.

  • When neither model configuration nor the catalogue supplies an output limit, Kilo’s documented fallback is 32,000 tokens. Set your chosen response budget explicitly.
  • For connection failures, check the URL, key, exact model ID, account access and provider availability. The error alone may not identify the cause.

The connection errors at least announce themselves. Kilo's troubleshooting list maps them directly: an invalid key means re-enter the key, Model Not Found means the model ID does not match what the provider exposes, and connection errors mean the base URL is wrong or unreachable. The subtler risk is behavioural drift after a model change, which is why we test function calling and context handling before switching: we wrote up what breaks when you switch models on an OpenAI-compatible API as its own checklist.

Verifying the model with a first task

One verification pass before rollout, two steps. First confirm the key can see the model list from outside the editor, so a dashboard-side problem does not masquerade as a Kilo misconfiguration:

curl https://api.lyceum.technology/openai/v1/models \
  -H "Authorization: Bearer lk_your_api_key_here"

Look for moonshotai/kimi-k2.7-code in the model list. If it is missing, check the ID, account access and current provider availability; the cause is not necessarily the key. Then run a small task in a familiar repository, confirm the selected model, inspect actual tool calls and review the result.

Verification consumes billable tokens at the selected model’s rates. Record actual usage, including reasoning, retries and failures, before estimating rollout cost. A repository’s size alone does not establish the price of a task.

Create an API key in the Lyceum dashboard and run your first Kilo Code task on your own repository.