AI Providers

Fruxon doesn't resell inference. You connect your own provider accounts, your own API keys, and your spend goes directly to OpenAI / Anthropic / Google / etc. The platform handles the orchestration; the model bill is yours.

Supported providers

Each provider has its own configuration — most need an API key; some need additional fields (region, project ID, resource name).

Connecting a provider

1. Open the agent in Studio.
2. Open the Configuration Panel (left sidebar) and select AI Providers.
3. Find the provider, expand it.
4. Paste the API key (and any additional fields).
5. Click Test to validate.
6. Click Save.

A Configured badge appears once the key is saved and validated.

You can connect multiple providers simultaneously — that's the whole point. Different agents can use different providers without copying keys.

Using a provider in an agent

1. Open the agent's form in Studio and expand Model & capabilities.
2. Pick the provider's config under LLM Config.
3. Pick the Model.
4. Set provider-specific knobs (temperature, max tokens, top-p, reasoning mode, etc.) under Model parameters.

Different agents can use different providers, or different keys for the same provider — useful for billing isolation. Fallback providers name where the agent's call goes when its primary provider won't answer.

Per-agent vs per-organization

Provider keys are configured per agent. This is intentional:

• Each agent can use distinct keys (separate billing, blast radius).
• A dev agent and a prod agent can be wired to different accounts without copying.
• Agents run together in a workflow inherit nothing from each other — each agent's keys are independent.

If you have many agents and want to share keys, the organization-level pattern is to use the same key in each agent's config. (Organization-shared key bindings are on the roadmap.)

Mixing models for cost and quality

The economical pattern is to give each agent the model its job needs:

• Use a fast, cheap model (Haiku, GPT-4o-mini, Gemini Flash) for agents that route, classify, or do simple extraction.
• Use a strong model (Opus, GPT-4o, Gemini Pro) for agents that write the user-visible answer.
• Use a reasoning model (o-series, Claude with extended thinking) only on agents that genuinely benefit from it — they're slower and more expensive.

Cost & Budgets breaks down how these decisions show up in your bill.

Bring-your-own cloud (Vertex AI, Bedrock & Azure)

For regulated or sovereign deployments where inference needs to stay inside an account you control, Fruxon groups these under Your cloud on the providers page — the model runs in your cloud tenancy, governed by your IAM, billed to your cloud contract:

• Google Vertex AI — run Claude and open models (DeepSeek, Qwen, GPT-OSS, Kimi) in your own GCP project. Enter your project, region, and service-account credentials once: the single Vertex credential fronts both Claude and the open models, so there's no pasting the same key twice or keeping two connections in sync. In an agent's form, that one credential surfaces both families in the model picker — pick the model and the connection follows.
• AWS Bedrock — run Claude, Nova, Llama, and other Bedrock-hosted models in your AWS account. Configure your region and credentials in the Bedrock provider; Fruxon orchestrates without proxying inference.
• Microsoft Foundry (Azure) — run OpenAI and Claude models deployed in your own Azure subscription, billed to your Azure account. One Foundry resource and key serve both families, so — as with Vertex — you enter the credential once, on Microsoft Foundry, and Microsoft Foundry (Claude) borrows it. See Microsoft Foundry below.

Microsoft Foundry

Foundry is two providers on one credential, because OpenAI and Claude models speak different APIs on the same resource:

Set up the credential on Microsoft Foundry; the Claude provider uses it as is:

Azure calls a deployment, not a model. In Foundry you deploy a model under a deployment name, and requests address the deployment. Fruxon calls each model through a deployment named after its model id — the name the Foundry portal suggests when you deploy, so if you kept it there's nothing more to enter. If you named a deployment differently, list it under Deployment names as model-id=deployment-name pairs separated by commas:

gpt-5.4=prod-gpt54, claude-sonnet-5-5=sonnet

A model you don't list is still called through a deployment named after its model id. Deploy every model your agents use: a model with no matching deployment fails when it's called, with an error telling you to deploy it in the Foundry portal or map it under Deployment names.

Testing the credential. Test lists the resource's models, which proves the resource exists and accepts the key. It also makes a one-token call to Claude Haiku 5.5 through its deployment. If the resource has no such deployment, the test still passes, with a note that Claude wasn't called — a resource you use only for OpenAI models doesn't fail its test over Claude. A rejected key fails the test either way.

Residency. Both providers sit under Your cloud and satisfy the inference residency setting Your own cloud only. Neither satisfies Your own cloud, in-region only: a resource name doesn't say where a deployment runs — a Global Standard deployment is served from any Azure region with capacity — so Fruxon can't show the call stays in one region, and that setting refuses both.

Content filter. Azure runs every deployment behind a content filter. A prompt the filter blocks fails as a problem with the prompt, not with your provider config: rephrase the prompt or the content it includes, or relax the content filter on the deployment in the Foundry portal.

No built-in web search. Neither Foundry provider offers the model's built-in web search. An agent that needs to search the web can use a search integration such as Tavily or Google Search.

Cost. Usage is priced at OpenAI's and Anthropic's list rates, which is what Foundry charges for Global Standard deployments. Data Zone and Regional deployments cost more than Fruxon reports for them.

Security

• API keys are encrypted at rest.
• Keys are never logged or echoed in traces — only the placeholder reference is captured.
• Editable only by Admins; not viewable after save (write-only).
• Rotate by overwriting; revoke by deleting.

Security →

Provider data handling

Fruxon doesn't train any models on your data and doesn't proxy your prompts through third parties. Prompts and outputs flow directly between Fruxon's runtime and your chosen provider.

Provider data policies still apply for inference itself — confirm in your contract with the provider:

• OpenAI's enterprise default: not used for training.
• Anthropic's API default: not used for training.
• For zero-retention guarantees: most providers offer it on enterprise contracts; configure it in your provider account.

Troubleshooting connections

Troubleshooting →

Next steps

• Agent Studio — pick a provider in the agent's form
• Cost & Budgets — track spend per model
• Security — how keys and secrets are protected
• Tools & Skills — what the model can do