Olyx SDKs
Olyx SDKs give services a typed interface for tracing, executing, and observing AI workflows. They are the primary way to use Olyx when you want more than a transport swap.
You can start in two ways:
- Use the Olyx SDK for first-class traces, execution helpers, tool loops, and MCP orchestration.
- Use the OpenAI-compatible gateway by changing your base URL when you only need a migration-friendly transport path.
The gateway route is intentionally lightweight. It is ideal for migration, but it does not give you the full SDK surface:
- explicit trace creation
execute-based request lifecycle control- typed result objects
- tool call continuation
- MCP tool wiring
- simulate / dry-run checks
- project-aware metadata and governance context
What the SDK gives you
The SDK path is useful when you want your application to stay in charge of the workflow instead of treating Olyx as a thin proxy.
| Capability | Why it matters |
|---|---|
| Trace binding | Every request is attached to a trace, which keeps execution, costs, and replay data connected. |
execute lifecycle | You control the request step, any follow-up tool loop, and the final response. |
| Typed responses | SDK methods return structured objects instead of raw HTTP payloads. |
| Tool orchestration | The SDK can continue a model request after tool calls return. |
| MCP support | Declare MCP servers as tools and keep their execution tied to the same trace. |
| Simulate / dry-run | Preview routing, risk, and cost before you spend tokens or hit a provider. |
| Private deployment support | Use the SDK with private-agent routes when you need outbound-only infrastructure. |
| Governance metadata | Attach project, user, and intent context so policy and observability stay useful. |
Common use cases
The SDK is a good fit for user retention analytics, MCP-powered support workflows, multi-step automations, private deployments, and model comparison. For concrete examples, see SDK use cases.
SDKs
- TypeScript
- Python
- Ruby
When to use the SDK
Use the SDK when you want:
- trace helpers and step-level control
- typed resource clients
- scoped MCP tool execution
- project-aware execution metadata
- tool-call continuation through
execute - simulate / dry-run checks before execution
- private-agent friendly deployment paths
When to use the OpenAI-compatible gateway
Use the gateway when you want to migrate an existing app with minimal code changes and you do not need the richer SDK lifecycle.
That path is best for quick adoption, while the SDK path is better for teams that want:
- explicit trace creation and replayability
- direct control over tool execution
- MCP orchestration in application code
- model routing decisions that remain visible to the application
- stronger alignment with observability and governance workflows