{"id":"c656cf7b-a05c-4939-a8f7-8fc7a7377a02","title":"External Providers (a.k.a. Proxies)","slug":"external-providers","content":"This page explains how Saucepan handles external LLM providers, what \"custom providers\" means on a companion, and the trade-offs creators and users should be aware of.\n\n# Saucepan's focus: In-House models\nSaucepan's primary investment goes into our **in-house models**.\n\nWe tune them, evaluate them against the features on this site (chats, scenarios, lorebooks, recipes, formatting, role-play behaviors, etc.), and roll out improvements as a first-class part of the product.\n\nExternal models, by contrast, are not something we test, tune, or ship features for. \n\n**We do not provide support for external models.**\n\nIf a feature behaves oddly through an external provider, the answer will almost always be \"use one of our in-house models\". We mention this up-front because it sets the expectation: external providers are a power-user escape hatch, not a supported path.\n\n# What are external providers?\nAn external provider is any LLM endpoint that isn't run by Saucepan, talking to us through a public API (OpenAI-compatible).\n\nWe split external providers into two buckets:\n- Vetted\n- Custom (unvetted)\n\n## Vetted Providers\nThese providers are a shortlist that we have **manually reviewed**.\n\nWhen we vet a provider, our primary focus is to ensure they don't provide a way for users to easily extract data that creators have marked as hidden. We do basic checks to ensure their data handling and privacy policies meet a minimum standard, but our main focus is on scraping prevention. **We want to make sure that if a creator wishes for their definitions to be private, it stays that way.**\n\n-# Note: That being said, we are not saying this is a fail-proof way of scraping contents. As with all LLMs, if there is a will, there is a way.\n\nIf a provider is on the vetted list, by default *every* companion on Saucepan can be used with it, regardless of how the creator has configured custom-provider access. \n\n**This is the default safety net**: even when a creator has not opted in to anything custom, the vetted list still gives users some external choice.\n\n### Currently Supported Vetted Providers\n- Anthropic\n- Chutes\n- DeepSeek\n- OpenAI\n- Routeway\n- Mistral\n- Xiaomi Mimo*\n- Moonshot*\n- Z.AI*\n- Perplexity*\n- Qwen*\n\n-# *Key validation runs a small inference call and may incur a tiny cost.\n\n## Custom providers (Unvetted)\nA custom provider is an arbitrary endpoint URL that a user supplies themselves. **We have not reviewed it, we don't know who runs it, and we have no signal about what it does with prompts it receives**.\n\nUnvetted providers provide full access to every provider, and even self-hosted machines, but they are also a prime avenue for scraping sites to mass scrape all data on the platform.\n\nThat last point is the important one: **the prompt sent to an LLM contains the companion's full definition.**\n\nIf a user routes their chat through a custom provider, that provider sees the definition. If the provider is run by, or feeds into, a scraping operation, the definition is now exposed.\n\n*This is why custom providers are off by default.*\n\n### OpenRouter\nFrom the devs:\n> We've spent considerable effort trying to integrate OpenRouter directly. However, as the name suggests, they route requests to other providers rather than hosting their own models. Custom Providers was introduced as a compromise; it was either that, or no OpenRouter support at all.\n\n**This will most likely be the same reason for any other provider than routes request to other providers rather than hosting their own models.**\n\n# What do we have against scraping?\nScraping and data theft are prevalent issues across the AI space, and we refuse to be part of that problem. Some people believe that all work should be public and open and hence scraping is fine. Regardless of where you stand on that debate, our stance is simple: **we want to give creators the *choice*.**\n\nSaucepan companions are creative work. Creators put time, taste, and iteration into their definitions, and they get to decide how visible those definitions are (locked vs. open definition, custom providers vs vetted providers). A bulk-scraping operation that vacuums up prompts via a permissive endpoint undermines that choice for every creator at once.\n\nAllowing arbitrary custom providers on a companion effectively opens the definition to whoever sits behind that endpoint. We will not enable that platform-wide. Whether to take that risk on a given companion is left to the creator who actually owns the work.\n\n# How custom providers work in practice\n- **On your own companions**: You can toggle custom providers on or off per-companion. If it's on, anyone chatting with that companion can route their messages through any endpoint they configure on their own account. As the creator, you can also use any custom provider on any companion you create regardless of the public setting.\n- **On gifted or collaborated companions**: This will be treated as your own, and you can use custom providers on these as well.\n- **On other creators' companions**: If a creator has enabled custom providers on the companion, you can use a custom provider when chatting with it. If they haven't, you can't.\n- **The toggle is the creator's call**: By default, vetted providers are permitted. Creators also have the option to limit it purely to Saucepan's own in-house models. Regardless of what the creator chooses, that is entirely up to their own decision.\n\n# Don't harass creators about it\nWe're explicit about this: **harassing a creator to flip the custom-providers toggle on their companion is not acceptable.**\n\nCreators owe nobody an explanation for keeping their companion locked to vetted providers and in-house models. Pressure campaigns, repeated DMs, comment brigading, or any similar behavior aimed at getting a creator to open their companion will be treated as harassment under our community guidelines.\n\nAsking nicely is permitted, but if a creator has said no, then that is the end of it. Continuing to push for it afterwards can be a reportable action by the creator or any other users who see it.\n\nFor further information, please refer to [6.3 Respecting Creator Settings of our Community Guidelines](https://saucepan.ai/community-guidelines#creator-settings).\n\n# How do I add a custom provider?\nYou can access the settings page in two ways. The first is to go to Settings > [Providers](https://saucepan.ai/settings/providers). The second way is to click on \"Manage Providers\" from your models selector in the chat.\n\nFor the vetted providers, you will first need to test it to ensure it works before you can add it. This ensures that it is not possible to add an invalid configuration. Some of them provide an endpoint for us to check whether the configuration is valid or not. Some others do not have this so it needs to send a test inference call. This will take approximately 100 tokens and might cost you money (prefer refer to the list above or see the list when adding the provider).\n\nFor custom providers, there is a button for you to test whether it is working or not, but you can still save it without completing a test.\n\n**Note: Once a configuration is saved, you can't change the API key and URL again.**\n\n# Summary\n- Saucepan's focus is **our in-house models**; external models are not officially supported.\n- If you experience any issues with external providers, **it is not our responsibility**; please check with the provider side itself.\n- **Vetted providers** available by default unless the creator restricts to in-house models only, even on companions that don't allow custom providers, because we've reviewed them for scraping and other concerns.\n- **Custom providers** are unvetted and have not been reviewed for scraping and other concerns, and so are off by default.\n- Each creator decides whether their companion allows custom providers. **Respect that decision.**","access_level":"public","category_id":"3c7ca2fc-68c5-4229-adff-af8aa151a47b","display_order":100,"keywords":["external providers","proxy","proxies","custom provider","openrouter","byok","api key","llm","models"],"description":"How external LLM providers (proxies) work and the trade-offs.","created_at":"2026-05-04T09:10:09.47918Z","updated_at":"2026-08-22T11:27:17.303186Z"}