Today we are shipping Connic Models: 30 models from nine creators, running across multiple inference providers, unified behind a single set of IDs that every Project can use right now. You name one in a line of agent YAML. No provider account, no API key, no region flag, and every call stays on EU inference capacity.
This is the release we have wanted to make since Connic started, because it removes the one step in getting an agent live that had nothing to do with building an agent. You wrote the YAML, you wrote the tools, and then you stopped to open an account with a model provider, add a card, generate a key, paste it into every environment, and work out for yourself whether the endpoint you had been given sat in the EU. That detour is now optional.
What are Connic Models?
Connic Models are managed models that Connic makes available to every deployed Project under the connic/ prefix, running on EU inference capacity. You select one by writing its exact catalog ID in the model field of an agent, the same field that has always taken a provider prefix and a model ID. Usage is charged against Project credit, the balance that already pays for runs, compute, storage, and retrieval.
The word doing the work there is managed. Multiple inference providers sit behind the catalog, and a connic/* ID is your single interface to all of them: one ID, one published rate, one line of config, one bill, and one set of capabilities you can read off a table. You never sign up with those providers, never hold their keys, never learn their model naming, and never write code to move between them. When a route is unavailable, Connic moves the call to other eligible capacity for the same model, which is why cross-provider failover is a property of the ID rather than something you build.
They are a third option, not a replacement. Bring-your-own-key and your own OpenAI-compatible endpoint work exactly as before, and any of the three can serve as an agent's primary or fallback model:
| Connic-managed | Bring your own key | Your own endpoint | |
|---|---|---|---|
| What you write | connic/glm-5.2 | anthropic/claude-sonnet-4-6 | vllm/mistral-7b |
| Setup | None, on by default | Add provider credentials to the Project | Pick a prefix, point it at a base URL |
| Who bills the tokens | Connic, from Project credit | Your provider, on your account | Nobody, you run the server |
| Where inference runs | EU only | Wherever your provider runs it | Wherever you host it |
| Rate limits | Managed by Connic across providers | Your provider contract | Your own hardware |
Works as fallback_model | Yes | Yes | Yes |
One Project can mix all three, and mixing them is the point. A managed primary with a BYOK fallback is a normal configuration, and so is the reverse:
version: "1.0"
name: refund-agent
type: llm
description: Reviews refund requests and drafts a decision
system_prompt: |
Review the refund request and draft a decision.
model: connic/glm-5.2
fallback_model: anthropic/claude-sonnet-4-6
temperature: 0.3
reasoning_effort: highWhich models are in the catalog?
As of 30 July 2026 the catalog carries 30 models from nine creators: Anthropic, Google, Meta, MiniMax, Mistral, Moonshot AI, OpenAI, Qwen, and Z.ai. Open-weight models sit beside hosted proprietary ones, and every entry names its license, so you can tell at a glance whether the model you are about to depend on is one you could also run yourself.
The spread is deliberate. Twenty-two entries accept image input, three accept audio, and twenty-two do reasoning, seventeen of those with an effort level you set. That means a small vision model can triage scanned invoices while a frontier reasoner handles the one decision that matters, both in the same Project, both named in YAML. Six entries, to show the range:
| Model ID | Creator and license | Context | Inputs | Reasoning effort |
|---|---|---|---|---|
| connic/mistral-small-3.2-24b-instruct-2506 | Mistral, Apache-2.0 | 128k | text, image | not supported |
| connic/qwen3.6-35b-a3b | Qwen, Apache-2.0 | 256k | text, image | none, low, medium, high |
| connic/glm-5.2 | Z.ai, MIT | 256k | text | none, high, max |
| connic/gemini-3.5-flash | Google, provider terms | 1M | text, image, audio | low, medium, high |
| connic/claude-sonnet-5 | Anthropic, provider terms | 1M | text, image | low, medium, high |
| connic/gpt-5.6-sol | OpenAI, provider terms | 1M | text, image | low, medium, high |
Browse the full model catalog for every ID, its capabilities and limits, its per-token price, and the date the catalog was last updated. It is searchable, filterable by creator, and sortable by price or context.
No key, no provider account, no region flag. Name a connic/* model in agent YAML and deploy.
Start buildingEU inference, not an EU option
This is the part we care most about, and it is the constraint every provider behind the catalog is held to. Adding a provider does not widen the boundary. There is no region flag to remember and no worldwide fallback hiding behind the model ID. Every connic/* request goes only to EU inference capacity. If that boundary cannot be held for a model, the model is removed from the catalog or the call fails closed. It does not quietly route somewhere else.
We could have left those labels out. We put them in because inference location and provider origin are two different questions, and a catalog that answers only the first one is a catalog you cannot take to a procurement review.
The split is where it gets interesting. Twenty-one of the 30 entries carry no non-EU-native-provider label at all, and ten of those ship under an open or source-available license: Apache-2.0, MIT, Modified MIT, Llama 3.3 Community, and the Kimi K3 License. That is enough to build a whole agent fleet on EU-native capacity and open weights, and still reach for a labeled frontier model on the one task that needs it. If keeping a US cloud out of the path is a requirement rather than a preference, start with how to run agents in the EU without US hyperscalers.
One limit, stated plainly: the connic/* guarantee covers the model call. A Project is fully EU-resident when its deployment region and every component you configure, including BYOK providers, tools, guardrails, judges, and external data destinations, are EU-resident as well. For the longer version, read how data residency works across an agent platform.
An ID that means what it says
A managed model ID that silently starts pointing somewhere new would be worse than shipping no managed models at all. Your tests, your judge scores, and your cost baselines would all stop meaning anything, and you would have no way of knowing when it happened. So we made the commitment explicit: every connic/* ID refers to the model named beside it in the catalog and keeps referring to it. When a model is retired, we announce the change before the ID goes away. A deploy never swaps out the model you tested.
Capacity behind the ID is a different story, and that one works in your favor. Rate limits, timeouts, and provider outages are ordinary events once agents run around the clock, so we handle them at the model call instead of leaving them in your application code:
fallback_model takes over, managed or BYOK. Runs that switched are tagged, so filtering the run list on context.fallback_model_used shows exactly how often a provider let you down last week.Two things that come with a managed ID
Fast IDs, when latency is the constraint
Seven models ship a companion ID with a -fast suffix: the same model through a latency-optimized execution path, at the same price. Two more, both Kimi models, are offered only on that path, so -fast is simply part of their ID. The suffix is the promise: if an ID does not carry it, the model is not served this way.
Two caveats, and we would rather you read them here than discover them in production.
First, the trade-off that makes it fast. A Fast ID can be served by a quantized deployment of the model, which is part of how the latency comes down and why its outputs may differ from the standard ID on the same prompt. Quantization is a quality trade-off, not a free win, so treat a switch as a model change: re-run the agent's tests, and keep accuracy-critical steps on the standard ID until you have evidence the Fast one holds up. The A/B comparison is the cheapest way to get that evidence, since it scores both sides on live traffic.
Second, a Fast ID can be narrower than its standard twin in three ways: fewer reasoning levels, a smaller context window, or fewer input types. connic/glm-5.2-fast accepts only high where the standard ID also takes none and max, and connic/qwen3.5-397b-a17b-fast takes text only where the standard ID also reads images. Three of the seven companions match their standard twin exactly, and the info icon beside every Fast ID states any differences.
Reasoning effort that survives a model swap
Every provider names its reasoning control something different and scales it differently. In Connic it is one field, reasoning_effort, and Connic translates the level you set into whatever the model underneath expects. Every managed model's accepted values sit in the catalog, and auto hands the decision back to the model.
The payoff lands at swap time. Changing the model line does not mean rewriting a provider-specific parameter beside it, and captured reasoning still appears in the run trace when the model returns it, whichever model that is. See how runs and traces work.
How is managed usage billed?
Managed tokens draw on Project credit, the same balance that pays for runs, compute, storage, and retrieval. One balance, one currency, one number to quote when someone asks what an agent costs to run. Input, output, thinking, and cached input are priced independently per model, and the catalog carries the current rates beside each ID.
Switch models on evidence, not on a benchmark chart
A cheaper model in the catalog is a hypothesis, not a saving. The three tools that turn one into the other were already in Connic, and managed models plug into all of them:
Spend alerts and hard limits apply either way, scoped globally, per environment, or per agent, daily or monthly. Switch on anomaly detection and a run that costs far more than that agent's 30-day average raises an alert on its own. See how to A/B test an agent change for the full workflow, or read the usage and budget docs.
BYOK is not going anywhere
We built managed models to remove a barrier, not to move your traffic. If your model spend already sits under a negotiated provider contract, keep it there. If you run a fine-tune on your own hardware, point a custom prefix at it and reach it over a Bridge with no inbound ports. Managed and BYOK are equal options in the same YAML field, and every observability, testing, and budgeting feature treats them the same way.
One more limit worth naming: connic/* models are part of the deployed Connic runtime, not a public pass-through model API. They exist to run your agents.
How do I start using Connic Models?
- 1.Browse the model catalog and pick an exact ID, filtering by creator and sorting by price
- 2.Set it as
modelin an agent file, or in a_defaults.yamlto change every agent in that directory and below - 3.Deploy. No key, no provider account, no region flag
- 4.Before production traffic, enable Auto-refill and set a spend limit on the agent
New to Connic? The quickstart deploys your first agent, and it no longer asks you for somebody else's API key first. For the field-by-field reference, read the models and providers docs, or see how model choice works end to end.