# Bring Your Own Compute

## A Concept for User-Delegated AI Compute

**Concept Paper v0.1 - 30 September 2026**  
**Arjen Roos**

![An old-fashioned telephone switchboard, used here as a conceptual analogy for connection establishment rather than data inspection.](../assets/switchboard.png)

*Figure 1. The switchboard establishes a connection; it does not need to participate in the conversation.*

### Abstract

AI inference is no longer available only from large centralized providers. Individuals, developers, researchers, and smaller organizations can run useful models on personal computers, workstations, organizational servers, and rented GPU infrastructure. Yet most applications still assume that inference comes from their developer or a centralized AI provider.

This paper explores **User-Delegated BYOC**: the ability for a user to authorize an application to use AI compute the user controls or selects, without requiring the application provider to own that compute or the authorization broker to participate in the inference data path. The term *bring your own compute* is not new; it is already used in enterprise infrastructure. The distinct question here is whether compute can become a user-delegatable capability across applications.

The proposal is intentionally not a protocol specification. OAuth, GNAP, private networking, OpenAI-compatible serving, MCP, and local runtimes already supply important pieces. Products such as LM Studio LM Link, Tailscale, Microsoft Foundry Local, Warp custom inference endpoints, NVIDIA NIM, NVIDIA DGX Cloud Lepton BYOC, Cloudflare AI Gateway, BazaarLink BYOC, QVAC, and compute marketplaces demonstrate meaningful adjacent or overlapping work. The defensible claim is narrower: no broadly adopted, application-agnostic interoperability layer was identified that combines user-selected compute, scoped delegation, capability-oriented selection, revocation, and a broker that can remain outside the plaintext inference path. That conclusion should be revisited as this fast-moving ecosystem changes.

---

## 1. The observation

**User-Delegated BYOC is the ability for a user to authorize an application to use AI compute the user controls or selects, without requiring the application provider to own that compute or the authorization broker to participate in the inference data path.**

A developer may use Codex while owning a computer capable of running a strong open-weight coding model. Routine work might be suitable for that local machine; difficult work might be better sent to OpenAI or another cloud provider. Today, connecting these choices commonly entails public servers, API keys, reverse proxies, tunnels, firewall rules, or model-specific integrations. The desired interaction is simpler: **“Allow this application to use my AI compute.”**

The user should be able to choose among local compute, privacy, speed, capability, cost, and cloud compute. “User” is not limited to a consumer: it may be an independent developer, a researcher, a maker, a small business, a team, or a privacy-sensitive professional.

BYOC already exists in several forms, particularly enterprise infrastructure. NVIDIA DGX Cloud Lepton, for example, uses BYOC for customer-owned machines brought under its workload-management platform [13]. This paper explores a different abstraction: **User-Delegated BYOC**.

## 2. The switchboard model: connect, don't inspect

An old telephone switchboard established a connection between two parties; it did not need to participate in the conversation. That is a useful, deliberately limited analogy.

```text
Control plane: identity, consent, discovery, capability description,
               authorization, connection establishment, revocation
                         │
                         ▼
Data plane:          application <──── encrypted/direct or relayed ────> compute
```

The design goal is: **control plane at the broker; inference data plane between application and authorized compute.** “Connect, don't inspect” means that an authorization or coordination provider should not necessarily receive plaintext prompts, attachments, outputs, or tool context.

This does not require direct peer-to-peer connectivity in every deployment. NATs, firewalls, and topology sometimes require relays. Tailscale is useful precedent: its coordination service handles identity, policy, discovery, and connection coordination, while devices carry encrypted data; DERP relays can forward already encrypted traffic when direct connectivity is unavailable [5-7]. An end-to-end encrypted relay is therefore compatible with the concept. The privacy property is about plaintext visibility, not about pretending that every packet takes a direct route.

## 3. Privacy and security: an option, not an automatic result

Local AI is not inherently safer. A poorly maintained local machine, exposed endpoint, long-lived credential, or weak access policy can be unsafe. Controlled compute can, however, offer stronger data-sovereignty options: a user or organization may choose where data is processed and who operates that environment.

A mature implementation could make secure connectivity a product capability rather than an individual integration project. That matters because manually exposing inference servers and assembling tunnels, credentials, and firewall rules is error-prone.

Privacy-sensitive policies might look conceptually like this:

```text
LOCAL_ONLY             Never leave approved controlled compute.
LOCAL_PREFERRED        Use approved compute first; escalation needs a rule.
CLOUD_ALLOWED          Cloud is an approved source for this workload.
NO_AUTOMATIC_FALLBACK  Fail visibly rather than silently change data locality.
```

The last policy matters. A local-provider outage should not silently send source code, documents, photographs, or financial information to a cloud provider merely because an application has a fallback. In some designs, the strongest available statement is not “we promise to handle your data appropriately,” but “we do not receive your inference data.” That is a possible property of a separated control/data-plane design, not a claim about every BYOC implementation.

## 4. Ask for capabilities, not a machine or model name

Applications should ideally describe what they need rather than bind themselves to a model label or a hardware SKU:

```yaml
requires:
  reasoning: true
  vision: true
  tool_use: true
  structured_output: true
  context: ">=64000"
```

A user-controlled layer could match that request to Qwen on a DGX Spark, a model on a Mac, NVIDIA NIM, an organizational server, rented capacity, an OpenAI cloud model, or a future runtime. This does not prescribe a capability schema for v0.1. It identifies a likely interoperability need: a shared vocabulary for describing available compute and acceptable workloads.

## 5. Who benefits?

### Independent developers

Inference can become a large recurring application cost. User-delegated compute could let a developer provide functionality without also becoming an inference operator: the application provides the workflow; the user provides or selects compute.

### Hobbyists, makers, and prosumers

Many technically interested users already own Macs, AI PCs, GPU workstations, or dedicated AI systems and can run models. The fragmented part is safely making that capacity usable by applications.

### Researchers

Research data may need to stay inside a workstation, laboratory, or institution. An application could use compute where the data already resides rather than requiring the data to travel to an external inference provider.

### Small and medium-sized businesses

SMBs/MKBs may have confidentiality, intellectual-property, customer-data, or regulatory requirements without an enterprise infrastructure team. Affordable local hardware can make private inference feasible while integration remains difficult.

### Privacy-sensitive users

The category is broader than regulated organizations: private documents, source code, financial information, photographs, unpublished creative work, and personal information may simply be data a person does not want sent to an external inference provider.

## 6. Prior art: the stack already exists in pieces

### User-carried AI entitlement: Sign in with ChatGPT

OpenAI's Sign in with ChatGPT separates identity sign-in from optional plan usage. Eligible ChatGPT Plus and Pro users can authorize participating applications to make eligible AI requests using their plan or available credits; the docs distinguish this from access to conversations or API keys [1,2]. Availability and eligibility are product-specific and may change. It is not BYOC compute selection, but it demonstrates a nearby principle: a user can carry AI entitlement into an application instead of every developer funding inference directly.

### Secure discovery and remote local models: LM Link and Tailscale

LM Studio's LM Link creates an end-to-end encrypted network across devices a user owns, using Tailscale. It provides remote-model discovery and lets an existing local LM Studio API client use a remote model through `localhost`; LM Studio documents integrations with Codex and Claude Code [3,4]. LM Studio says its Hub facilitates discovery while chats and model listings subsequently travel inside the encrypted Tailscale connection [4]. LM Link is unusually strong practical prior art for the switchboard pattern, but it is currently a LM Studio/llmster device ecosystem rather than a general delegated-compute authorization layer for arbitrary applications.

Tailscale independently demonstrates the control/data-plane split: its coordination service manages discovery, keys, policy, and NAT traversal without routing ordinary traffic; clients exchange encrypted traffic directly when possible or via encrypted relays when necessary [5-7]. It does not itself define AI capabilities or app-to-compute consent.

### Delegated authorization: OAuth, GNAP, and MCP

OAuth Resource Indicators (RFC 8707) let a client signal the protected resource for which it requests an access token [8]. GNAP's core protocol is now RFC 9635 and its Resource Server Connections companion is RFC 9767; it frames delegated access among a client, resource owner, authorization server, and resource server [9,10]. Neither standard is an AI-compute protocol, and BYOC should reuse rather than replace mature authorization work.

MCP provides interoperable discovery of tools, prompts, and resources and an OAuth-based authorization model for protected resources [11]. Its legacy sampling feature also shows a server asking a client to obtain a model completion, but sampling is deprecated in the July 2026 specification release [12]. MCP therefore provides important vocabulary and authorization precedent; it does not, on the reviewed specifications, establish a general application-agnostic mechanism for a user to select an arbitrary controlled inference provider with capability matching and a plaintext-independent broker.

### Local serving and application choices: Foundry Local, Warp, and NVIDIA NIM

Microsoft Foundry Local can expose local models through an OpenAI-compatible REST endpoint, including a local server for multiple processes [15]. It is relevant enterprise and local-serving prior art: a governed Microsoft ecosystem can make local/private inference practical. This paper's focus is different - user-centered interoperability across applications, runtimes, and compute sources - so it does not depend on a detailed comparison of Microsoft identity flows.

Warp lets a user point the Warp application to a custom OpenAI-compatible inference endpoint, including internal gateways, and supports BYOK and enterprise BYOLLM variants [16]. This is strong application-level bring-your-inference prior art. The documentation does not establish a general interoperability layer for other applications, and its own endpoint routing should not be assumed to bypass Warp without an explicit architectural statement.

NVIDIA NIM can run local or private model deployments and exposes OpenAI-compatible endpoints, including chat completions and Responses API endpoints; NVIDIA documents Codex CLI setup and tool calling [17,18]. NIM makes sophisticated controlled inference available behind common APIs, but it does not provide user-delegated discovery and authorization across unrelated applications.

### Enterprise BYOC: NVIDIA DGX Cloud Lepton

NVIDIA's DGX Cloud Lepton BYOC feature imports customer-owned hardware into Lepton node groups and lets it be managed as part of the platform [13,14]. It is important prior art: customer-controlled compute can participate in a managed AI ecosystem. Its abstraction is organization/platform-managed infrastructure, not a user authorizing arbitrary third-party applications to use selected compute.

### Gateways and tunnels: Cloudflare and BazaarLink

Cloudflare AI Gateway supports custom providers, including self-hosted AI models, but requests sent to its gateway endpoint traverse the gateway; it is therefore a **proxy**, not equivalent to a design where the broker is outside the plaintext inference path [19]. Cloudflare's access and tunnel products can be relevant connectivity and identity building blocks, but the data-path property is product- and deployment-specific.

BazaarLink BYOC is closer than a generic gateway: it supports an agent connected outbound to a BazaarLink gateway and local Ollama, LM Studio, vLLM, or llama.cpp backends. Its own architecture diagram is “customer machine -> BYOC Agent -> BazaarLink gateway -> customer app,” and it supports fallback to BazaarLink models [20]. It is a useful example of user-/organization-owned inference behind one application API, but the gateway remains in the declared request path and the system is not presented as a neutral consent layer for arbitrary applications.

### Delegated peer inference: QVAC and open-source work

QVAC documents encrypted peer-to-peer inference delegation from a phone to a user's laptop, with blind relays for difficult networks and a common SDK interface [21]. The open-source Leash project also describes encrypted private-mesh delegated inference, peer capability tracking, and an OpenAI-shaped shim [22]. These are important counterexamples to any claim that delegated inference itself is absent. They appear focused on their own SDKs/ecosystems or paired peers rather than a widely adopted neutral layer spanning arbitrary third-party applications, but the latter characterization should be treated as a snapshot, not a permanent conclusion.

### Compute marketplaces

Vast.ai, Akash, and related marketplaces show that GPU capacity can already be described, selected, rented, and provisioned independently of an application's owner [23,24]. They are not what this paper proposes. A marketplace could be a future compute source behind a BYOC layer; BYOC would determine whether an application may use that source and under which policy.

## 7. Comparison: scope matters more than a binary yes/no

The table is intentionally conservative. “Broker outside plaintext path” means the documentation supports that property for the relevant coordination function; it does not make a security guarantee for every deployment. “Arbitrary applications” means a neutral, third-party-application interoperability mechanism, not merely any client that can configure an endpoint.

| System | User identity | Compute discovery | User delegation | Local/private inference | Broker outside plaintext inference path | Arbitrary applications | User-controlled compute |
|---|---|---|---|---|---|---|---|
| Sign in with ChatGPT | Yes | No | Plan usage: limited | No | No - OpenAI serves inference | Participating apps | No |
| LM Link | Own-device link | Own linked devices | Limited - device/link membership | Yes | Yes for Hub discovery; encrypted device traffic | Limited - compatible local API clients | Own devices |
| Tailscale | Yes | Devices, not AI capability | Network policy | General private networking | Yes; encrypted relays possible | Yes, network-level | Own/organization devices |
| Foundry Local | Microsoft/local context | Local server/models | Enterprise/local context | Yes | N/A - no broker in local use | Compatible API clients | Local machine |
| Warp custom endpoint | Warp account | User-configured endpoint | Within Warp | Partial | Unclear; do not assume bypass | No - Warp only | User-selected endpoint |
| NVIDIA NIM | Deployment-defined | Loaded models/metadata | No general mechanism | Yes | N/A - deployment-specific | Compatible API clients | Local/organization deployment |
| NVIDIA Lepton BYOC | Enterprise/workspace | Node groups | Enterprise/workspace | Organization-controlled | No claim | Enterprise Lepton workloads | Organization-controlled |
| Cloudflare AI Gateway | Yes/Access optional | Configured providers | Gateway policy | Partial | No - proxy path | Compatible gateway clients | Custom/self-hosted provider possible |
| BazaarLink BYOC | Account/organization | Bound local node/models | Account-bound routing | Yes | No - gateway is in stated path | Limited - one BazaarLink API | User/organization hardware |
| QVAC | Peer/device identity | Peer capabilities | Paired/SDK ecosystem | Yes | Yes - encrypted P2P/blind relay design | Limited - QVAC ecosystem | Own peer devices |
| Vast.ai / Akash | Account | Marketplace capacity | Customer provisioning | Rented/private deployment possible | N/A | API/tenant workloads | User-selected rented compute |
| Proposed User-Delegated BYOC | Required | Required, capability-oriented | Required, scoped/revocable | Optional | Design goal, not guaranteed | Required | Personal, organization, community, or rented |

## 8. The critical observation

The ecosystem already contains most of the primitives required for User-Delegated BYOC. What appears to be missing is a **broadly adopted, application-agnostic interoperability layer** that lets individuals delegate AI compute they control or select to applications they choose, while allowing identity and authorization infrastructure to remain outside the plaintext inference data path.

This is not “nobody has built BYOC,” nor “AI compute has never been a delegatable resource.” The prior art shows the opposite. The narrower observation may change if an existing system is shown to satisfy the full definition at interoperable, third-party-application scope.

## 9. Is a new protocol necessary?

Probably not as a first move. The missing artifact may be an **interoperability profile**, composed from established layers:

```text
Identity and consent       -> OAuth / GNAP / existing identity systems
Resource authorization     -> scoped, short-lived delegated authority
Private connectivity       -> existing encrypted networking and relays
Inference                  -> OpenAI-compatible, Responses, Messages, or other APIs
Capability discovery       -> a shared BYOC vocabulary/profile
Applications               -> coding, research, creative, and business software
Compute                    -> personal, organizational, cloud, community, or rented
```

Such a profile would need decisions about capability claims, endpoint attestation, key binding, revocation propagation, isolation, auditability, abuse prevention, quotas, billing, relay threat models, and how an application proves what it is asking to do. These are not details to hand-wave away; they are reasons to involve specialists and to reuse standards where possible.

## 10. Hybrid compute, explicitly governed

User-Delegated BYOC is not anti-cloud.

**Local first:** routine work uses approved local compute; cloud is used only under a stated escalation rule.  
**Balanced:** cloud intelligence or orchestration works with local worker models.  
**Cloud first:** cloud remains primary; controlled compute handles privacy-sensitive or specialized work.

The key is explicit policy-aware escalation. A failure to reach local compute is not consent to export sensitive input.

Once compute is abstracted from an application, it need not be physically owned by one person. It may be personal compute, organization-operated compute, voluntary community capacity, or rented capacity. BYOC is not a marketplace proposal: it determines which compute an application may use; other systems determine ownership, financing, and exchange.

## 11. What this concept is not

User-Delegated BYOC is not necessarily a new model, inference API, VPN, AI gateway, compute marketplace, replacement for OAuth, replacement for MCP, argument that local inference is always better, claim that local inference is automatically secure, argument against cloud AI, or fully specified technical protocol.

It is an architectural and interoperability concept:

> The application provides the functionality. The user provides or selects the compute. A trusted layer establishes permission and connectivity.

## 12. Scope and invitation

This proposal intentionally describes the concept rather than prescribing its implementation. Authentication, endpoint discovery, direct connectivity, cryptographic authorization, isolation, capability verification, revocation, abuse prevention, and billing require expertise from their respective fields. Existing standards should be reused wherever appropriate.

The useful next question is not “can this paper declare a new protocol?” It is: **which existing standards and products can be responsibly composed into an interoperable, user-centered compute-delegation profile, and where are the real gaps?** Specialists in identity, networking, cryptography, distributed systems, AI serving, security engineering, and product design should test that question.

---

## References

1. OpenAI. [Quickstart - Sign in with ChatGPT](https://developers.openai.com/siwc/quickstart). Accessed 30 Sep 2026.
2. OpenAI. [Integrating Sign in with ChatGPT in your Open Source App](https://developers.openai.com/cookbook/articles/sign-in-with-chatgpt), 28 Sep 2026.
3. LM Studio. [LM Link](https://lmstudio.ai/docs/lmlink). Accessed 30 Sep 2026.
4. LM Studio. [LM Link FAQ](https://lmstudio.ai/docs/lmlink/basics/faq). Accessed 30 Sep 2026.
5. Tailscale. [Control and data planes](https://tailscale.com/docs/concepts/control-data-planes). Accessed 30 Sep 2026.
6. Tailscale. [Connection types](https://tailscale.com/docs/reference/connection-types). Accessed 30 Sep 2026.
7. Tailscale. [DERP servers](https://tailscale.com/docs/reference/derp-servers). Accessed 30 Sep 2026.
8. IETF. [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707), 2020.
9. IETF. [RFC 9635: Grant Negotiation and Authorization Protocol](https://www.rfc-editor.org/rfc/rfc9635), 2024.
10. IETF. [RFC 9767: GNAP Resource Server Connections](https://www.rfc-editor.org/rfc/rfc9767), 2025.
11. Model Context Protocol. [Authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization). Accessed 30 Sep 2026.
12. Model Context Protocol. [The 2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/), 28 Jul 2026.
13. NVIDIA. [Bring Your Own Compute to Lepton](https://docs.nvidia.com/dgx-cloud/lepton/guides/nodes/bring-your-own-compute/). Accessed 30 Sep 2026.
14. NVIDIA. [Create BYOC Node Group](https://docs.nvidia.com/dgx-cloud/lepton/compute/bring-your-own-compute/create-byoc/). Accessed 30 Sep 2026.
15. Microsoft. [What is Foundry Local?](https://learn.microsoft.com/en-us/azure/foundry-local/what-is-foundry-local). Accessed 30 Sep 2026.
16. Warp. [Pricing and billing FAQ - custom inference endpoints](https://docs.warp.dev/support-and-community/plans-and-billing/pricing-faqs). Accessed 30 Sep 2026.
17. NVIDIA. [NIM LLM and VLM API reference](https://docs.nvidia.com/nim/large-language-models/latest/thinking-budget-control.html). Accessed 30 Sep 2026.
18. NVIDIA. [NIM tool calling and MCP integration](https://docs.nvidia.com/nim/large-language-models/latest/advanced-use-cases/tool-calling-and-mcp.html). Accessed 30 Sep 2026.
19. Cloudflare. [AI Gateway custom providers](https://developers.cloudflare.com/ai-gateway/configuration/custom-providers/). Accessed 30 Sep 2026.
20. BazaarLink. [Bring your own compute back to your API](https://bazaarlink.ai/en/solutions/byoc). Accessed 30 Sep 2026.
21. QVAC / localhost/AI. [Delegated Inference: Phone Borrows Laptop GPU](https://localhost41.com/articles/qvac-delegated-inference/), 26 Apr 2026.
22. Daniel Asaboro. [Leash](https://github.com/danielAsaboro/Leash). Accessed 30 Sep 2026.
23. Vast.ai. [Rent GPUs](https://vast.ai/). Accessed 30 Sep 2026.
24. Akash Network. [GPU Deployments](https://akash.network/docs/learn/core-concepts/gpu-deployments/). Accessed 30 Sep 2026.