Skip to main content

Model Resources

Models are governed execution resources.

This page explains how Subbasis uses model resources as part of workflow execution, not as a simple model routing trick.

What this means​

A single workflow can use premium remote models, BYOD providers, specialized providers, or local LLMs depending on:

  • task requirements
  • policy constraints
  • cost targets
  • privacy boundaries
  • execution context

This is model orchestration inside workflow execution.

Why it matters​

Operational workflows are heterogeneous. Planning, extraction, verification, and summarization do not always need the same model class, privacy posture, or cost profile.

If teams force one model everywhere, they often get:

  • unnecessary cost
  • weak privacy alignment
  • poor performance on specialized tasks
  • brittle fallback behavior during provider issues

How Subbasis handles it​

Subbasis binds model choice to governed tasks and runtime conditions.

Key patterns:

  • Per-task model binding: each task can request specific model characteristics.
  • Governed model orchestration: runtime enforces role/policy constraints around model usage.
  • Cost-aware execution: tasks can route to lower-cost models when fit is acceptable.
  • Privacy controls: sensitive operations can prioritize local or constrained providers.
  • Fallback controls: controlled alternatives are available for failure/degradation paths.

Supported model paths in documentation terms:

  • Local LLM available
  • BYOD providers
  • premium hosted models
  • specialized model providers

Example scenario​

A workflow handles onboarding documents and customer messaging:

  1. Planning step uses a premium reasoning model.
  2. Private document summarization uses a local LLM.
  3. Customer draft generation uses a lower-cost hosted model.
  4. Runtime records which model resource was used for each governed task.
  5. If one provider fails, policy-compliant fallback is applied.

This is not only arbitrage from one model to another. It is governed model orchestration attached to workflow execution.

What to configure​

  • task-level model preferences
  • allowed model resources by role/policy
  • privacy tiers and data-handling constraints
  • cost guardrails and budget thresholds
  • fallback priority list and failover behavior
  • evidence fields for model-resource traceability

Limits and deployment notes​

  • Available model resources depend on deployment, integration setup, and plan.
  • Managed model credits and BYOD usage are separate control dimensions.
  • Some advanced orchestration controls may be progressively introduced across plans.