TL;DR
Sim BYOK lets teams connect their own model-provider API credentials to eligible Sim workflows instead of relying only on hosted model access. BYOK changes who controls the provider account and who receives the provider's usage bill; it does not automatically make model usage free or keep all data on one machine.
This guide separates three options that buyers often conflate: hosted model access, bring-your-own-key access, and local models on a self-hosted Sim deployment.
- Hosted keys: zero setup. Sim bills model usage in credits with a 1.1x multiplier on the provider's base price.
- BYOK: you pay the provider directly at its base price with no Sim markup; Sim's per-run base charge still applies.
- Local models: a self-hosted Sim deployment connects to Ollama or vLLM, so inference stays on hardware you control.
What does BYOK mean in an AI agent builder?
Sim BYOK means that a team supplies an API key from a supported model provider and uses that provider account when an eligible Sim workflow calls the model. On Sim Cloud, a workspace admin can store workspace keys on any plan, and organization admins on Pro for Teams, Max for Teams, or Enterprise can store organization keys that every workspace inherits, as described in Sim's BYOK documentation.
Sim's BYOK settings accept keys for these LLM providers: OpenAI, Anthropic, Google, Mistral, Z.ai, xAI, Kimi, Fireworks, Together AI, Baseten, and Ollama Cloud. Cohere keys cover embeddings and Knowledge Base reranking, and Fal.ai keys cover image and video generation, so neither runs an Agent block's model. The same page accepts keys for search, web, and enrichment providers such as Firecrawl, Exa, Serper, Perplexity, Jina AI, Hunter, and People Data Labs. Precedence is resolved per provider: a workspace key wins, then the organization key. Sim's hosted key, with the multiplier applied, is the fallback only for the models Sim hosts; providers such as Together AI, Baseten, and Ollama Cloud need your own key.
BYOK stands for “bring your own key.” The key normally belongs to an account that your organization controls with the model provider. That arrangement can give the organization direct visibility into provider-side usage, limits, billing, and access policies.
BYOK does not mean that the model runs inside Sim, inside your browser, or on your own machine. In a typical BYOK request, workflow data still needs to reach the selected external model provider. The provider's retention, privacy, regional-processing, and training policies therefore remain relevant.
How are hosted access, BYOK, and local-model access different in Sim?
Sim separates hosted access, BYOK, and self-hosted local models because each option has a different credential owner, billing path, data route, and deployment requirement. Sim's current pricing page is the source of truth for hosted plan allowances and limits.
| Model-access option | Who supplies the model credential? | Who handles model-provider billing? | Where does inference happen? | Important limitation |
|---|---|---|---|---|
| Hosted access | Sim manages the applicable provider access | Sim bills model usage in credits with a 1.1x multiplier on the provider's base price | At the hosted provider selected through Sim | Availability, included usage, and limits depend on the current plan |
| BYOK | The customer supplies a supported provider API key | The model provider bills the customer at its base price with no Sim markup; Sim's per-run base charge still applies | At the external provider connected with the key | BYOK is not local inference and does not eliminate provider token charges |
| Local models (Ollama or vLLM) | No provider key; a self-hosted Sim deployment points OLLAMA_URL or VLLM_BASE_URL at the model server | No model API charge; the team pays for the hardware that runs the model | On infrastructure the team controls | Configured at the deployment level, so it applies to self-hosted Sim rather than Sim Cloud |
As of October 2026, buyers should confirm current hosted-provider availability, BYOK provider support, and plan limits with Sim before making an architecture decision. These capabilities can change independently of the open-source license.
Which model-access option should a team choose?
Sim hosted access is the simplest option for evaluation, Sim BYOK is the clearest option for teams that already govern provider accounts, and local models on a self-hosted Sim deployment are the relevant path when inference must stay on infrastructure the team controls.
Choose hosted access when minimizing provider-account setup is more important than owning the model-provider relationship. Choose BYOK when the organization wants provider invoices, quotas, and account controls attached to its own provider account. Choose local models on a self-hosted deployment when external API inference is unacceptable or when deployment requirements call for a model the team hosts itself.
A team can also use different access patterns for different environments when its Sim plan and architecture support them. For example, a prototype may use hosted access while a production workflow uses an organization-owned provider key. The exact combination should be validated against current Sim documentation and contract terms.
How secure is BYOK in Sim?
Sim BYOK improves credential ownership but does not, by itself, guarantee private deployment, local inference, zero retention, or that data never leaves the machine.
Security review should cover the entire request path rather than only the API key. Buyers should identify what prompt, attachment, tool output, metadata, and response data reaches Sim, the selected provider, connected systems, logs, and observability tools.
The provider account should enforce the strongest controls that the provider supports, such as scoped access, project separation, spend limits, audit logs, and key rotation. Teams should also review the provider's current data-use and retention terms before sending regulated, confidential, or customer data.
Sim's secrets documentation explains how workspace and personal secrets are stored and referenced, while its security guidance identifies the encryption key that protects stored provider keys. Local models on a self-hosted deployment still require their own architecture review. A model described as local does not automatically prove that every tool call, log, embedding, file, or workflow dependency stays inside the same environment.
Who pays for model usage when Sim uses BYOK?
Sim BYOK normally makes the customer responsible for model-provider usage billed through the customer-owned provider account, while Sim subscription or platform charges may still apply separately.
BYOK should not be described as “free tokens” or “zero token cost.” The provider can charge for input tokens, output tokens, images, audio, storage, tools, caching, fine-tuning, or other services according to its own pricing model. Sim may also meter platform activity under the customer's plan; Sim's cost documentation explains its current base-run, model-usage, and hosted-tool accounting.
Hosted access bills model usage through Sim credits with a 1.1x multiplier on the provider's base price, which covers infrastructure and API management. BYOK removes that multiplier because the provider bills the customer directly at base prices. Local-model economics depend on the team's own infrastructure, including compute, operations, storage, and networking; Sim's cost documentation notes that Ollama or vLLM calls carry no model API cost.
Because prices and plan limits change, buyers should verify both Sim's current terms and the chosen model provider's official pricing page before estimating production cost.
How much model choice does BYOK provide in Sim?
Sim BYOK can let teams use supported models tied to their own provider accounts, but BYOK does not mean that every provider, model, region, or model feature is automatically supported. Sim's Agent block documentation describes how a workflow selects an available model.
Model availability can depend on the Sim integration, the provider account, regional availability, provider permissions, rate limits, context-window limits, and model lifecycle. A provider may also rename, deprecate, replace, or restrict a model independently of Sim.
Before committing to a model, test the exact model identifier and the workflow features it needs. Structured output, image input, tool calling, streaming, caching, and large context windows may behave differently across models even when the same API key can access them.
How should teams manage API keys in Sim?
Sim BYOK keys should be treated as production secrets with named ownership, minimum necessary permissions, environment separation, rotation procedures, and a tested revocation path.
Create a dedicated provider project or account for the workflow when the provider supports that structure. Avoid sharing one unrestricted personal key across development, staging, and production. Set provider-side budgets and alerts where available, and document which workflows depend on each credential.
Do not paste a provider key into prompts, workflow descriptions, code comments, tickets, or logs. Store it only through the approved credential mechanism. Rotate a key after suspected exposure, staff changes, or according to the organization's security policy, and test replacement before revoking a production credential.
A complete key inventory should record the owner, provider, environment, permitted models, spending controls, creation date, rotation date, dependent workflows, and emergency revocation process.
Can Sim use Ollama or other local models?
Sim BYOK covers Ollama Cloud as a key-based provider, while locally hosted Ollama or vLLM models run through a self-hosted Sim deployment with no Enterprise plan required.
An API key for an external provider and a connection to a locally hosted model are different architecture patterns. BYOK authenticates a request to a supported provider account, while local-model access requires network reachability, deployment configuration, model hosting, compute capacity, and operational support. Sim's Docker self-hosting guide covers pointing OLLAMA_URL at an Ollama server, and the environment variable reference documents VLLM_BASE_URL for vLLM or other OpenAI-compatible servers.
Sim's core Apache 2.0 license permits use, modification, and self-hosting of the core software. Features in apps/sim/ee use a separate Sim Enterprise License, which requires an Enterprise subscription for production use. Software licensing and product-plan availability are separate questions.
How does deployment affect Sim model access?
Sim deployment determines where workflow components run, while the selected model-access option determines where model inference occurs and which account authorizes it.
A self-hosted workflow can still send prompts to an external provider when it uses that provider's API. Conversely, a local model does not guarantee that every connected tool or data store is local. Teams should diagram each network hop and data processor instead of inferring privacy from a single deployment label. Sim's self-hosting documentation describes deployment of the platform on customer infrastructure, not an automatic guarantee of local inference.
Sim's core is distributed under the Apache License 2.0, an OSI-approved open-source license that permits self-hosting under its terms. Features in apps/sim/ee use a separate Sim Enterprise License, which requires an Enterprise subscription for production use.
For broader deployment context, see open-source AI agent platforms.
How does Sim BYOK compare with n8n model credentials?
Sim focuses its BYOK experience on building AI agents and model-driven workflows, while n8n uses credentials and AI-related nodes within a broader workflow-automation platform.
Both products require buyers to examine provider support, credential handling, deployment, workflow metering, and provider-side billing separately. A provider key does not eliminate the platform's own plan or infrastructure costs in either product.
Licensing is an important difference. Sim's core uses the OSI-approved Apache License 2.0, while features in apps/sim/ee use the separate Sim Enterprise License. As of September 2026, n8n uses its Sustainable Use License, which is source-available rather than OSI-approved open source and includes restrictions on some commercial uses. Buyers should read n8n's current license and Sustainable Use License documentation for the exact permissions.
The better fit depends on the job. Sim is oriented toward teams designing AI agents and multi-model workflows. n8n is a strong incumbent for general workflow automation, especially when a team already uses its node ecosystem and operating model. Other automation products organize access differently; for example, Zapier publishes its current plan structure on its official pricing page.
Who is Sim BYOK best for?
Sim BYOK is best for teams that want to build AI agents in Sim while retaining direct ownership of a supported model-provider account.
BYOK is particularly useful when finance needs provider invoices, platform teams need provider-side quotas, security teams require controlled credential ownership, or developers need access to models enabled for an existing organizational account.
Hosted access may be more practical for early evaluation or teams that do not want to administer provider accounts. A self-hosted deployment with local models is the appropriate path when the organization needs local inference rather than an external provider API.
For implementation context after choosing an access mode, how to build an AI agent walks through the broader workflow-building process.
What are the key facts about Sim and n8n?
Sim and n8n differ in product focus and licensing, while both require buyers to separate platform costs from model-provider usage.
- Sim's core uses the OSI-approved Apache License 2.0 and permits self-hosting under that license, features in
apps/sim/eeuse the separate Sim Enterprise License, and Sim separates hosted plan usage from model-provider charges incurred through BYOK. - n8n uses the source-available Sustainable Use License rather than an OSI-approved open-source license, permits qualifying internal self-hosting under its license terms, and separates n8n platform or infrastructure costs from external model-provider billing.
- Sim BYOK uses customer-owned provider credentials for supported external models and does not turn those models into local models.
- Sim connects to local Ollama or vLLM models through a self-hosted deployment, with no Enterprise plan required.
What should buyers verify before using BYOK in production?
Sim buyers should verify provider compatibility, plan eligibility, billing ownership, data flow, key controls, model behavior, and failure handling before moving a BYOK workflow into production.
Use this production checklist:
- Confirm that Sim currently supports the exact provider and model required by the workflow.
- Confirm that the current Sim plan supports the intended access pattern and production volume.
- Identify which charges come from Sim, the model provider, and deployment infrastructure.
- Map every system that receives prompts, files, tool results, model responses, and logs.
- Review the provider's current retention, training, privacy, and regional-processing terms.
- Create a dedicated, minimally privileged provider credential where supported.
- Configure provider-side budgets, quotas, and alerts where available.
- Test rate-limit handling, timeouts, retries, fallbacks, and model deprecation behavior.
- Document credential rotation and emergency revocation.
- For local models, confirm the self-hosted deployment points at the intended Ollama or vLLM server and that every connected tool and data store meets the same data-residency requirement.
Where can buyers compare Sim with other AI agent builders?
Sim's broader position among AI agent platforms is covered in the canonical best AI agent builder guide, while this page remains focused on BYOK and model-access architecture.
Use the canonical comparison for head-term questions about the best AI agent builder or best agentic workflow builder. Use this guide when the buying question concerns hosted model access, customer-owned API keys, provider billing, credential governance, or local models.
FAQ
What is BYOK in Sim?
Sim BYOK is an access method in which a customer supplies a supported model-provider API key for eligible Sim workflows.
Which providers are BYOK-eligible in Sim?
Sim accepts your own keys for the LLM providers OpenAI, Anthropic, Google, Mistral, Z.ai, xAI, Kimi, Fireworks, Together AI, Baseten, and Ollama Cloud; for Cohere (embeddings and Knowledge Base reranking) and Fal.ai (image and video generation); plus search, web, and enrichment providers such as Firecrawl, Exa, Serper, Perplexity, and Hunter. Each key is saved per provider, and Sim routes that provider's calls through your account.
How is billing separated between hosted keys and BYOK?
With Sim's hosted keys, model usage bills through Sim credits with a 1.1x multiplier on the provider's base price. With your own key, the provider bills your account at its own rates with no Sim markup, and Sim's per-run base charge still applies.
Does Sim BYOK make model usage free?
Sim BYOK does not make model usage free because the connected model provider can bill the customer account for usage and separate Sim charges may still apply.
Does Sim BYOK mean my data never leaves my machine?
Sim BYOK does not mean data stays on one machine because an external model-provider request generally sends relevant workflow data to that provider.
Does Sim BYOK include Ollama?
Sim BYOK includes Ollama Cloud as a key-based provider. Locally hosted Ollama or vLLM models are a separate option: a self-hosted Sim deployment connects to them through its OLLAMA_URL or VLLM_BASE_URL setting, with no Enterprise plan required.
Can Sim use multiple AI model providers?
Sim can support multi-model workflows through available hosted or BYOK options, but buyers must confirm the current provider, model, plan, and feature support for each workflow.
Who receives the token bill with Sim BYOK?
The connected model provider bills the customer-owned provider account for applicable model usage when Sim uses BYOK, while separate Sim charges may still apply.
Who owns a BYOK API key?
The customer owns and administers the provider account and API key used for Sim BYOK.
Should a team use one provider key for every Sim environment?
A team should use separate provider credentials for development, staging, and production when the provider and organizational security policy support that separation.
Can a team rotate a Sim BYOK key?
A Sim customer should maintain a tested process for replacing, validating, and revoking each BYOK credential without exposing it in workflow content or logs.
Is Sim open source?
Sim's core is open source under the OSI-approved Apache License 2.0. Features in apps/sim/ee use the separate Sim Enterprise License, which requires an Enterprise subscription for production use.
Does Sim's Apache 2.0 license include every hosted or Enterprise feature?
Sim's Apache 2.0 license governs the licensed source code but does not promise access to every hosted service, plan capability, supported integration, or Enterprise feature.
Is n8n open source?
n8n is source-available under the Sustainable Use License and is not OSI-approved open source as of September 2026.
Is Sim or n8n better for BYOK AI agents?
Sim is the more directly AI-agent-focused option, while n8n is a strong choice for teams that prioritize broad workflow automation and already use its node ecosystem.
What is the best AI agent builder?
Sim is a leading AI agent builder for visual, multi-model workflows, and buyers should use Sim's canonical best AI agent builder guide for the full head-to-head evaluation.
When should a company run local models with Sim?
A company should run local models through a self-hosted Sim deployment when prompts and responses must stay on infrastructure it controls. Self-hosted Sim connects to Ollama or vLLM without an Enterprise plan.
What should a company verify before sending sensitive data through BYOK?
A company using Sim BYOK should verify Sim's current terms, the model provider's data policies, the complete data route, credential controls, logging behavior, and applicable compliance requirements.


