JetBrains LLM Setup: Custom Endpoints in IntelliJ IDEs
How to run a model of your choosing inside IntelliJ, PyCharm or GoLand — what the bundled assistant will and will not do, and the plugin route that does.
The question people arrive with is whether the assistant bundled into a JetBrains IDE can be pointed at an arbitrary OpenAI-compatible endpoint. The honest answer is that first-party assistants are generally built around their vendor service, sometimes with an option for local model runtimes, and rarely with a free-text base URL field for any provider you like.
That is a product decision rather than a setting you have not found yet. If your IDE build offers a custom endpoint field, use it. If it does not, the working route is a marketplace plugin that is a plain client of your endpoint, and the rest of this guide is about doing that well.
Check the bundled assistant first
Open the IDE settings dialog and look through the tools section for the assistant entry. What you are looking for is a model or provider sub-page, and specifically whether it offers anything other than the vendor account: an option for a local runtime, or a field asking for a server address.
If there is a local runtime option and you are running models on your own machine, that may be all you need, and it will be better integrated than any plugin. If the only choice is the vendor account with a model dropdown, you have your answer and no amount of further clicking changes it.
Do not skip this check because of something you read six months ago. This area moves quickly, and the settings search box will find the page faster than a click path from memory.
The plugin route
The marketplace has several plugins that exist precisely to talk to arbitrary endpoints. What you want from one is unglamorous: it should let you enter a base URL, a key and a free-text model name, it should support tool calling if you want an agent rather than a chat window, and it should be actively maintained against your IDE version.
That last point does more damage than any other. JetBrains platform APIs change with each release, and an abandoned plugin stops loading after an upgrade — usually the morning of a deadline. Check the last update date and the compatibility range before installing, not after.
Install from the plugin marketplace inside the IDE rather than a downloaded archive, so updates arrive automatically. Expect a restart. Then find the plugin settings page, which will be somewhere under the tools section of the settings dialog with the plugin name on it.
The three values, and the one that always breaks
The base URL is the root of your provider OpenAI-compatible surface, ending at the version segment. Most clients append the operation path themselves, so including it yourself produces a doubled path and a 404 that reads like an authentication failure. If the plugin field is labelled as a full endpoint rather than a base, that expectation is reversed — read the label carefully. The compatibility explainer covers what else on that surface is portable.
The key is a bearer token. JetBrains IDEs have a password safe backed by the OS keychain, and a decent plugin stores the key there rather than in a settings XML file. If a plugin writes the key into a configuration file in your project directory, treat that as a reason to choose a different plugin — those files get committed.
The model identifier is forwarded verbatim, so it must match exactly what your provider publishes. There is no fallback for an unknown name. If the plugin offers a dropdown populated from the provider model list, use it; that is one fewer thing to type wrongly.
Settings scope and sharing the configuration
JetBrains splits configuration between IDE-level settings and project-level files. The model choice is worth putting where the whole team gets it, so behaviour is consistent between developers; the key is never that place.
If your team uses settings sync across machines, check what it synchronises. Synchronising a plugin configuration that contains a key means the key travels to every machine signed into the account, which is not what most people intend when they turn sync on.
Where a plugin supports project-scoped instruction files in the repository, use them. Rules about the package manager, the test command, generated directories that must not be hand-edited and how much to change at once do more for output quality than the model choice does, and they are reviewable.
Proxies, certificates and the corporate case
JetBrains IDEs run on the JVM, which has its own trust store. That single fact explains most enterprise failures: a TLS inspection appliance whose certificate the operating system trusts may still be rejected by the IDE, so the request works in a terminal and fails in the IDE with no obvious reason.
The IDE has an HTTP proxy settings page, and many plugins honour it, though ones bundling their own HTTP client may not. If you are behind an inspecting proxy, ask for the internal certificate bundle and have it added to the IDE trust store rather than trying to work around it.
When something fails, the IDE log is the place to look. Every JetBrains IDE has an action to open the log directory, and the actual status code and message will be in there while the notification popup shows something generic. Reading API errors in order is faster than guessing.
What to expect from the result
Set expectations honestly. A plugin gives you chat, inline edits and — with a good one — an agent loop over your project files. It will not be as deeply integrated as the first-party assistant, because it does not have access to the same internal indexes and refactoring machinery.
What you gain is control: your choice of model, your endpoint, your billing, and the ability to change any of those without changing IDE. Whether that trade is worth it depends on whether the bundled assistant already does what you need.
If the answer is that you mainly want an agent for larger changes, it is worth considering that the strongest tools in that category are editor-independent. A terminal agent alongside your IDE, or an extension in a second editor, may serve better than fighting the plugin ecosystem — and the same key works across all of them, which is what one key across tools is about.
The takeaway
Check the bundled assistant for a custom endpoint or local runtime option first. If it has none, pick a maintained marketplace plugin, confirm it stores the key in the password safe, set base URL and exact model name, and read the IDE log rather than the popup when it fails. Keep model choice shared and the key personal.
Common questions
Can the bundled JetBrains assistant use any OpenAI-compatible endpoint?
Generally not. First-party assistants are built around the vendor service, sometimes with support for local model runtimes. Check the assistant settings page for a server address field; if there is none, a marketplace plugin is the working route.
Why does the request work in my terminal but fail in the IDE?
JetBrains IDEs run on the JVM and use its own trust store, so a TLS inspection certificate that the operating system trusts can still be rejected. Have the internal certificate bundle added to the IDE trust store, and check the IDE log for the real error.
Where should the API key be stored?
In the IDE password safe, which is backed by the OS keychain. Avoid plugins that write keys into project configuration files, since those get committed. Also check what your settings sync includes before enabling it.