This Schedule describes the current sandbox service and supplements the Terms of Service. It does not announce managed routing, provider resale, or Wildflower-hosted sandbox capacity.
1. Current service
Wildflower provides a shared API and generated SDKs for creating and operating isolated compute environments through supported sandbox providers. The current contract includes provider discovery and persistent sandbox create, list, get, command execution, file read, file write, and delete operations.
Provider behavior is not identical. Images, timeouts, persistence, output, file semantics, sleep behavior, deletion, and other capabilities remain provider-specific and are documented in the compatibility reference.
2. Current routing mode
Customer selects a provider when creating a sandbox. Wildflower returns an opaque, project-scoped sandbox ID whose provider namespace routes later lifecycle calls back to the same provider-native resource. Wildflower does not move an existing sandbox’s processes or filesystem to a different provider.
The TypeScript SDK may try a Customer-supplied ordered list of creation candidates after narrowly defined, proved-safe provider failures. That helper runs in the Customer’s client, is not a general server-side routing service, and does not retry an ambiguous provider outcome.
3. Provider credentials
The current service is bring-your-own-key. Customer can connect one project-scoped provider profile or supply an inline credential override. PostgreSQL-backed profiles encrypt credentials at rest using AES-256-GCM and return only non-secret connection metadata. Inline credentials are forwarded for the operation and are not intentionally persisted.
Wildflower API keys authenticate applications to Wildflower. Provider credentials authorize Wildflower to call a sandbox provider. They are separate credentials with separate scopes and should be rotated independently.
4. Provider relationship
In the current customer-connected mode, Customer selects and contracts with each sandbox provider. The provider’s terms, privacy practices, charges, quotas, regional availability, and remedies apply directly to Customer. Wildflower does not waive or replace those terms.
Customer is responsible for confirming that its provider agreement permits the intended workload and authorizes use through Wildflower. Technical API compatibility does not establish permission for resale, sublicensing, or another commercial arrangement.
5. Customer Content and data flow
Wildflower receives commands, environment values, file paths, file contents, and provider responses only as needed to complete a requested operation. The current service forwards this material through the API path to the selected provider and returns the normalized result.
Wildflower’s operation telemetry excludes commands, environment values, paths, file contents, stdout, stderr, provider credentials, and reversible provider-native sandbox identifiers. Sandbox registry and idempotency records contain only the operational facts needed to route resources, reconcile outcomes, and prevent duplicate creates.
6. Provider availability and errors
A provider may reject credentials, limit requests, change an upstream API, or become unavailable. Wildflower normalizes known error classes and fails closed when a create outcome cannot be proved. Customer must not blindly retry an outcome-unknown create.
Wildflower may add, update, suspend, or remove a provider adapter when needed for security, legal compliance, upstream compatibility, or provider availability. Adapter availability does not guarantee that every provider feature is exposed.
7. Resource limits
Wildflower may enforce limits on request bodies, command output, files, execution duration, concurrent work, projects, keys, sandboxes, and request rates. Current machine-readable limits and errors are part of the API contract. Provider limits may be more restrictive.
8. Features not currently offered
- No server-managed automatic provider selection or failover.
- No migration of an existing sandbox between providers.
- No Wildflower billing, provider resale, credits, or marketplace.
- No Wildflower-operated sandbox capacity.
- No AI model execution or completed agent platform.
- No guarantee that provider capabilities are interchangeable.
9. Sandbox and model providers are separate
A sandbox provider supplies an isolated compute environment. An AI model provider supplies model inference. Choosing one does not choose the other, and this Schedule does not govern a separate model provider relationship.
10. Future service modes
Wildflower may later offer Customer-authorized routing policies, Wildflower-contracted provider capacity, or Wildflower-operated infrastructure. Those modes will not silently inherit this BYOK allocation. Before launch, a revised Schedule or Order Form will identify provider selection authority, fees, data-processing roles, supported regions, service levels, and responsibility for third-party provider terms.