Developers

Give your application self-evolving long-term memory

Four routes; take the shortest. Already on the OpenAI SDK? Change one base_url. Any other language calls HTTP. Any MCP client pastes a config and reads and writes memory. Extraction, dedup, conflict resolution, validity and the daily tidy-up all happen on our side; your code is left with remember and recall.

Get a key in the console See what it remembers

Five verbs

The whole public surface of the kernel. Not one more, not one fewer.

remember

Write. Conversations, one-line facts, whole documents and device events; when new contradicts old, the old is marked invalid, not deleted.

recall

Retrieve. Several paths searched at once and fused; with explain, every hit says how it was found and whether it still holds.

profile

Profile. Structured slots computed from the facts, plus a narrative; every item opens to its evidence.

forget

Forget. Veto one memory with a reason, reversible; delete a session with cascade; wipe everything with a receipt.

explain

Trace. Which message, model and prompt produced a memory, and what superseded it.

Integrate

The same code as the console quickstart; sign in to copy a version with your key filled in.

Pick a way in. All of them use the same API key and write into the same memory.

Get an API key

Create one under API → Keys. It is shown only once, so save it right away. Create a key →

Install

pip install openai

Call

from openai import OpenAI

client = OpenAI(
    base_url="https://api.reglos.ai/v1",
    api_key="<your API key>",
)

resp = client.chat.completions.create(
    model="gemini-2.5-flash",
    user="alice",  # whose memory this is
    messages=[{"role": "user", "content": "What do I like to do on weekends?"}],
)
print(resp.choices[0].message.content)

If you already use the OpenAI SDK, change base_url and you have long-term memory: each turn recalls first and writes back in the background. The user field decides whose memory it is. If recall times out or fails, the turn falls back to a plain chat instead of failing. Without a model of your own configured, requests go to the server model; set model to gemini-2.5-flash.

Create keys under API → Keys in the console; they are shown once. A server key can read and write any subject — never ship it to a device; devices use device tokens.

Errors and limits

One error shape, {"detail": "…"}: branch on the status code, then on the detail prefix.

Status	When	What to do
400	Request does not make sense: none of the five inputs given, confirm ≠ subject, bad idempotency key	Fix the request; do not retry
401	No key, invalid or disabled key, invalid device token	Use another key; do not retry
403	This key or device token is bound to a different subject	Drop the subject parameter or use the right key
404	Memory / session / document does not exist	Business decision; do not retry
422	Missing parameter, wrong type, too long; detail is a field array	Fix the request; do not retry
429	Per-minute rate limit, or monthly quota exhausted; carries Retry-After	Wait Retry-After seconds; upgrade if the quota is exhausted
5xx	Our fault	Exponential backoff, at most 3 retries

Limits

Rate limit / monthly quota: Configured per API key; one authenticated request = one call, reads and writes alike, never by token; services/quota.py
Request body: ≤ 30 MB; remember:batch ≤ 200 items; observations ≤ 5000 items; gateway + kernel.py
Recall: 45 items by default; a 2.5 s per-query timeout returns the other paths' results with timed_out_paths listed, never a 5xx; recall.py
Sync write: mode=sync takes 5–30 s per conversation; gateway read timeout 300 s; nginx
Idempotency: Idempotency-Key ≤ 128 ASCII chars, kept 7 days; a replay returns the first receipt; idempotency.py
Active keys: At most 5 per account; api_key.py

The full tables (every detail string, the retry matrix, curl and Python examples) live in the repository at docs/API_ERRORS.md and docs/API_LIMITS.md.