Build with Synaptika.

Synaptika is a marketplace that connects demand-side users with a global network of community-run inference suppliers. Inference goes out as standard OpenAI chat-completions requests, gets load-balanced across registered providers, and comes back with Synaptika metadata so you know exactly which node served you.

1. 01

   Sign up

   Create a marketplace account at app.dev.synaptika.com.

2. 02

   Pick a pool

   Pools group providers by tier or model. Each has advertised capacity in tokens/hour.

3. 03

   Mint a VPI

   A Virtual Private Instance reserves capacity from a pool against your token budget.

4. 04

   Use the API key

   Each VPI ships its own sk-vpi-* key — drop it into any OpenAI client.

If you already know the model, the fastest path is: mint → copy key → cURL. The full anatomy of the request lives in the integrations section below.

curl -X POST \
  https://app.dev.synaptika.com/api/v1/vpis/<your-vpi-slug>/v1/chat/completions/ \
  -H "Authorization: Bearer sk-vpi-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<model-slug>",
    "messages": [{"role": "user", "content": "Hello, Synaptika."}],
    "max_tokens": 128
  }'

Replace <your-vpi-slug> with your VPI slug,sk-vpi-... with the key from your VPI's Credentials tab, and <model-slug> with the marketplace slug (e.g.llama323b) — not the underlying Ollama tag (llama3.2:3b).

Synaptika issues two kinds of keys — for two separate purposes. Pick the right one for what you’re wiring up.

Authenticating an inference call

Every request to /api/v1/vpis/<slug>/v1/chat/completions/ is gated on the VPI’s own key — JWT/session auth is disabled on that route on purpose so third-party tools work.

POST /api/v1/vpis/<slug>/v1/chat/completions/
Host: app.dev.synaptika.com
Authorization: Bearer sk-vpi-...
Content-Type: application/json

Discovering available models

Pool slugs and model slugs live behind the public model registry. Hit it without auth to see what’s servable today.

curl -s https://app.dev.synaptika.com/api/v1/models/ | jq '.results[] | {slug, name, pools: [.pools[].slug]}'

A pool is a group of providers serving a shared capacity ceiling, expressed in tokens/hour. Capacity is split between what’s already committed to active VPIs and what’s still free.

Spot service: covered and uncovered

A request paid from credits is spot, and it is served one of two ways. It is covered when a holder’s pledged VPI stands behind it: it rides that floor and holds when the pool is busy. It is uncovered when it runs on capacity nobody has bought: best effort, and the first traffic shed when demand passes what the pool can serve. Two requests at the same price can therefore see different outages. Each spot response says which it got: the X-Synaptika-Service-Class header (covered or uncovered), and in a non-streaming reply synaptika.service_class with sheds_first. A covered request still yields to the pledge holder’s own use of their VPI.

Browsing models

Open /models to see the capacity financial actors have pledged into the network: rentable tokens-per-hour per offer, the spot rate you pay, the term left, and which model it serves. The availability bar turns amber as an offer fills up.

curl -s https://app.dev.synaptika.com/api/v1/vpis/offers/ | jq '.results[] | {
  id,
  seller: .holder,
  pool: .pool_slug,
  model: .model_slug,
  rentable_tph: .headroom_tokens,
  price_input_per_1m,
  price_output_per_1m
}'

Renting a VPI

Open an offer and use the right-rail rent form, or call the API directly with the offer id. The commit slider is clamped to min(offer_headroom, your_available_budget), so you can’t over-allocate. The pool is derived from the offer.

{
  "name": "my-assistant",
  "offer": <offer-id>,
  "committed_tokens": 1000000
}

The response includes the auto-generated slug, the freshly minted api_key (sk-vpi-…), and the endpoint URL. Store those — the key is only echoed back to you on creation and rotation.

Token economy

• Every account starts with a 50,000,000-token monthly budget.
• tokens_committed is the sum of unused reservations across active VPIs.
• tokens_available = budget − consumed − unused_committed.
• Releasing a VPI returns its unused committed portion to the pool.

curl -H "Authorization: Bearer <jwt-access-token>" \
  https://app.dev.synaptika.com/api/v1/vpis/budget/

Synaptika speaks OpenAI chat-completions. Any tool that lets you point at a custom baseUrl + Bearer token will work. Below are the verified configs for the three most common surfaces.

# 1. set your VPI key + slug
export SYN_KEY="sk-vpi-..."
export SYN_VPI="<your-vpi-slug>"
export SYN_MODEL="<model-slug>"   # e.g. llama323b

curl -sX POST \
  https://app.dev.synaptika.com/api/v1/vpis/$SYN_VPI/v1/chat/completions/ \
  -H "Authorization: Bearer $SYN_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$SYN_MODEL\",
    \"messages\": [{\"role\":\"user\",\"content\":\"Hi Synaptika\"}],
    \"max_tokens\": 128
  }" | jq

{
  "choices": [{ "message": { "role": "assistant", "content": "Hello!" } }],
  "usage":   { "prompt_tokens": 33, "completion_tokens": 10, "total_tokens": 43 },
  "synaptika": {
    "vpai":         "<your-vpi-slug>",
    "node_id":      "node-7312",
    "latency_ms":   1291
  }
}