PoolParty™ Open workspace
The studio pool — desert studio · afternoon, with composed blue, amber, and cream tesserae on the pool floor.

For developers

Build with your pool’s models and compute.

Connect through an OpenAI-compatible API or MCP. Run models, submit GPU jobs, store encrypted files, and exchange agent messages with owner-approved access.

  • Chat API
  • GPU jobs
  • Encrypted storage
Available in beta verified in the published releaseIn development not yet availablePlanned future capability

See how your pool powers its experiences: Apps overview · Chat · PitchDeck · Social · Theater

Agent crews and harnesses · In development

Coordinate agents around a shared task.

The planned orchestration service connects a lead agent with role-specific workers. It will make assignments, model choices, approvals, and results visible, while respecting each machine’s existing consent limits.

Lead agentBreak down the task
Worker agentsBuild · research · create
Reviewed resultsReturn for approval

Concept workflow · Crew execution and broader harness integrations are not qualified for release yet.

Chat API

Use the OpenAI-compatible chat API

The pool serves an OpenAI-compatible chat surface. Existing code ports with a change of base URL — that is the whole integration. On your own network the pool answers directly; remote API clients can use https://api.poolpartyai.com behind a key you mint, with a rate limit and a budget on every key. This is PoolParty’s own hosted API; guided setup for third-party provider models is a separate feature in development.

How it works

Ask in your app. Answer on your hardware.

  1. Your appSend a chat request.
  2. PoolPartyPick a model, or use pool/auto.
  3. A pool computerRun the model and stream the answer.
The response names the model and explains the routing choice.

Chat completions

Available in beta

on your own network at the pool's address · from anywhere at https://api.poolpartyai.com/v1/service/…

curl "$POOL_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $POOL_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "pool/auto",
    "messages": [{ "role": "user", "content": "Hello" }],
    "stream": true
  }'

Streaming works. pool/auto lets the pool pick the model and say why in the response’s routing block; name a model instead to pin it. Responses carry honest fields for the structural-verification caveat: the pool can attest that a run happened on the node it says, not that a model’s answer is correct.

Provider model connections · In development

Bring supported model APIs into your pool.

The planned setup flow will help owners connect a supported provider model beside local models and select where each task runs. Provider secrets remain in the approved app credential store; provider billing is separate from PoolParty credits.

Approve a providerOwner-controlled setup
Select a modelProvider or local · planned
Send a requestRoute and cost shown

Concept workflow · Provider onboarding is not available in the beta.

GPU jobs

Run jobs on compatible GPUs

You describe what the job is. The scheduler decides where it runs, by matching your requirements against what each machine has actually been measured to have.

How it works

The job goes where the right GPU is

  1. Submit a jobExample: CUDA, at least 16 GB VRAM.
  2. Match hardwareCheck measured capacity and consent.
  3. Compatible GPURun the payload on that machine.
Use a desktop GPU from your laptop. Hardware requirements still apply.

Submit a GPU job

Available in beta

sandboxed WebAssembly job groups by default · the native GPU tier behind its own consent

const job = await pool.jobs.submit({
  class: "photogrammetry",
  files,
  requirements: { needsCuda: true, minVramGb: 16 },
  webhook: "https://example.com/hooks/job-done",
});

const status = await pool.jobs.status(job.id);

An honest boundary, stated up front: the pool executes jobs on machines that can run them. It does not translate between hardware — a CUDA job needs a CUDA machine and a payload built for one. Job placement is available in the beta. Coordinating agent crews is a separate capability in development.

Encrypted storage

Encrypt and store files across your pool

Files are encrypted before they leave, split, and scattered. Reading them back requires a key that lives only on devices you approved.

How it works

Encrypt first. Then distribute the pieces.

  1. Your fileStarts on an approved device.
  2. Encrypt & splitEncryption happens before upload.
  3. Pool storageMachines store encrypted chunks.
Only approved devices hold the keys needed to read the file.

Sealed put and get

Available in beta

on a pool you have joined · encrypted before it leaves your device

const ref = await pool.storage.put(file);
const stream = await pool.storage.get(ref.id);

The machines holding the chunks see opaque blocks — no filenames, no grouping, no keys — and no machine holds enough of a file to reconstruct even its encrypted form.

MCP integration

Connect agents through MCP

One configuration line, and an agent can discover what the pool can do — machines, accelerators, models, storage — and use it directly. A real Claude Code session did exactly this on a live pool; the run is quoted on the home page.

How it works

Give an agent access to your pool

  1. Your agentConnect through an MCP client.
  2. Owner approvalChoose the tools it may use.
  3. Pool toolsModels, jobs, storage and messages.
Turn access off and the next tool call is refused.

Model Context Protocol server

Available in beta

loopback only, off by default, one explicit toggle to enable · the hosted door at api.poolpartyai.com for machines outside the pool

{
  "mcpServers": {
    "poolparty": { "command": "poolparty", "args": ["mcp"] }
  }
}

No new trust path: the agent surface is a client of the same channels and the same consent gates as everything else, it listens on loopback only, and it is off until you turn it on.

Agent messaging

Send messages between your agents

The same door carries a mailbox. An agent declares a handle when it opens its door; agents on your other machines can find it, message it, and wait for its reply — sealed device to device, couriered as ciphertext by the hub when a machine is offline.

How it works

Three permissions before a message arrives

  1. Sender allowedOwner approves messaging access.
  2. Machine allowedRecipient allows this sender.
  3. Agent acceptsThe receiving agent accepts the message.
Device-to-device threads are sealed. Sending a message does not authorize tool actions.

Agent messaging over the door

Available in beta

three locks, all off by default · every thread readable by the humans who own the machines

agents_list                        → handles reachable in pools where Use is on
agents_send    to, text, thread?   → message id + receipt
agents_receive thread?, wait_ms     → long-poll for replies (≤ 60 s)
agents_ask     to, text, timeout    → send and wait for the first reply
agents_threads                     → this door's threads

Lock one: the sending agent’s door needs the agents.message scope, approved once in plain words on the machine it runs on. Lock two: the receiving machine’s inbound rail, off by default, with an allow-from list. Lock three: the receiving agent’s own acceptance. Refusals come back by name; a loop guard stops two agents ping-ponging forever. Messages are speech — actions stay behind consented tool doors, which are Planned.

Trust model

Control permissions for each app

How it works

Each app gets only the access you approve

  1. App asksThe request names the application.
  2. You chooseApprove specific capabilities.
  3. Revoke anytimeRemove the app’s access.
Service keys also carry their own rate limits, quotas and budgets.

Request access

Available in beta

An application’s first call raises a prompt in the PoolParty app naming the application that is asking.

Limit permissions

Available in beta

Approval mints a token scoped to the capabilities you chose — jobs, chat, storage — and nothing wider.

Revoke access

Available in beta

Connected applications are listed in the app with a revoke button beside each. Nothing is ambient.

Service keys for backends carry a quota, a rate limit and a budget each, metered per key, and refuse by name when they run out. The SDK and the example configurations live in the agent kit linked from the agents page; the tool doors that let an agent act on your other machines, and the web door that puts your pool behind a site you run, are Planned.

Build from anywhere

Connect a remote app to your own compute

The infinity pool — coastal · morning, with a turquoise and gold mosaic threshold on the pool floor.

PoolParty

One integration. Access beyond the LAN.

Remote applications use the hosted gateway with a key you create. Models still run on your pool hardware.

  • Scoped keys
  • Rate limits
  • Per-key budgets

Build an app that uses your pool

Download it and point a tool at it — then tell us what you would run. It genuinely shapes what gets built next.

Download PoolParty hello@poolpartyai.com