Skip to main content
This page is the current public status map for SimpleFunctions developer surfaces. The SDK and Agent SDK are now published as stable packages, while the CLI and HTTP API remain separate surfaces with their own contracts.

​
Current state

​
Which surface should I use?

Use the HTTP API if:
  • you are not writing TypeScript
  • you need direct control over requests and response handling
  • you are integrating from a service that already owns auth, retries, and error mapping
Use the CLI if:
  • a human, shell script, CI job, or coding agent is operating from a terminal
  • you want the richer sf agent local loop
  • you need headless NDJSON tooling
  • you need local runtime controls such as sf runtime
Use the SDK if:
  • you are writing TypeScript
  • you want typed reads and stable resource objects
  • you want API-key-first client behavior
  • you want strict manifest inspection through sf.manifest.*
  • you need K-line/OHLCV candle reads and watchlist-first screening through sf.markets.candles() and sf.markets.screenCandles()
  • you need Kalshi or Polymarket execution.place, runtime orchestration, and intent management with explicit auth
Use the Agent SDK if:
  • you already have an application, worker, or agent harness
  • you want a Cursor-style Agent.create().send().stream() lifecycle
  • you want SimpleFunctions strict tools mounted into a model loop
  • you need policy hooks, sideEffect, costEffect, sessions, watch inputs, local trace, and replay
  • you want to compose research, monitoring, execution, and management agents behind configurable safety valves
Use the low-level direct runner only when you need deterministic canonical tool calls without a model loop.

​
What is not shipped

These are not shipped as stable SDK/Agent capabilities:
  • GA semver compatibility
  • browser runtime or long-lived browser API keys
  • MCP runtime inside the Agent SDK
  • events.*
  • market.related semantic graph
  • auth.status
  • investigations.create
  • intents.propose
  • webhooks.create
runtime.status and runtime.ensure are canonical SDK methods for runtime readiness. live_trade is a side-effect class and compatibility alias for execution.place; it is not a canonical SDK method.

​
Tool truth hierarchy

For SDK and Agent SDK work, use this hierarchy: Do not treat /api/tools or MCP names as SDK/Agent canonical names. For example:

​
Roadmap

The current sequence is:
  1. Keep the current stable SDK and Agent SDK versions pinned in examples and customer projects.
  2. Keep execution expansion contract-first through /api/contracts/tools.
  3. Harden watch/model-loop/execution examples against real production workloads.
  4. Add public support, rate-limit, and error-handling commitments before GA.
  5. Keep 1.x stable releases backward-compatible for direct-runner replay, trace behavior, and policy gates.
Browser runtime, MCP runtime, or broad /api/tools aliasing is not part of the current SDK roadmap.