# CloudSigma AI Mission Control

> Public, read-only product and developer information.

## Pages
- [Enterprise AI Control Plane](https://taas.1stack.net/): Bring model access, usage visibility and policy-based routing together with CloudSigma AI Mission Control.

### The Enterprise AI Control Plane.
Manage who can use AI, monitor spending and choose from supported models through one platform — without forcing every team into the same provider or deployment model.
#### AI Governance
Organise access across organisations, departments and projects. Apply model and region policies at the credential boundary.
- Role- and project-aware access
- Model, supplier and region controls
- Enterprise SSO — discuss identity-provider rollout with our team
#### AI FinOps
Connect token activity to accountable teams and nominated billing relationships, with usable cost and usage evidence.
- Usage and cost visibility
- Department, project and key attribution
- Hard-budget policies — confirm enforcement scope and rollout during your briefing
#### AI Sovereignty
Choose supported geographic regions and keep deployment options open as governance requirements evolve.
- EU and supported-country routing
- Credential-level location restrictions
- Customer-owned GPU integration through assisted onboarding
#### AI Optimisation
Use explicit model selection or opt in to chat routing informed by model fit, cost and available operational telemetry.
- Policy-aware route selection
- Supplier health and availability signals
- Inspectable choices rather than self-learning authority
#### Universal AI Access
Connect applications to supported models through documented compatible, native and specialist endpoints.
- OpenAI- and Anthropic-compatible APIs
- Specialist media and embedding endpoints
- Bring your own supplier API key with documented limits
#### AI Trust is the foundation
Identity, policy, observability and evidence sit beneath every pillar. Controls are scoped to the route, region and integration you select.
- Least-privilege API keys
- Auditable request and usage records
- Clear supported, assisted and planned boundaries
- [AI control plane platform](https://taas.1stack.net/platform): Explore governance, FinOps, sovereignty, optimisation and universal model access in one enterprise AI control plane.

### One control plane. Five connected disciplines.
AI adoption becomes manageable when access, economics, location and routing are governed together. Mission Control gives platform, finance and application teams a shared operating layer.
#### Govern AI access
Create organisation, department and project boundaries, then issue keys with deliberate model, supplier and region permissions.
- Separate workloads by accountable owner
- Central administrators with delegated operation
- Discuss enterprise SSO rollout and identity-provider requirements
#### Make AI economics visible
Relate usage to models, keys and teams, with pricing and nominated billing available for operational review.
- Current usage and cost breakdowns
- Project and department reporting
- Hard-budget requirements assessed against each enforcement path
#### Control location and infrastructure
Choose supported EU or country policies and enforce allowed regions on credentials. Available regions depend on the selected model.
- Explicit regional policy
- Fail closed when an allowed route is unavailable
- Assisted onboarding for customer-owned GPU capacity
#### Optimise without surrendering policy
Applications can name a model directly or opt in to chat autorouting. Eligibility remains bounded by configured policy and available route telemetry.
- Model-fit and cost inputs
- Availability-aware routing
- Explicit selection policies and inspectable routing metadata
#### Use one governed access layer
Adopt compatible APIs where they fit and native specialist endpoints where modalities require them.
- Documented endpoint coverage
- Central key lifecycle
- Use your OpenAI key with the OpenAI corporate API; confirm supported models during evaluation
- [Architecture](https://taas.1stack.net/architecture): See the request lifecycle, policy checkpoints and assisted customer-GPU path behind CloudSigma AI Mission Control.

### Policy first, then route.
Mission Control checks identity and key policy before processing a request. OpenAI and Anthropic models are available through one CloudSigma service with a consistent model catalogue.
#### 1. Authenticate and scope
A request arrives through a documented endpoint. The API key establishes its organisation, project and allowed model, supplier and region scope.
- Credential validation
- Organisation and project context
- Endpoint-specific input validation
#### 2. Apply policy and select
Direct model requests retain the caller's choice. Opt-in chat autorouting considers eligible models using configured constraints and available fit, cost and health signals.
- Policy eligibility before routing
- Regional and supplier restrictions retained
- Requests remain within configured access policies
#### 3. Execute and observe
CloudSigma processes the selected model request and records usage for operational and billing records.
- Current: unified access to supported models
- Assisted: customer-owned GPU onboarding and integration
- Response and usage records available in the platform
- [Partners](https://taas.1stack.net/partners): Deliver governed AI access with reseller controls, branding and assisted infrastructure integration opportunities.

### Build governed AI services on a shared control plane.
Cloud and service providers can package model access for their markets while retaining operational oversight and a clear relationship with each customer organisation.
#### Operate a branded service
Use reseller branding and organisation management to present a coherent customer experience.
- Branding for supported reseller surfaces
- Organisation and model controls
- Portfolio and financial reporting
#### Shape the catalogue
Define which supported models are appropriate for your customers using the CloudSigma catalogue.
- Reseller model controls
- Customer and organisation boundaries
- Published pricing and usage context
#### Bring infrastructure
Explore customer- or partner-owned GPU capacity through an assisted onboarding process with explicit integration and operational responsibilities.
- Manual technical assessment
- Routing and observability integration
- Assisted setup with agreed operational ownership
- [Resources](https://taas.1stack.net/resources): Practical guides for evaluating enterprise AI governance, economics, sovereignty and integration.

### Plan an AI control plane around real workloads.
Use these public resources to frame requirements, inspect supported interfaces and prepare a focused technical evaluation.
#### Evaluation checklist
Start with workload, data, identity and spending boundaries before comparing model output.
- List applications and accountable owners
- Define allowed providers and locations
- Separate current controls from rollout requirements
#### Developer paths
Review compatible APIs, the guide and agent integration notes before choosing a migration path.
- API documentation
- Quick-start guide
- Agent and discovery guidance
#### Trust review
Map your required controls to available platform evidence and identify where contractual or assisted review is needed.
- Security practices
- Control scope
- Certification and evidence status
- [Book an AI briefing](https://taas.1stack.net/contact): Book a focused CloudSigma AI Mission Control briefing for your workload, controls and deployment requirements.

### Put your AI estate on the map.
In a focused briefing, we will connect your workloads, model choices, spending controls and location requirements to supported and assisted Mission Control paths.
#### What we will cover
Bring a current workload or an evaluation plan. We will keep the conversation specific and identify follow-up evidence where needed.
- Workloads and supported model options
- Access, spending and hard-budget requirements
- Location, customer-owned GPU and integration scope
- Evaluation and rollout next steps
- [Agents and MCP](https://taas.1stack.net/agents): Discover public AI Mission Control content, models and pricing through read-only MCP and HTTP interfaces.

### Public discovery. Clear boundaries.
Use standard API clients for inference and read-only public discovery resources for product and catalogue context. Customer data, credentials and inference are not exposed through discovery tools.
#### Choose the inference interface
Use a documented compatible or specialist endpoint based on the workload modality.
- Explicit model IDs for deterministic selection
- Opt-in chat autorouting where appropriate
- Project-scoped credentials and restrictions
#### Discover public capabilities
Agent-facing discovery can retrieve approved product pages, public model fields and pricing without crossing into customer operations.
- Streamable HTTP MCP: https://taas.cloudsigma.com/mcp
- Public discovery OpenAPI: /api/site/openapi.json
- Six read-only tools; no inference or customer-data access
- Briefing handoff without lead submission or booking
#### Keep tools bounded
Treat model calls and operational actions as separate capabilities with their own authentication and approval model.
- No credentials in prompts
- Validate tool inputs and outputs
- Log accountable workload context
- [Developers](https://taas.1stack.net/developers): Integrate supported models through compatible and specialist APIs with governed keys, routing and usage evidence.

### One governed entry point for diverse AI workloads.
Start with a familiar API shape, choose the interface that matches your workload, and use Mission Control policies to constrain models, suppliers and regions without embedding those decisions throughout application code. This public page explains the path; setup happens after sign-in.
#### Choose your interface
Use the endpoint family that matches the client you already run. The guide and API reference provide the exact request shapes after you sign in.
- OpenAI-compatible /v1 for standard chat clients
- Anthropic-compatible /v1/messages for Claude-compatible clients
- Native /v1/codex Responses for Codex CLI and Desktop
- Specialist endpoints for supported modalities
#### Make a first request
After sign-in, create a scoped key, choose a supported model and run the smallest useful request. The onboarding guide walks through the steps and the success signal.
- Start with /v1/models or the published model catalogue
- Keep a redacted key placeholder in local configuration
- Inspect status, request ID and usage evidence
#### Express routing intent
Name a model directly or opt in to supported chat autorouting. Credential controls remain authoritative over eligible choices.
- Model and supplier allowlists
- Region restrictions
- Request metadata for accountable workloads
#### Operate with evidence
Use response metadata, request logs and usage reporting to understand what ran and what it cost. Keep the request ID with your application run when troubleshooting or reviewing spend.
- Usage attribution
- Route and status visibility
- Request IDs and trace context
- Graceful handling when no compliant route is available
#### When usage grows
Move the same workload from a personal test to a governed team service by putting access, budget and supplier decisions in the control plane.
- Centralised organisation and project access
- Per-project and per-key budgets
- BYOK with supplier and region policy
- Traceability for requests, usage and routing
- [Agent integrations](https://taas.1stack.net/integrations): Connect Claude Code, OpenClaw, Codex and other agent harnesses to CloudSigma AI Mission Control through familiar API interfaces.

### Keep your harness. Add a control plane.
Start with the client you already use, point it at a governed OpenAI- or Anthropic-compatible endpoint, and keep the path to budgets, policy and traceability open as usage grows. These public recipes explain the workflow; actual key creation and configuration happen after sign-in.
#### Status and verification
Treat each recipe as a versioned compatibility record. A named client is ready for a stronger claim only after a clean configuration, one successful request and a recorded completion receipt.
- Verified: current client/version completed the smoke test
- Validation: the connection path is plausible and a bounded test is pending
- Exploratory: the product exposes no supported inference endpoint or needs an adapter
- Record transport, client version and last-verified date
#### Verified quick starts
The Anthropic-compatible path and OpenClaw have documented connection paths today. Each recipe is designed to get from configuration to a successful request in minutes; named client claims remain versioned evidence work.
- Anthropic-compatible clients, including Claude Code: ANTHROPIC_BASE_URL with a scoped token and auto or auto:orchestrator
- OpenClaw: OpenAI-compatible provider at https://taas.cloudsigma.com/v1 with taas/auto
- MCP discovery: read-only public catalogue and pricing context at https://taas.cloudsigma.com/mcp
#### OpenAI-compatible clients
Cline, Roo Code, Aider and similar tools can use the documented OpenAI-compatible path where their current version exposes a custom base URL. Codex-native clients are tracked separately because their response contract differs.
- Use /v1 and a scoped API key
- Run a /v1/models or small completion smoke test
- Record the client version and last-verified date in the compatibility matrix
#### Codex, desktop, Hermes and Grok Bot
Codex CLI and Desktop already have a verified current-version TaaS reference using the native Responses endpoint and file-backed provider auth. Hermes is a named custom-provider validation track; Grok Bot (stable Cursor app 0.75.5) is a separate xAI app product with no documented customer-selectable model endpoint. Its Enterprise beta Inference Hooks are a possible policy integration, not an inference provider route.
- Codex CLI and Desktop: use the shared $CODEX_HOME/config.toml provider pattern at /v1/codex and retain a versioned completion receipt
- Hermes: validate NousResearch/hermes-agent v0.22.5 with a named custom provider at the OpenAI-compatible /v1 path
- Grok Bot: do not imply compatibility with the separate xAI Grok API; evaluate signed Inference Hooks separately if an enterprise policy use case emerges
#### The team path
A personal harness connection can become a governed team workload without replacing the application. Move policy to the control plane as adoption grows.
- Project and key budgets
- Centralised access and scoped credentials
- BYOK and supplier or region policy
- Request logs, usage attribution and route evidence
- [Security](https://taas.1stack.net/security): Understand the security boundaries used to protect access to CloudSigma AI Mission Control.

### Security begins with scoped access.
Mission Control layers credential controls, tenant boundaries and operational evidence around model access. Responsibilities are documented for the selected service and any customer infrastructure integration.
#### Identity and access
Keys are scoped to accountable platform entities and can be constrained by model, supplier and region.
- Role-aware administration
- Credential lifecycle controls
- Enterprise SSO requirements reviewed during rollout planning
#### Data and routing boundaries
Region policies govern where supported models can be used. Review inference, logging and storage requirements for your workload.
- Supported EU and country routing
- Fail-closed eligibility when configured
- Service-specific data-flow review
#### Operational assurance
Logging and usage records support review without publishing sensitive implementation or vulnerability details.
- Auditable administrative and request context
- Security disclosures handled privately
- Contractual documents remain the authoritative legal terms
- [AI controls](https://taas.1stack.net/controls): Map AI access, spending and routing requirements to current and assisted Mission Control controls.

### Turn policy into enforceable boundaries.
Controls are most useful when their enforcement point and limitations are clear. Mission Control applies current key and routing controls while qualifying capabilities that require rollout assessment.
#### Current platform controls
Use roles, organisations, departments, projects and API-key restrictions to establish accountable access boundaries.
- Model, supplier and region restrictions
- Project and payer context
- Usage, pricing and reporting views
#### Commercial capability areas
Plan enterprise identity, BYOK and hard-budget policies with our team, confirming supported paths and rollout requirements during evaluation.
- Enterprise SSO — identity-provider rollout discussed with our team
- Bring your own supplier API key
- Hard-budget policies — enforcement scope and rollout confirmed during briefing
#### Assisted infrastructure control
Customer-owned GPUs can be integrated through a manual assisted service rather than a self-service enrolment flow.
- Architecture and connectivity assessment
- Model-serving and route integration
- Agreed operational ownership
- [Certifications and assurance](https://taas.1stack.net/certifications): Review CloudSigma AI Mission Control assurance evidence without unsupported blanket compliance claims.

### Evidence over badges.
A control plane touches several responsibility domains. We map relevant company, platform, infrastructure and upstream evidence to the service being evaluated.
#### Scope matters
A certification held by one organisation or facility does not automatically certify every model, provider or customer workload.
- Identify the legal and technical service boundary
- Separate platform, datacentre and model-provider scope
- Confirm current evidence during due diligence
#### Review path
Use public security and legal materials for initial review, then request applicable evidence under the appropriate disclosure process.
- Security and subprocessors information
- Data processing and service terms
- Private evidence review where applicable
#### No blanket claim
Mission Control does not present a universal compliance badge. Customers remain responsible for assessing their use case and configuration.
- Workload-specific assessment
- Region and provider selection
- Documented shared responsibilities
- [Model pricing](https://taas.1stack.net/pricing): View current public model pricing and understand usage-based CloudSigma AI Mission Control economics.

### Pay for the model usage you select.
The live pricing view remains the source for current public rates. Use workload attribution and policy controls to understand spend; enterprise commercial terms are discussed directly.
#### Live public rates
Published model and schedule data is rendered from the public catalogue with current supported rate units.
- Model-specific units
- Current schedule context where available
- Outcomes depend on workload and selected model
- [Public model catalogue](https://taas.1stack.net/models-public): Explore the current public model catalogue available through CloudSigma AI Mission Control.

### Choose from the supported catalogue.
The live catalogue remains the authority for supported model IDs, modalities, locations and public availability. If the catalogue is temporarily unavailable, contact our team to discuss your requirements.
#### One catalogue
Applications, pricing pages and public discovery should consume the same allowlisted source.
- Current supported model IDs
- Public modality and location fields
- Explicit availability state
- [API documentation](https://taas.1stack.net/api-docs): Reference CloudSigma AI Mission Control compatible and specialist model API endpoints.

### Integrate against documented interfaces.
Existing API documentation remains the detailed source for request schemas, authentication and compatibility. Check endpoint-specific behaviour rather than assuming every upstream feature is identical.
#### Base URLs and authentication
Use the OpenAI-compatible base at https://taas.cloudsigma.com/v1 for standard SDKs, the Anthropic-compatible POST /v1/messages path for Claude clients, and https://taas.cloudsigma.com/v1/codex for Codex-native Responses semantics.
- Send a scoped API key as Authorization: Bearer or the client-specific x-api-key header
- Use an identifier returned by GET /v1/models rather than assuming a model name
- Keep keys in a local secret manager; public discovery never accepts or returns credentials
#### Endpoint coverage
The reference covers model listing, chat completions, Anthropic Messages, Codex-native Responses, embeddings, reranking, audio transcription, text-to-speech and an unauthenticated health check. Streaming and tool payloads follow the endpoint-specific contract.
- GET /v1/models
- POST /v1/chat/completions and POST /v1/messages
- POST /v1/codex/responses, /v1/embeddings and /v1/rerank
- POST /v1/audio/transcriptions and /v1/audio/speech
- GET /health
#### Compatibility with boundaries
Compatible interfaces reduce migration effort while Mission Control adds policy, routing and usage semantics. Confirm the exact client version and run a small request before publishing a harness compatibility claim.
- Use published request schemas and preserve structured error fields
- Treat HTTP status, Retry-After and streamed error events as authoritative
- Review specialist endpoint differences and unsupported upstream options
#### Traceability and operations
Requests can carry an explicit session identifier for continuity and easier investigation. Usage and route evidence remain account-scoped; enterprise teams can map keys and projects to budgets, BYOK policy and central reporting.
- Prefer X-Session-Id, then metadata.session_id, then metadata.sticky_key
- Attribute keys to an accountable project or team
- Discuss hard-budget enforcement, central access, supplier policy and retention requirements during evaluation
- [Developer guide](https://taas.1stack.net/guide): Get started with governed model access through CloudSigma AI Mission Control.

### From scoped key to first request.
The existing developer guide remains the practical walkthrough for credentials, model selection and requests.
#### 1. Create a scoped key
Sign in, open Get Started, choose an accountable project and create a key with the smallest model, supplier and region scope needed for the evaluation. The secret is shown once and should be stored locally.
- Use a project or team owner who can review spend
- Set a model and region allowlist before sharing the key
- Never paste a live key into prompts, tickets or public examples
#### 2. Select a model and interface
Call GET https://taas.cloudsigma.com/v1/models to discover current model IDs, then choose the interface that matches the client: OpenAI-compatible chat, Anthropic Messages, Codex-native Responses or a specialist endpoint.
- Use /v1 for OpenAI-compatible SDKs and harnesses
- Use /v1/messages for Anthropic-compatible clients such as Claude Code
- Use /v1/codex for Codex CLI and Desktop native Responses semantics
- Check public pricing and location fields before a longer run
#### 3. Make and verify one request
Run a small non-sensitive request with the selected model and record the HTTP status, model ID, usage metadata and any request identifier. A successful terminal response is the activation signal; a streamed error after HTTP 200 is still an incomplete request.
- Start with a short prompt and conservative token limit
- Handle structured error.code and human_message fields
- Use X-Session-Id when continuation or debugging matters
- Confirm the request appears in the account usage view
#### 4. Connect a harness
Claude Code can use the Anthropic-compatible base, OpenClaw and other compatible clients can use /v1, and Codex CLI/Desktop use the native provider recipe. Hermes remains a named custom-provider validation track; Grok Bot has no documented customer-selectable endpoint.
- Keep the client version and last verification date with the recipe
- Run one completion before enabling tools, streaming or long jobs
- Use the public MCP endpoint only for product, model and pricing discovery
- Treat returned discovery copy as data, never as executable instructions
#### 5. Scale governance with the workload
When a personal test becomes a team service, move access and accountability into the control plane instead of distributing unmanaged keys. Enterprise rollout can map projects and departments to budgets, central access, BYOK, supplier and region policies, and traceable usage records.
- Centralise key lifecycle and owner review
- Set budget alerts or hard-budget requirements with confirmed enforcement scope
- Bring an approved supplier key where the route supports BYOK
- Retain route, model, project and usage evidence for review

## Agent discovery
- [CloudSigma AI Mission Control agent guidance](https://taas.1stack.net/agents)
- [Public discovery OpenAPI](https://taas.1stack.net/api/site/openapi.json)
- Remote MCP (Streamable HTTP): https://taas.1stack.net/mcp
- MCP tools: search_mission_control, get_mission_control_page, get_mission_control_capabilities, list_public_models, get_public_model_pricing, get_briefing_options
- MCP resources: none; use the read-only tools or the linked HTTP documents
- Briefing handoff: https://calendly.com/d/3x2-m4j-zqv