Introduction
When you browse a model page on AIPortalX, you will see an access label such as 'Open weights (unrestricted)', 'Open weights (restricted use)', 'Open weights (non-commercial)', 'API access', or 'Hosted access (no API)'. These labels are not marketing fluff—they describe the legal and technical terms under which you can use the model. Understanding them is essential before you commit to a deployment.
The open weights vs API debate often focuses on cost, but licensing and privacy matter just as much. An open-weights model gives you full control over where and how it runs, but you become responsible for infrastructure and compliance. An API model offloads operations to the provider but may limit what you can do with outputs or where data is stored.
This guide breaks down each access type, explains the licensing nuances, and shows how to choose the right one for your project. We will also point out common pitfalls that trip up teams when they mix up these categories.
Key Concepts
Open weights (unrestricted): The model's parameters are publicly downloadable, and the license allows any use, including commercial, without restrictions. Example: DeepSeek V4.1 Flash.
Open weights (restricted use): The weights are available, but the license imposes conditions—such as acceptable use policies, attribution requirements, or limits on certain applications. Example: Muse Spark Open.
Open weights (non-commercial): The weights are available, but the license prohibits commercial use. You can use the model for research, personal projects, or non-profit work, but not to generate revenue. Example: Kimi K3.
API access: The model is available via a programmatic endpoint, typically with usage-based pricing. You do not download weights; you send requests and receive responses. The provider handles infrastructure and scaling.
Hosted access (no API): The model is only available through a user interface, such as a web app or chat interface. There is no API, so you cannot integrate it into your own software. Example: ChatGPT Images 2.5.
Deep Dive
Open Weights: Unrestricted vs Restricted vs Non-Commercial
Open weights models publish their trained parameters, but the license determines what you can do with them. Unrestricted open weights (like DeepSeek V4.1 Flash) give you maximum freedom: you can fine-tune, redistribute, and deploy commercially without asking permission. Restricted-use models (like Muse Spark Open) may require you to adhere to an acceptable use policy or provide attribution. Non-commercial models (like Kimi K3) are free for research but off-limits for revenue-generating applications.
Always read the license before deploying. A model labeled 'open' is not automatically permissive. For example, Kimi K3 is a 2.8T-parameter model with a 1-million-token context window, but its non-commercial license means you cannot use it in a paid product without a separate agreement.
API Access: Convenience with Trade-offs
API access is the most common way to use proprietary models. You get a key, send requests, and pay per token or per call. The provider manages uptime, scaling, and security. This is ideal for teams that lack ML infrastructure or need to move fast. However, you are dependent on the provider's pricing, rate limits, and terms of service. Data privacy is also a concern: your inputs may be logged or used for training unless the provider offers opt-out guarantees.
Hosted Access: UI-Only Models
Some models are only available through a hosted interface, with no API. ChatGPT Images 2.5 is an example: you can use it via the ChatGPT web app, but you cannot call it programmatically. This limits automation and integration, but it may be sufficient for creative tasks where a human is in the loop. Hosted access is also common for models that are too large or too expensive to serve via API.
Cost, Privacy, and Control
Open weights give you control over data locality and can reduce per-inference costs at scale, but you pay for hardware and engineering. API access shifts costs to a variable expense and reduces operational burden. Hosted access is typically the least flexible but may be the cheapest for occasional use. Privacy-wise, open weights let you keep data entirely on-premises, while API and hosted access require trusting the provider.
Practical Application
To see how these access types work in practice, explore the AIPortalX Playground. You can test models with different access labels and compare their behavior. For example, try a prompt on DeepSeek V4.1 Flash (open weights, unrestricted) and on a hosted-only model to see the difference in interface and capabilities.
When evaluating a model, check the access label first. If you need to integrate the model into an app, API access or open weights are your options. If you need to fine-tune, open weights are required. If you just need to generate images occasionally, hosted access may suffice. Use the deployment guides to understand how to serve open-weights models yourself.
Common Mistakes
Assuming 'open weights' means 'free to use commercially.' Always check the license: non-commercial and restricted-use models exist.
Confusing API access with hosted access. Hosted-only models cannot be called programmatically, so they are unsuitable for automation.
Ignoring data privacy terms. API providers may log your inputs; open weights let you keep data in-house.
Underestimating operational costs of open weights. Hosting a large model requires GPUs, cooling, and MLOps expertise.
Forgetting to check model size and context window. For example, Kimi K3 has 2.8T parameters and a 1M-token context, which may be overkill for simple tasks.
Next Steps
Now that you understand the access types, review the models you are considering. Check their licenses and decide whether open weights, API access, or hosted access fits your needs. If you need help, browse models by task, such as question answering or image generation.
For teams building agents or automated workflows, explore AI agents and workflows tools on AIPortalX. And if you are ready to test models hands-on, the Playground is the fastest way to get started.
