Build with
private intelligence.

Overview

Glow is a thin, authenticated gateway around a curated Venice model catalog. It gives applications a stable Glow model alias, a single API contract, account-level credit controls, and a privacy receipt for each completed request.

• ✓OpenAI-compatible /v1/models and /v1/chat/completions.
• ✓Glow-issued API keys with scopes, revocation, and monthly spend ceilings.
• ✓Optional server-sent event streaming for chat completions.
• ✓Bounded agent runs with a fixed catalog of safe agent identities.
• ✓Prompt and response content is not written to Glow’s database or operational logs.

Quickstart

Generate a key from the API workspace, store it in your server environment, then call the Glow base URL. Keys are shown once; treat them like production credentials.

export GLOW_API_URL="https://api.useglow.ai"
export GLOW_API_KEY="glow_sk_…"

curl "$GLOW_API_URL/v1/chat/completions" \
  -H "Authorization: Bearer $GLOW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glow/fast",
    "messages": [
      {"role": "user", "content": "Give me a concise welcome."}
    ]
  }'

const response = await fetch(`${GLOW_API_URL}/v1/chat/completions`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${GLOW_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "glow/fast",
    messages: [{ role: "user", content: "Hello Glow" }]
  })
});
const completion = await response.json();

Authentication

Send a Glow API key in the standard bearer header on every inference request. Keys use the glow_sk_ prefix. Create and revoke keys from the authenticated dashboard; never commit one to source control, ship one to a browser, or place one in a mobile binary.

Authorization: Bearer glow_sk_your_key_here

Authenticated dashboard sessions may also call the API, but machine integrations should use a dedicated key with its own monthly limit. Invalid, revoked, over-limit, or missing credentials return 401.

List models

Returns the enabled public Glow aliases. Provider model IDs are intentionally not part of the public contract and may change as the catalog evolves.

curl "$GLOW_API_URL/v1/models" \
+  -H "Authorization: Bearer $GLOW_API_KEY"

{
  "object": "list",
  "data": [{
    "id": "glow/fast",
    "object": "model",
    "owned_by": "glow-ai",
    "name": "Glow Fast",
    "description": "Low-latency private intelligence…",
    "privacyClass": "private",
    "inputUsdPerMillion": "0.11",
    "outputUsdPerMillion": "0.44",
    "tags": ["Fast", "Private"]
  }]
}

Current stable aliases are glow/fast, glow/private, and glow/permissive. glow/e2ee is experimental and only appears when the deployment explicitly enables it.

Create a chat completion

Glow accepts a bounded OpenAI-style message list and returns a standard chat completion with a Glow privacy and charge receipt.

Request fields

{
  "model": "glow/private",
  "messages": [
    {"role": "system", "content": "Be precise."},
    {"role": "user", "content": "Summarize this proposal."}
  ],
  "temperature": 0.2,
  "max_tokens": 800
}

{
  "id": "chatcmpl_…",
  "object": "chat.completion",
  "created": 1786000000,
  "model": "glow/private",
  "choices": [{
    "index": 0,
    "message": {"role": "assistant", "content": "…"},
    "finish_reason": "stop"
  }],
  "usage": {"prompt_tokens": 42, "completion_tokens": 81, "total_tokens": 123},
  "glow": {
    "request_id": "req_…",
    "privacy_receipt_id": "prv_…",
    "price_version": "…",
    "charged_usd": "0.0001",
    "server_content_stored": false
  }
}

Stream a completion

Set stream: true to receive text/event-stream. Each event is a JSON chat-completion chunk. The final event contains usage and the Glow receipt, followed by data: [DONE].

curl "$GLOW_API_URL/v1/chat/completions" \
+  -H "Authorization: Bearer $GLOW_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"model":"glow/fast","stream":true,"messages":[{"role":"user","content":"Write a haiku."}]}'

Consume events incrementally, preserve the final usage event, and close the connection after [DONE]. A stream can still incur a charge because usage is recorded for the completed inference.

Run a bounded agent

Agent runs apply a fixed role, capability boundary, privacy policy, and budget check before calling inference. Agents cannot submit transactions or claim live chain access.

{
  "agent_id": "private-researcher",
  "model": "glow/private",
  "message": "Compare these two supplied approaches."
}

The response includes the run ID, agent metadata, completed policy steps, output, usage, and a glow receipt.

Privacy and data

Glow processes prompt and response content in memory to complete inference. The current implementation does not persist chat content, prompt text, response text, or message history in its database or operational logs. Account, API-key, usage, billing, wallet, security, and public blockchain metadata may be retained to operate the service.

• ✓Provider credentials stay server-side.
• ✓Request logs deliberately omit message content.
• ✓Every successful completion includes a privacy receipt ID.
• ✓Browser-saved history is opt-in and local to the device.

Privacy does not make a request safe for every use. Do not send secrets, regulated data, or personal data unless your own legal, contractual, and deployment requirements permit it.

Credits, limits, and receipts

Inference requires a positive Glow account balance. Each successful chat or agent run records token usage, model alias, provider request ID, privacy class, price version, and charge amount. API keys may also have a monthly spend ceiling.

• ✓402 billing_error means the account has insufficient credits or the key has reached its configured limit.
• ✓Charges are calculated from prompt and completion token usage using the active Glow price configuration.
• ✓Payment and token rails are deployment-dependent; clients must read account readiness before presenting checkout as available.

Errors and retries

Errors use a consistent JSON envelope. Do not retry authentication, validation, unknown-model, or insufficient-credit errors without changing the request or credentials.

{
  "error": {
    "message": "Insufficient Glow credits",
    "type": "billing_error"
  }
}

For 502 and transient network failures, retry with exponential backoff and jitter. Use a client-generated idempotency strategy at your application layer; inference requests are not currently idempotent.

Production checklist

• □Keep GLOW_API_KEY in a server-side secret manager.
• □Set a separate key and monthly limit per application or environment.
• □Handle 401, 402, 429/upstream throttling, 502, and 503 explicitly.
• □Redact authorization headers and completion content from your logs.
• □Store request IDs and privacy receipt IDs for support without storing prompts.
• □Pin a Glow alias and review the live model list before deployments.
• □Use HTTPS and validate the TLS certificate; never disable certificate verification.
• □Verify payment contract and treasury configuration before enabling crypto checkout.