NeuroCluster
Let's talk
Platform / Models

Modelchoiceisapolicydecision,notanarchitecturedecision.

NeuroCluster is model-independent by design. Workloads declare what they need; policy decides which model serves them. That is what keeps replacing a provider a configuration change rather than a rewrite.

Talk to an architectResearch in Labs
Model routing
Model choice is a policy decision, evaluated per request.
Model supplyWhat is available to the organisation
Commercial APIsOpen-weight modelsPrivate modelsDomain modelsFirst-party models

Model control

The routing decision, evaluated against policy rather than hard-coded in the application.

CapabilityData sensitivityJurisdictionLatencyCostAvailabilityFallback
Enterprise workloadThe task that needed a model
The workload declares what it needs. It does not name a vendor, which is what makes replacing one a configuration change rather than a rewrite.

Whyindependenceisacontrolrequirement

Model capability is moving faster than any enterprise procurement cycle. A system designed around one provider's API surface is a system that will be rebuilt, and the rebuild will land at the least convenient moment.

There is a governance argument as well. Different classes of work carry different constraints: some data must never leave a specific jurisdiction, some tasks need a model that can be inspected, some decisions need a model whose behaviour has been evaluated against a regression suite. A single default model cannot satisfy all of those at once, and hard-coding several of them into applications spreads the constraint across code nobody audits.

So the routing decision is lifted out of the application and expressed as policy.

Whatcanserveaworkload

Model supply is treated as a registry. Anything registered can be selected by policy; nothing is selected by default.

  • Commercial APIs

    Frontier hosted models, where their capability justifies the data-handling terms for the class of work in question.

  • Open-weight models

    Models you host yourself, in your own tenancy or on your own hardware, with no external inference dependency.

  • Private models

    Fine-tunes and adapters trained on your data, kept inside your boundary and versioned like any other artefact.

  • Domain models

    Task-specific models — forecasting, classification, extraction, vision — which frequently outperform a general model on the narrow job.

  • First-party models

    Models developed in NeuroCluster Labs. Available as options where they are the right tool, never as a requirement.

  • Embedding and reranking models

    Retrieval quality is a model choice too, and it is governed by the same jurisdiction and sensitivity rules.

Whattheroutingpolicyweighs

Every criterion below can be a hard constraint or a preference. Hard constraints are checked before capability is considered.

  • Capability

    Whether the model can do the task to the standard the evaluation suite requires.

  • Data sensitivity

    The classification of the data in the request, which can rule out external inference entirely.

  • Jurisdiction

    Where inference may physically occur, and which provider terms apply there.

  • Latency

    Whether an interactive workflow can tolerate the response time.

  • Cost

    Cost per unit of work, evaluated against the workload's budget rather than in the abstract.

  • Availability

    Current provider health, with automatic fallback to a permitted alternative.

  • Fallback path

    The ordered set of models that may serve this work if the first choice cannot.

  • Retention terms

    What the provider may keep, log or train on — a hard constraint for most regulated work.

Model support is a technical capability, not a commercial endorsement. NeuroCluster does not imply partnership with any model provider by virtue of being able to route work to it.

Questions

Which models do you recommend?
It depends entirely on the work, the data classification and the deployment posture, and the honest answer changes as capability moves. The recommendation we hold to is architectural: do not let the choice become structural.
Can different agents use different models?
Yes, and in practice they should. Model policy is set per agent and per class of work, so a summarisation step and a decision-support step need not share a model.
What happens when a model is upgraded?
It is treated as a change: the evaluation suite runs, the results are recorded, and promotion is a lifecycle gate. Silent upgrades are the main reason production behaviour drifts without anyone shipping anything.
Do you train on our data?
No. Customer data is not used to train shared models. Where you want a private fine-tune, that is an explicit, contracted piece of work whose output stays inside your boundary.

Continue

Bring us one operational problem.

You do not need a finished brief. Bring the problem — we will work out the next step together.

Or book a call with the team