Bringing your own API key to Agent.Space means connecting a model provider you already pay to a shared Workspace. The Workspace owner saves the connection, Agent.Space checks the selected models, and members with permission to run Agents can choose compatible models without receiving the owner's key.
The important distinction is between a successful API connection and a model that can complete an Agent's tool loop. A provider can return a text answer but still reject the follow-up request after a tool runs. Start with one model and one small task before sharing the connection more widely.
This guide covers the Workspace-owned model connection reviewed on October 12, 2026. Feature availability follows the product release: first check whether your Workspace settings show Your own models. The instructions do not assume that every computer type supports the same route, and they do not report a test with your provider account.
BYOK and the Developer API run in opposite directions
BYOK means “bring your own key.” Here, you bring a provider's API into an Agent.Space Workspace. The provider handles the model usage bill.
The Agent.Space Developer API goes the other way: you create an Agent.Space key to use Agent.Space model access in an external client or server application. Its endpoint examples are not instructions for configuring your own provider inside a Workspace.
Neither route turns a ChatGPT or Claude subscription login into an API key. Before connecting a company account, confirm that its owner permits this use and knows which Workspace will spend against it.
Prepare the owner account, endpoint, and a limited test
The Workspace owner manages the connection. Access to a shared model does not grant permission to run Agents to a read-only member; normal Workspace roles still apply.
Have these ready:
- The provider's documented API address and a key authorized for the intended models.
- One or two exact model IDs to test, rather than the whole catalog.
- A provider-side usage budget or alert, where available.
- A non-sensitive sample project for the first tool-using task.
Use the provider preset when it matches your account's endpoint. For a custom endpoint, the current connection expects a publicly reachable HTTPS address. A service reachable only at localhost or inside your company's private network will not become reachable from the cloud just because the address works on your laptop.
The connection checks Responses and Messages, two API formats used by coding Agents. A service that offers only Chat Completions is not automatically compatible. Likewise, a provider's “OpenAI-compatible” label is not sufficient evidence that it supports all the requests your chosen Agent sends.
Keep the key in the connection form, not a prompt, project file, screenshot, or support message. Use a separate key for this integration where practical, and keep a rotation plan.
Connect, check the models, then select one
- As the owner, open Workspace settings → Your own models and add a provider.
- Select the matching preset or enter the custom address, then provide the key.
- Choose a small set of models from the discovery result. If the provider does not expose a usable model list, use the interface's manual model-ID entry and copy the exact ID from the provider.
- Run the compatibility check and inspect each model's result, including the Agents it can serve. Saving a provider is not the same as every selected model passing.
- If the cloud computer is already running, save ongoing work and coordinate with other members before following the restart prompt. Do not restart a shared task silently.
- Reopen the conversation's model menu. Your own models are grouped by provider near the top; choose a model compatible with the current Agent.
The check includes a prior conversation, a streamed tool call, and a follow-up request carrying the tool result. It also checks that the streams finish. That is more relevant to an Agent than a greeting-only test, but it does not certify every tool, attachment type, provider extension, or long conversation.
Detection itself sends requests to your provider. Treat it as potentially billable usage, not an offline validator.
If the model passes but does not appear in Codex
Codex needs more than a recognizable model name. Its request path uses Responses and reasoning-related fields, so a model that works with another Agent may still be unavailable to Codex.
The connection checks reasoning compatibility as well as the tool loop. For a model absent from the platform catalog, a passing reasoning check can establish the capabilities needed for Codex; it is not enough that the provider lists the model.
Check the model's Agent compatibility result and the message under its provider in the menu. If the connection was saved before a compatibility improvement, edit it and run the check again. Then follow any restart prompt and reopen the menu.
Do not rename an incompatible model to look like a supported one. Use a supported model–Agent pairing, or ask the provider about the exact rejected request format. Keep the timestamp, model ID, protocol, and redacted error; leave out the key.
Separate model charges, other activity, and key access
Calls through the Workspace's own-model connection go to the owner's provider and do not consume Agent.Space plan allowance or credits for those model calls. The provider may still charge the owner. “No Agent.Space charge for this model call” does not mean free inference, unlimited provider capacity, or that every other Workspace activity uses the same billing path.
For example, choosing an own model for an Agent task does not establish how separate automatic tasks are funded. Check other product charges and the provider's usage records independently rather than inferring a zero total bill.
The saved key is encrypted, and members do not receive its secret value through the normal Workspace interface. Agent.Space nevertheless stores and uses the credential to make the connection work. This is not a claim that the key or project data never passes through platform infrastructure.
Members who can run Agents may cause provider usage even though they cannot read the key. Use a dedicated provider key where practical, review membership, and set limits at the provider. If the key is exposed elsewhere, revoke or rotate it through that provider, then update the Workspace connection.
Verify one small task before team-wide use
A useful acceptance test is deliberately narrow:
- Select the intended Agent and own model in a sample project.
- Ask it to inspect a non-sensitive file and summarize it without editing.
- Confirm that a tool actually ran and the Agent continued with a usable answer.
- Match the time and model to the provider's usage record, when that record is available.
- Ask an authorized teammate to confirm the same compatible model is selectable without sharing the key itself.
This verifies a particular connection and workflow. It does not prove that a long task, every model, or another computer type will behave identically. If the tool call works but the continuation fails, preserve the provider's response and stop repeated retries until that compatibility problem is understood.
Ready to use an existing provider account with a shared project? Open Agent.Space, check the target Workspace's Your own models entry, and start with one authorized key and one compatible model. Keep the provider's bill and the project's access rules visible as you expand usage.