Open API

May inilalantad ang Reverie na Chat Completions endpoint na compatible sa OpenAI. Ituro rito ang kahit anong OpenAI client, magpasa ng Reverie API key, at gamitin ang field na model para pangalanan ang isang karakter o scenario sa halip na isang LLM. Itinatago ng Reverie sa panig nito ang usapan, ang mga memorya at ang mga buod, kaya ang bago mo lang na mensahe ang kailangan ng bawat request.

Magagamit ito ng kahit anong naka-sign in na account. Walang subscription tier at walang waitlist — API key lang ang kailangan mo. Gumawa ng isa →

Base URL at auth

https://reverie.im/api/device/v1
Authorization: Bearer rk_...

Ipinapakita ng Mga Setting → Higit pa → Mga API Key ang eksaktong base URL sa card na API Endpoint, na may copy button.

Mabilis na pagsisimula

curl --no-buffer https://reverie.im/api/device/v1/chat/completions \
  -H "Authorization: Bearer $REVERIE_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary '{
  "model": "Luna [abc12345]",
  "messages": [
    {
      "role": "user",
      "content": "Hi"
    }
  ],
  "stream": true,
  "temperature": 0.8
}'

May request builder din ang Mga Setting → Higit pa → Mga API Key na bumubuo ng tatlong snippet na ito gamit ang isa sa mga totoo mong key at isang totoong karakter.

Karakter ang pinapangalanan ng field na model

Mga detalyeng nagpapasya kung mare-resolve ang maikling ID:

• Dapat nasa dulo ng string ang [...].
• Ang suffix na 8 character o mas maikli ay itinutugma lang sa mga karakter na may chat ka na, sa web man o sa pamamagitan ng API. Ang maikling ID ng karakter na hindi mo pa nabubuksan ay tahimik na babagsak sa iba.
• Tumatakbo lang ang paghahanap ng scenario kapag naka-pin ang key sa isang karakter. Sa global key, hindi kailanman mare-resolve ang maikling scenario ID.
• Itinuturing na buong ID ang higit sa 8 character.

Paglilista ng mga puwede mong kausapin

curl https://reverie.im/api/device/v1/models \
  -H "Authorization: Bearer $REVERIE_API_KEY"

Ibinabalik ng global key ang mga kamakailan mong karakter. Ang key na naka-pin sa isang karakter ay ibinabalik ang mga scenario ng karakter na iyon, o ang karakter mismo kung wala itong scenario. Ganito ang itsura ng bawat entry:

{
	"id": "Luna [abc12345]",
	"object": "model",
	"created": 1759200000,
	"owned_by": "character",
	"permission": [],
	"root": "<full character id>",
	"parent": null
}

Kopyahin nang direkta ang id sa model. Gumagamit ang mga error mula sa endpoint na ito ng simpleng hugis ng error sa halip na ang OpenAI envelope.

Ano ang binabasa sa request body

Apat na field ang binabasa. Tinatanggap at tahimik na itinatapon ang lahat ng iba pa.

Binabalewala nang walang babala: max_tokens, top_p, n, stop, presence_penalty, frequency_penalty, logit_bias, seed, user, response_format, tools, tool_choice, logprobs, stream_options.

Paano hinahawakan ang messages:

• Inaalis ang mga mensaheng system. Galing sa sariling mga field ng karakter ang persona at pag-uugali, hindi sa request. Mga prompt field →
• Walang suporta sa vision. Puwedeng string o parts array ang content, pero mga text part lang ang binabasa; binabalewala ang mga image part.
• Ang huling mensaheng user lang ang idinadagdag sa usapan. Binabalewala ang mga naunang mensahe ng user.
• Para lang sa history sync ang mga assistant message (tingnan sa ibaba).
• Ibinabalik ang missing_user_message kapag walang laman o puro whitespace ang huling mensahe ng user.

Mga response

Ang non-streaming na response ay karaniwang object na chat.completion. Laging stop ang finish_reason — hindi kailanman inilalantad ang mga internal na tool call — at puro zero ang mga counter ng usage, kaya sukatin ang mga token mula sa mga istatistika ng paggamit sa pahina ng mga API key sa halip na mula sa response.

Ang streaming na response ay text/event-stream:

1. Mga content chunk: mga object na chat.completion.chunk na may delta.content. Walang ipinapadalang paunang chunk na delta: {"role": "assistant"}.
2. Isang finish chunk, na may finish_reason na stop, length o content_filter. Iniuulat bilang stop ang pagtatapos dahil sa tool call.
3. Isang usage chunk na may walang lamang array na choices.
4. data: [DONE].

Kapag pumalya ang pag-generate sa gitna ng stream, maglalabas ang stream ng data: {"error": {...}} at saka [DONE].

Estado ng usapan

Ang Reverie ang nag-iimbak ng usapan. Iisang chat ang umiiral bawat pares ng key at karakter, lumalabas ito sa web app kasama ng iba mo pang mga chat, at binubuo ang bawat turn mula sa system prompt at scenario ng karakter, canon ng World Book, pangmatagalang memorya, mga rolling summary, istilo ng pagsasalaysay ng karakter, haba ng sagot at mga NSFW na setting, isang language lock mula sa locale ng iyong account, at kasindami ng kamakailang history na kakayanin ng context window ng model. Tumatakbo ang mga memory tool kapag sumusuporta sa mga tool ang model.

Dahil ang server ang may hawak ng history, hindi mo na kailangang i-replay ito.

Aling LLM ang sumasagot

Ang karakter ang nagpapasya, hindi ang request — maliban kung magpangalan ka ng LLM. Pagkakasunod-sunod ng prayoridad, mula pinakamababa hanggang pinakamataas: ang default na chat model, saka ang sariling setting ng model ng karakter, saka ang model ID ng Reverie na ipinasa bilang model, at panghuli ang preference ng model bawat chat na itinakda mo sa web app, na nangingibabaw sa lahat. Mga model →

Mga error

Gumagamit ng OpenAI envelope ang mga error mula sa /chat/completions: {"error": {"message", "type", "param": null, "code"}}.

Dalawang kaso ang labas sa envelope na iyon: mga error ng GET /models, at mga request body na tinanggihan ng validation (halimbawa, temperature na lampas sa saklaw) — parehong nagbabalik ng simpleng hugis ng error.

Mga rate limit at quota

Walang rate limit bawat key, walang limitasyon sa sabay-sabay na request at walang request quota sa API na ito. Dalawang bagay ang naglilimita sa paggamit mo:

Kahati ng window ng libreng model ang web chat, mga story, mga nobela at ang mga bot — iisang allowance ito bawat account, hindi isa bawat lugar. Mga libreng model →

Walang ipinapadalang outbound webhook ang Reverie; walang masu-subscribe-an para sa mga completion event.

Pag-import ng mga karakter

Isang ikalawang endpoint, ang POST /api/v1/characters/import, ang gumagawa ng karakter mula sa isang character card. Kailangan nito ng key na may import scope, na hindi ang uri ng key na ginagawa ng pahina ng mga setting. Mga API key → at Mag-import ng mga karakter →

Kaugnay

• Mga API key — gumawa, mag-pin, mag-expire at magbantay ng mga key
• Mga model — mga model ID at credit multiplier
• Mga limitasyon — ang iba pang hangganan sa produkto
• Credits — paano pinepresyuhan ang mga request