GPU rental and inference for agents

Useful today. Not yet hands-off.

Agents with a shell or HTTP tools can already use nafnaf. An operator signs in, authorizes access, and funds an account; software can then rent a GPU or call a hosted text model against that prepaid balance. Those are two separate products: GPU rental gives you a workspace on a provider's hardware, while inference gives you a model response without managing a machine.

Examples, not a sandbox. Public discovery calls are read-only. Inference requests and instance creation below consume real account credit. Provision credentials through your own account, review the budgets, and run paid examples only with the account owner's approval.

There is no single agent standard.

Discovery, tool execution, authorization, and settlement solve different problems. Our recommended stack combines established HTTP interfaces with narrowly delegated permissions; newer payment protocols can sit alongside them.

REST and OpenAPI: the underlying contract

OpenAPI describes HTTP operations, request schemas, responses, and security requirements. That makes it useful for generated clients and agent integrations alike. nafnaf publishes an OpenAPI document, but the audited version does not yet describe bearer authentication or inference request bodies completely. Use the explicit examples here, not an assumption that every generated client will work.

MCP: a tool interface, not a wallet

Model Context Protocol tools give compatible agent clients a discoverable, typed way to call services. A nafnaf adapter could expose offer search, quotes, creation, status, pause, deletion, and usage over the same backend. This is a proposed integration, not an endpoint you can connect to today.

For a remote authenticated MCP server, the current authorization specification uses OAuth 2.1 mechanisms, protected-resource discovery, and tokens intended for that resource. An agent should receive only the permissions it needs. Tool descriptions and approval prompts do not replace server-side authorization or spending controls.

Model compatibility is a separate question

An OpenAI-compatible interface helps integrate a model, but does not imply that every model supports every feature. Even vLLM documents compatibility by endpoint and feature. Check the nafnaf model catalog for each model's current protocols and capabilities.

This category already has real implementations. Runpod offers an MCP server for GPU resources, and Lium documents agent-oriented rental scripting. The opportunity is not to invent agent-accessible GPUs; it is to make compute affordable, interoperable, and predictable to operate.

Give an agent a text-model tool.

Start in Inference, review the current model and token prices, and create an inference API key. Add credit through Billing. Store the key in your runtime's secret store, not in a prompt, repository, browser bundle, or command transcript.

The API base is https://inference.nafnaf.ai/v1. An inference key begins with nf_inf_; it is not a credential for GPU rental or account administration. Fetch the public catalog to inspect available models, pricing, capabilities, and limits:

curl --fail-with-body --silent --show-error \
  https://inference.nafnaf.ai/v1/catalog

The response has an object value of list and a data array of model objects. With jq installed, extract model IDs with jq -r '.data[].id'. An empty array means no model is currently available; do not submit a paid request until the intended model is listed.

The following paid request uses mimo-v2.6-flash for a short streamed answer. NAFNAF_INFERENCE_KEY is an environment variable supplied securely by your runtime.

curl --fail-with-body --no-buffer \
  https://inference.nafnaf.ai/v1/chat/completions \
  -H "Authorization: Bearer $NAFNAF_INFERENCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mimo-v2.6-flash",
    "messages": [{
      "role": "user",
      "content": "Explain when a GPU is useful in three sentences."
    }],
    "max_tokens": 512,
    "stream": true,
    "stream_options": {"include_usage": true}
  }'

Consume the server-sent events incrementally, inspect any error event, and record the final usage: prompt_tokens, completion_tokens, and total_tokens. Completion usage includes reasoning tokens. Do not treat an HTTP 200 or the first streamed text as proof that the request has finished successfully.

• Set an output budget. Limits differ by model. Review the catalog and choose the request's output allowance before submitting it.
• Bound concurrency. Current account limits are 15 in-flight requests, 120 requests per minute, and 500,000 combined tokens per minute. Handle rate or capacity rejection with bounded backoff, not an endless retry loop.
• Treat retries as new generations. A transport retry can create another paid request, so retry only when your application intends another generation.
• Disconnection is not cancellation. Closing the stream does not stop admitted generation or its billing. Choose the output limit before submitting the request.

Rent, monitor, and release a GPU.

The nafnaf CLI is the practical starting point for an agent with shell access. Its official installer runs without administrator access; Python 3.9 or newer is required, plus OpenSSH for SSH access. Inspect the installer before running it, then authorize the login as the account owner:

curl --fail --silent --show-error --location \
  https://api.nafnaf.ai/v1/cli/install -o nafnaf-install.sh
less nafnaf-install.sh
bash nafnaf-install.sh
export PATH="$HOME/.local/bin:$PATH"
nafnaf --version
nafnaf login
nafnaf whoami --raw

On a remote machine, use nafnaf login --no-browser and open the displayed authorization link in your own browser. The CLI stores its credential locally; it does not export NAFNAF_CLI_TOKEN for the REST examples. A rental credential begins with nf_cli_. Unlike an inference key, it grants broad account access; it currently has no per-key scope, expiry, or spend cap. Keep it behind a trusted tool runner instead of exposing it to model-generated shell commands without restrictions.

nafnaf search offers "RTX 4090" --raw

Public offers can be read without a key. Select a per-GPU offer ID, not a host name, and inspect the renter price, booking window, storage and transfer terms, and compatible workload templates:

curl --fail-with-body --silent --show-error \
  https://api.nafnaf.ai/v1/offers

# Set OFFER_ID to a reviewed offer from that response.
curl --fail-with-body --silent --show-error --get \
  https://api.nafnaf.ai/v1/workload-templates \
  --data-urlencode "offer_id=$OFFER_ID"

After login and funding, create a one-hour SSH rental with explicit storage and transfer budgets. This example asks you to confirm the fetched terms interactively. These are example allowances, not a universal price quote; the offer must support them, and the storage budget must cover its required minimum.

nafnaf create instance "$OFFER_ID" --ssh --hours 1 \
  --storage-gb 100 \
  --storage-budget-usd 1 \
  --transfer-budget-usd 1 \
  --raw

Non-interactive creation requires --yes, which accepts the freshly fetched terms without a prompt. The CLI has no maximum-price flag: an earlier offer inspection is not a guaranteed price cap. For unattended booking, use the REST API with an owner-approved expected price and terms ID, rejecting changed terms instead of silently accepting them. The storage and transfer budgets do not include the GPU compute charge.

1. Inspect and authorize. Compare the current rate and terms with an owner-approved maximum price, GPU count, and duration. Reject a changed or incompatible offer.
2. Create once, then track the ID. Save the returned instance ID outside the model's context. Rental creation does not currently support an idempotency key; a timeout must trigger reconciliation, not an automatic second rental.
3. Wait for readiness. Poll GET /v1/instances with the rental credential and inspect GET /v1/instances/INSTANCE_ID/logs if startup fails. Use the returned connection details once the workspace is ready.
4. Collect results before teardown. Stop compute with the pause operation if files are still needed. After exporting results and confirming deletion, destroy the instance. Treat deletion as a distinct, explicitly authorized action.

Set INSTANCE_ID to the ID returned by creation. Read status and startup logs; repeat status checks with a bounded polling deadline rather than issuing another creation request. SSH waits up to 180 seconds for readiness:

nafnaf show instances --raw
nafnaf logs "$INSTANCE_ID"
nafnaf ssh "$INSTANCE_ID" --wait 180

To stop compute while retaining files, request a pause and poll until it is confirmed. Resume later with nafnaf resume instance "$INSTANCE_ID" --raw, provided the GPU is available and the original rental term has not expired.

nafnaf pause instance "$INSTANCE_ID" --raw
nafnaf show instances --raw

Paused does not mean free. Storage continues to be billed while paused, and pausing does not extend the agreed compute deadline. If storage funding or its budget runs out, the rental has a total 72-hour recovery allowance before files become eligible for permanent deletion; top-ups do not reset time already used. Workspace storage is not a backup. A transfer budget limits charges and requests a pause, but is not a hard network-byte cutoff. DELETE /v1/instances/INSTANCE_ID permanently destroys workspace files.

Only after exporting results and receiving explicit permission to delete the files, permanently destroy the workspace:

nafnaf destroy instance "$INSTANCE_ID" --yes --raw

For a direct REST integration, POST /v1/instances requires the reviewed terms ID, storage policy, allowance and budget, transfer policy and budget, and retention acceptance for paid rentals. Also supply the expected price and pricing policy as additional price guards. Fetch current values instead of hardcoding policy identifiers.

Pay from a funded account today.

nafnaf currently uses prepaid credit. A person adds funds through Stripe-hosted checkout; API usage then consumes that balance. The backend checks funds and reserves credit when admitting work. This supports automated usage after funding, not fully autonomous funding or a separate wallet per agent.

curl --fail-with-body --silent --show-error \
  https://api.nafnaf.ai/v1/billing \
  -H "Authorization: Bearer $NAFNAF_CLI_TOKEN"

For a custom integration, POST /v1/billing/checkout accepts an allowed amount_cents and a UUID request_id, then returns a Stripe checkout URL and an order ID. Current credit packs are $25, $50, and $100; read the billing response for the permitted amounts. Reuse the same request ID if checkout creation needs a retry.

Present the checkout URL to the account owner to complete payment and any card authentication. Only trust the backend's verified payment confirmation and updated balance, never a browser redirect alone. There is no automatic recharge or nafnaf crypto-payment endpoint today. Do not give an agent raw card details or a Stripe secret key.

How autonomous funding could work

The payment ecosystem now offers several complementary options. None of the following is implemented on nafnaf yet:

Our recommended first experiment is Stripe MPP with Shared Payment Tokens: limited payment grants rather than reusable card credentials. The owner would authorize a seller, amount, currency, and expiry. Switzerland is listed for seller support, but preview APIs and account eligibility still need validation.

Stripe's machine-payment documentation sets a $0.50 minimum for card payments through those tokens and a 0.01 USDC stablecoin settlement minimum. Buying credit or accumulating metered usage therefore makes more sense than a card transaction for each tiny completion. Non-US businesses must request access for Stripe's stablecoin machine payments; an existing Stripe account is not sufficient evidence of approval.

Payment authorization and compute authorization must remain separate. Permission to top up $25 is not permission to rent an unbounded fleet. Likewise, x402 payment verification does not itself enforce an agent's total task budget. Lium already documents stablecoin CLI top-ups, so this is an emerging operational pattern, not a first-of-its-kind claim.

The next step is bounded autonomy.

This is our recommended implementation order, not a list of shipped features or a delivery commitment:

1. Complete the API contract. Document bearer authentication, inference request schemas, structured errors, exact model capabilities, and the full rental lifecycle in OpenAPI. Keep machine-readable discovery and runnable examples synchronized.
2. Add a real delegation boundary. Issue revocable, expiring, scoped agent credentials. Enforce account and per-agent budgets across concurrent reservations, compute, storage, transfer, and inference. Keep funding and destructive actions separately authorized.
3. Make retries safe before making them autonomous. Add idempotent rental creation and persistent operation IDs. Provide receipts and reconciliation so a lost response cannot silently become a second charge or a second GPU.
4. Expose a small MCP toolset. Reuse backend checks for search, quote, create, inspect, pause, delete, and usage. Keep model-visible descriptions untrusted and validate every tool argument in deterministic code.
5. Pilot bounded agent payments. Start in the processor sandbox with owner-approved credit purchases. Verify eligibility, refunds, replay protection, receipts, and failure recovery before enabling live machine payments.

The useful promise is simple: an agent can finish its task without being given unlimited access to your account. Today, use nafnaf through a trusted CLI or HTTP runner with human-approved funding and conservative limits. The standards above describe how to make that experience more portable and less dependent on supervision.

Browse GPUs or open Inference to start with an operator-approved workflow.