Model routing
Call OpenAI, Anthropic, Google, DeepSeek, Meta, and other providers through consistent schemas. Route work to the right model, apply fallback when providers fail, and track model cost per request.
Agent-native Platform for builders
SandBase is an Agent-native Platform for AI Agents
SandBase gives production AI agents one Agent-native Platform for model calls, cloud sandboxes, MCP servers, reusable skills, long-running sessions, traces, and tool access. Teams use this Agent-native Platform through an OpenAI-compatible API, a terminal CLI, and MCP connectors that coding agents can understand.
The platform is built for agent-native applications rather than one-off chat demos. A backend can route requests across language, vision, image, video, and audio models; attach secure sandboxes when code or files must run; and preserve session history so agent work can be inspected, resumed, retried, and billed. Builders can start with one API key, then add orchestration, MCP tools, skills, and console workflows as the Agent-native Platform matures.
What the Agent-native Platform includes
SandBase combines the runtime services that an agent needs after a prototype becomes a real product. Instead of stitching together a model gateway, isolated execution, prompt tools, session storage, and cost tracking by hand, teams can use one Agent-native Platform surface and keep the same workflow across API, CLI, dashboard, and MCP.
Secure cloud sandboxes
Run generated code, file operations, browser-like workflows, and build steps in isolated environments. Sandboxes keep risky execution away from application servers while preserving outputs for review.
MCP servers and skills
Give agents governed access to tools, data sources, and reusable instructions. MCP servers, skills, and prompt context let Codex, Claude, Sandy, and custom agents use the same capabilities.
Durable sessions
Store agent messages, tool calls, traces, files, and generated artifacts in sessions. A durable runtime makes agent behavior observable, debuggable, and easier to replay.
Why agent teams choose SandBase
Agent products need more than a completion endpoint. They need a place where model selection, tool execution, context, safety boundaries, billing, and inspection work together. SandBase is an Agent-native Platform because those runtime concerns are first-class: every call can be traced, every sandbox can be isolated, every tool can be attached intentionally, and every builder can work from the same product map.
- For backend teams: use one API for direct model calls, agent sessions, outputs, and cost tracking without building provider adapters from scratch.
- For AI coding workflows: give Codex and Claude a builder.md context file, CLI commands, and MCP setup so they know how to use SandBase correctly.
- For product teams: move from prototype to production with observable sessions, reusable skills, governed tools, and a dashboard for API keys and usage.
- For platform teams: keep execution isolated, route across providers, and monitor spend while shipping agent features faster.
How the runtime fits into an application
A typical SandBase workflow starts when your application creates a session or calls a model. The agent can choose a model, execute a tool, open a sandbox, inspect generated files, and return a structured result. The app can poll events, stream updates to the user, save outputs, and continue the same session later. The same runtime supports direct component calls for simple tasks and full agent workflows when state, tools, and traces matter.
- Create an API key in the SandBase console and choose whether the app needs direct model calls or a durable agent session.
- Use the OpenAI-compatible endpoint or SandBase agent API from your backend, CLI, or automation workflow.
- Attach MCP servers, skills, cloud sandboxes, and model routing rules when the agent needs tools or controlled execution.
- Inspect traces, session events, generated artifacts, usage, and cost so production behavior stays visible.
This is the practical difference between a generic AI gateway and an Agent-native Platform. SandBase keeps the operational pieces around the model call close to the agent itself, so applications can ship complex workflows without losing control of security, cost, and observability.
Use cases for production AI agents
SandBase is useful when an agent must do real work for a user, not only answer a prompt. The Agent-native Platform gives these workflows a shared execution layer, so teams can move between experiments and production systems without changing the mental model each time.
That consistency matters for search intent too: if a developer sees Agent-native Platform in an ad, the homepage should immediately confirm the same promise. SandBase repeats Agent-native Platform in the product story because it is the actual category: a platform for agents that need runtime, tools, sandboxes, model routing, sessions, and operational review in one place.
For example, a customer support agent might retrieve account data, call a language model, generate a remediation script, run that script in a sandbox, and save the final artifact to a session. A research agent might collect sources, summarize them with a routed model, use MCP tools for enrichment, and expose every step as traceable events. A coding agent might read the SandBase builder guide, choose the correct endpoint, execute tests in an isolated environment, and return files that the application can review. These are runtime problems, so they belong in the same platform, with a consistent developer experience from local testing to production deployment and ongoing operational review needs.
Agent workflows
Create agents with a model, system prompt, tools, skills, MCP servers, environment settings, and session state. Use this pattern for support copilots, research assistants, coding helpers, operations agents, and internal automation that must be inspected after it runs.
Sandboxed tool execution
Let agents run generated code, transform files, test scripts, parse documents, or create artifacts in a controlled sandbox. The application can receive the result while the risky execution stays isolated from production infrastructure.
Direct AI component API
Call LLMs, embedding models, image generators, video generators, audio models, and other components directly when the application does not need a full agent loop. Teams can still use SandBase model cards, schemas, routing, and cost visibility.
Agent-native Platform FAQ
Is SandBase only a model gateway?
No. Model routing is one part of the platform, but SandBase also includes cloud sandboxes, MCP access, skills, sessions, traces, generated outputs, API keys, billing, and dashboard workflows. The goal is to host the runtime layer around the model, not merely proxy model traffic.
Can I use existing OpenAI-style clients?
Yes. SandBase supports OpenAI-compatible access for model calls, and it also exposes SandBase-specific agent and runtime APIs when a workflow needs sessions, tools, sandboxes, or richer outputs. This lets teams adopt the runtime gradually.
How does this help Codex or Claude?
The builder guide, CLI, and MCP surfaces give AI coding agents concrete instructions for SandBase. A coding agent can learn which endpoint to call, when to use a sandbox, how to name models, and how to avoid inventing SDKs or unsupported routes.
Why not build this in-house?
Teams can build each piece separately, but production agents quickly need many moving parts at once: provider routing, schema handling, isolation, tool governance, sessions, observability, and cost controls. SandBase packages those concerns into one Agent-native Platform so product teams can focus on the agent experience.
Start building on the Agent-native Platform
Use SandBase when an agent needs models, tools, memory-like session continuity, code execution, generated artifacts, and real production controls. Start with one API key, read the builder guide, then add the Agent-native Platform services your agent needs as it grows.