Diogenes API

Create a key in Settings → API on diogenes.to. It is shown once; keep it in an environment variable.

export DIOGENES_API_KEY="dgn_..."

curl https://api.diogenes.to/v1/chat/completions \
  -H "Authorization: Bearer $DIOGENES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "Hello"}]}'

The reply comes back in OpenAI's chat.completion shape with one addition, conversation_id. Every request is stored as a chat in your workspace, so it shows in the sidebar and follows your retention, export and delete settings.

Send the key as a bearer token: Authorization: Bearer dgn_…. Diogenes stores only a hash of it.

• A key acts as you: the same models, included usage, credits and spending limit as the app.
• A key reaches all your JARs and personal chats unless you limit it. In Settings → API choose Limit this key to name the JARs it may use and whether it may use personal chats. A request outside that answers 403 forbidden.
• Up to 10 active keys. Revoking one stops it at once.
• Keys are for servers and scripts. The API sends no CORS headers; never put a key in a web page.

GET /v1/models lists the models you can use, their price, and where your prompts are processed.

curl https://api.diogenes.to/v1/models \
  -H "Authorization: Bearer $DIOGENES_API_KEY"

The list also carries image_generation: the picture model and its price per image, or null while pictures are off.

POST /v1/chat/completions takes OpenAI's request body, plus three Diogenes fields.

• system messages are not sent to the model: the Diogenes system prompt applies, as in the app.
• On a new conversation, your earlier user and assistant messages become its stored history.
• Text only: images and files are not accepted over the API.
• Browsing and the sign-in view need the app and are not offered. Link reading, on-chain lookups and pictures follow the same switches as in the app.

{
  "id": "chatcmpl-…",
  "object": "chat.completion",
  "created": 1790330000,
  "model": "qwen3.5-397b-a17b",
  "choices": [
    {
      "index": 0,
      "message": { "role": "assistant", "content": "Hello! …" },
      "finish_reason": "stop"
    }
  ],
  "usage": { "prompt_tokens": 812, "completion_tokens": 64, "total_tokens": 876 },
  "conversation_id": "…"
}

The headers X-Conversation-Id and X-Model-Id carry the same values. The body is written after the reply is stored, so conversation_id always names a conversation that already holds it.

curl https://api.diogenes.to/v1/chat/completions \
  -H "Authorization: Bearer $DIOGENES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"conversation_id": "CONVERSATION_ID",
       "messages": [{"role": "user", "content": "And the week before?"}]}'

With "stream": true the reply arrives as chat.completion.chunk events: first the role, then text deltas, then a closing chunk with finish_reason and usage, and finally data: [DONE].

data: {"object":"chat.completion.chunk","choices":[{"index":0,"delta":{"role":"assistant","content":""},"finish_reason":null}],…}

data: {"object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"Hello"},"finish_reason":null}],…}

data: {"object":"chat.completion.chunk","choices":[{"index":0,"delta":{},"finish_reason":"stop"}],"usage":{"prompt_tokens":812,"completion_tokens":64,"total_tokens":876},…}

data: [DONE]

finish_reason is stop, cancelled when the connection closed, or error. On error the closing chunk also carries error with a code and message.

Pass jar_id to start a conversation inside a JAR you belong to. Replies draw on its Knowledge exactly as a JAR chat does in the app. GET /v1/jars lists the JARs this key can use, with id, name and your role; personal_chats says whether it may also chat outside a JAR.

curl https://api.diogenes.to/v1/jars \
  -H "Authorization: Bearer $DIOGENES_API_KEY"

curl https://api.diogenes.to/v1/chat/completions \
  -H "Authorization: Bearer $DIOGENES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jar_id": "JAR_ID",
       "messages": [{"role": "user", "content": "What changed since last week?"}]}'

• Membership is checked on every reply. Leaving a JAR ends the key's access to it.
• A JAR's owner may keep external models out of it: 403 external_unavailable_in_jar.

Requests are billed exactly like messages in the app. See Models & Credits for the prices.

• included models run on your plan's included usage first; past it, a reply continues on credits only where the app would allow it.
• credits models cost credits_per_1m_in and credits_per_1m_out per million tokens.
• Your monthly spending limit applies to API requests too.
• usage in every response shows the tokens counted.
• When the app would first ask you to choose (a pay-as-you-go price, an external provider, a plan), the API answers with the matching error instead. Make the choice once in the app, then retry.

Errors share one shape and the app's codes:

{ "error": { "code": "forbidden", "message": "This key cannot reach that JAR." } }

• The app's per-minute message limit, shared between the app and your keys.
• Up to 200 messages and 200,000 characters per request; request bodies up to 1 MB.
• Up to 10 active keys; a limited key names up to 20 JARs.