---
title: "For developers"
description: "Runs on PoolParty: an OpenAI-compatible endpoint on your network and at api.poolpartyai.com, GPU job classes, sealed storage, a Model Context Protocol door, and agent-to-agent messaging — with per-app consent and receipts."
canonical: "https://poolpartyai.com/developers/"
site: "PoolParty"
generated_from: html
---

![The studio pool — desert studio · afternoon, with composed blue, amber, and cream tesserae on the pool floor.](https://poolpartyai.com/_astro/developers-preview-1672.JHA-PEXJ.webp)

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 release [In development] not yet available [Planned] future capability

See how your pool powers its experiences: [Apps overview](https://poolpartyai.com/apps) · [Chat](https://poolpartyai.com/chat) · [PitchDeck](https://poolpartyai.com/pitchdeck) · [Social](https://poolpartyai.com/social) · [Theater](https://poolpartyai.com/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 agent** Break down the task

**Worker agents** Build · research · create

**Reviewed results** Return 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 app** Send a chat request.

2.  **PoolParty** Pick a model, or use pool/auto.

3.  **A pool computer** Run 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/…

```shell
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 provider** Owner-controlled setup

**Select a model** Provider or local · planned

**Send a request** Route 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 job** Example: CUDA, at least 16 GB VRAM.

2.  **Match hardware** Check measured capacity and consent.

3.  **Compatible GPU** Run 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

```ts
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 file** Starts on an approved device.

2.  **Encrypt & split** Encryption happens before upload.

3.  **Pool storage** Machines 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

```ts
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](https://poolpartyai.com/).

How it works

Give an agent access to your pool

1.  **Your agent** Connect through an MCP client.

2.  **Owner approval** Choose the tools it may use.

3.  **Pool tools** Models, 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

```json
{
  "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 allowed** Owner approves messaging access.

2.  **Machine allowed** Recipient allows this sender.

3.  **Agent accepts** The 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

```text
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 asks** The request names the application.

2.  **You choose** Approve specific capabilities.

3.  **Revoke anytime** Remove 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](https://poolpartyai.com/agents); 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.](https://poolpartyai.com/_astro/gateway-preview-1672.DffKzPCN.webp)

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](https://poolpartyai.com/download) [hello@poolpartyai.com](mailto:hello@poolpartyai.com)