Today we are shipping Connic Models: 30 models from nine creators, unified behind a single set of IDs that every Project can use right now. One line of agent YAML names the model without requiring a provider account, API key, or region flag, and every call stays on EU inference capacity.
We have wanted to make this release since Connic started because it removes the one step in getting an agent live that had nothing to do with building an agent. Developers wrote the YAML and tools, then stopped to open an account with a model provider, add a card, generate a key, paste it into every environment, and determine whether the provided endpoint was 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. Selection happens 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. A connic/* ID provides one published rate, one line of config, one bill, and one documented set of capabilities. No separate provider account or provider credentials are required.
They are a third option, not a replacement. Bring-your-own-key and custom 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 | Custom endpoint | |
|---|---|---|---|
| Configuration value | 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 | The provider, on the associated account | Nobody; the organization runs the server |
| Where inference runs | EU only | Wherever the provider runs it | Wherever the organization hosts it |
| Rate limits | Managed by Connic | The provider contract | The organization's 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: connic/gpt-5.6-terra # or anthropic/claude-sonnet-4-6 with Anthropic BYOK configured
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. This shows whether a model can also run on infrastructure controlled by the organization using it.
The spread is deliberate. Twenty-two entries accept image input, three accept audio, and twenty-two do reasoning, seventeen of those with a configurable effort level. 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 |
The full model catalog lists 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.
Name a connic/* model in agent YAML and deploy without a key, provider account, or region flag.
Start buildingEU inference as a catalog boundary
We care most about this constraint of the catalog. The model ID has no region flag or worldwide fallback. 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.
We could have left those labels out. We included them because inference location and provider origin are two different questions, and a catalog that answers only the first one is a catalog that is unsuitable for 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. Our guide to EU hosting without US hyperscalers covers the requirements when a US cloud must be excluded.
One limit, stated plainly: the connic/* guarantee covers the model call. A Project is fully EU-resident when its deployment region and every configured component, including BYOK providers, tools, guardrails, judges, and external data destinations, are EU-resident as well. Our data residency guide covers the entire agent platform. The EU-hosted model comparison explains provider and deployment options.
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. Tests, judge scores, and cost baselines would all stop meaning anything, with no clear indication of when the change happened. So we made the guarantee 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 tested model.
Rate limits, timeouts, and provider outages are ordinary events once agents run around the clock, so we handle failures at the model call instead of replaying the full run:
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 failed during the previous week.What comes 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 belong here so they do not first surface 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 evidence shows 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 configured level 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. The runs and traces documentation explains the details.
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. Our A/B testing guide describes the full workflow. The usage and budget documentation covers cost controls.
BYOK is not going anywhere
We built managed models to remove a barrier, not to divert existing traffic. Model spend already covered by a negotiated provider contract can stay there. Teams running a fine-tune on their own hardware can 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 agents on Connic.
Getting started with 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 without a key, provider account, or region flag
- 4.Before production traffic, enable Auto-refill and set a spend limit on the agent
For teams new to Connic, the quickstart covers the first agent deployment without requiring another provider's API key. The models and providers documentation explains each configuration field, and the model selection overview describes the available options.