Dati e provider

#The principle

The customer chooses, the platform discloses. The templates run on Claude and Gemini by default — some plan with Claude and do the work with Gemini, others use Gemini throughout — and on a paid plan an agent can be set to a different provider/model from the catalogue, including OpenAI, open-weights and Chinese-made models (trial runs use the platform's default model). In production every model call goes through OpenRouter, and no EU-hosted model is connected yet. Every run shows exactly which provider processed which step, where that provider hosts inference, and what it cost.

#The model catalogue

GET /v1/models lists every selectable model, already filtered by the calling workspace's data-region policy:

curl "https://api.agentflowbind.com/v1/models" -H "Authorization: Bearer afb_live_xxxxxxxxxxxx"

{
  "models": [
    {
      "id": "claude-sonnet-5",
      "displayName": "Claude Sonnet 5",
      "maker": "Anthropic",
      "host": "Anthropic",
      "hostRegion": "us",
      "tier": "A",
      "dataPolicy": { "retentionDays": 30, "trainingUse": false, "dpaAvailable": true }
    }
  ],
  "allowedDataRegions": "eu_us"
}

Each catalogue entry carries: maker (who made the underlying model), host (who actually operates the API you call), hostRegion (us / eu / cn / sg / global — where inference physically runs), and a dataPolicy (retentionDays, trainingUse, dpaAvailable). The console's model picker and the Your data FAQ render the same fields under friendlier labels ("Model by", "Hosted by", "Region", "Retention", "Training use", "Contract"). The same underlying open-weights model (e.g. Qwen) can appear more than once with a different host/hostRegion/dataPolicy depending on who's serving it — a maker's own cloud vs. an EU/US host are never conflated into one entry.

#Workspace data policy

A workspace sets Allowed data regions (allowedDataRegions, one of eu, eu_us, or any — a new workspace starts on eu_us), and only an owner or admin can change it. It filters GET /v1/models's results and is checked when an agent is saved: a model outside the policy cannot be chosen, though a template's own default models are exempt. It is not checked again when a run starts, and narrowing it later does not re-check agents already saved. options.model on POST /v1/runs is not a way around it: it does not change the model a run uses, only the estimate (see Runs). The setting decides which models an agent can use, not where your data is stored — that is one database and one data volume on a single server in Germany.

#Per-run disclosure

Every step in GET /v1/runs/:id/steps records the provider, model, and hostRegion actually used for that step — not just what the agent's config allows, but what it did:

{ "phase": "act", "tool": "extract_fields", "provider": "anthropic", "model": "claude-sonnet-5", "hostRegion": "us", "cost": 6 }

#Tiers

Diagnose and Assess stay on a Tier A model by default; a profile can route bulk Act-phase work to a cheaper Tier B/C model. A model's per-phase cost (tokens × provider price × a margin factor that's lower for cheaper tiers) is included in a run's estimate and its final costCredits breakdown.

#Full FAQ

The complete "Where does my data go?" page — providers used, sub-processors, retention, deletion, and whether Chinese-made models can route through China (through OpenRouter a request can reach the maker's own API, so those rows are labelled cn and need the any policy) — lives on Your data. It is maintained by hand against the same catalogue this page describes, not generated from it.