Inference routing

Send this workspace’s inference to an account you control — Bedrock, Vertex, Foundry, Azure OpenAI, or any gateway of your own — instead of the vendor’s endpoint. Your code already runs on your hardware; this is the other half, and it is the reason a workspace with a model-governance policy can use Sparkyard at all.

Only whoever installed Sparkyard in the workspace can change it: routing decides where this workspace’s code is sent.

Commands

Command	What it does
/sparkyard routing	Where each vendor is routed right now.
/sparkyard routing <vendor> <target>	Names the values to seal, then routes there.
/sparkyard routing <vendor> default	Back to the vendor’s own endpoint, from the next turn.
/sparkyard routing test	How to confirm it took effect.

Where each agent can go

Agent	Target	You supply
claude	bedrock	CLAUDE_CODE_USE_BEDROCK, AWS_REGION
claude	vertex	CLAUDE_CODE_USE_VERTEX, ANTHROPIC_VERTEX_PROJECT_ID, CLOUD_ML_REGION
claude	foundry	ANTHROPIC_BASE_URL
claude	gateway	ANTHROPIC_BASE_URL — anything speaking the Anthropic API
chatgpt	azure-openai	AZURE_OPENAI_API_KEY, AZURE_OPENAI_BASE_URL
chatgpt	gateway	OPENAI_BASE_URL, OPENAI_API_KEY
gemini	vertex	GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION
copilot	—	GitHub operates Copilot. There is no customer-owned endpoint to point at.

Bedrock and Vertex authenticate the cloud’s own way — an AWS credential set, or Google application default credentials — rather than with a vendor API key.

Copilot is refused rather than quietly accepted. If your requirement is inference inside your own cloud, that is a thing to learn while you are configuring it, not during a security review.

Credentials go through the private form, never a message

/sparkyard routing tells you which values a target needs; you seal each one with /sparkyard secret NAME, one at a time. These are more dangerous than an inference key — an AWS credential set may reach far more than inference, depending how it was scoped. Give it the narrowest scope that can run inference and nothing else.

What changes, and what you lose

Some targets do not carry every server-side tool. Sparkyard tells you which when you configure one, and the same warning appears in /sparkyard routing:

Target	Not available
claude → bedrock	web search, web fetch, code execution
claude → vertex	web fetch, code execution

A desk whose standing instruction assumes one of these will quietly do less, so it is worth re-reading your desk prompts after moving.

Model ids and pricing follow the operator, not Anthropic — on Bedrock, ids carry an anthropic. prefix and the bill is AWS’s.

Azure’s base URL needs the /openai/v1 path

Azure serves the v1 API there. Without it every request 404s in a way that reads exactly like a bad key.

Confirming it took effect

A half-configuration is refused rather than silently ignored — a workspace that believes it is routed and is not would be the worst outcome here, so incomplete values do not apply at all.

To confirm the real answer, run any turn and check /sparkyard status. Its Inference line reports where turns actually went, not where they were configured to go — the only evidence worth trusting.

If a turn reaches the vendor’s own endpoint while routing says otherwise, Sparkyard says so outright: the setting did not take effect, and that turn was not billed to your own account. It is worth checking once after you configure a target, because a workspace that believes it is routed and is not has been telling its security team something untrue.

Routing takes effect from the next turn, not the next VM restart.