Memory that scales
with your agents.

One write per 6,000 characters of text you store: an add() call (POST /v1/memories), one item of a batch import, or an edit of a memory (PATCH), because it runs extraction again. A memory up to 6,000 characters is one write, however many typed facts Korely extracts from it: a whole 20-message conversation usually is. A longer one counts one write per 6,000 characters of its text, rounded up; the longest the API takes, 16,000 characters, is 3. The engine may make more extraction calls than that, because its reading windows overlap; you pay only the writes. A direct fact write (POST /v1/facts) or a fact correction is one write. Deletes do not count. The dashboard shows the count in real time.

One read call that returns stored data: GET /v1/memories (a list, a single memory or its history), POST /v1/memories/search, GET /v1/context, GET /v1/facts, GET /v1/profile, GET /v1/users, GET /v1/agents, GET /v1/events, or the equivalent SDK methods (korely.search(), korely.get_context(), korely.get_facts()). GET /v1/audit and the status of a batch import do not count. Writes (POST /v1/memories, POST /v1/facts, each item of POST /v1/batch, and edits with PATCH) count against the writes quota, not queries; deletes count against neither. Reads are retrieval, not generation: no generative model runs on the read path, which is why read quotas are an order of magnitude more generous than write quotas. The monthly counter resets the 1st of every month at UTC midnight.

No. An agent is a namespace for one of YOUR agent applications: your support chatbot is one agent, your sales copilot is another. The end users those agents serve are unlimited on every tier. Each memory and query is scoped to an end user via user_id, so a single support-bot agent can remember thousands of distinct customers. A user_id is just a label. An app with 10 users and one with 100,000 making the same API calls pay the same. What counts against quotas is total volume: writes and queries made.

You get a 10% grace above the plan figure. Past that, writes answer 429 quota_exceeded until the month resets, you top up or you upgrade, and nothing is written in the meantime; reads past the queries quota answer the same 429 until the month resets or you upgrade. A quota.warning webhook fires once at 80% of the monthly writes quota, so you can decide whether to top up, upgrade or trim before you hit the wall. The per-minute, per-hour and per-day rate limits are a separate 429 (rate_limit_exceeded, with Retry-After). We never auto-upgrade and we never bill overage.

Yes, on Developer, Team and Scale. From the Usage page of the dashboard you add 1,000 writes to the current month with one payment of 10 euro (or 10 dollars, or 10 pounds), plus VAT, once a month. The writes are for that month and end with it. It is there for the busy month; if every month runs over, move to the next plan.

Yes, and it is a product rather than an exception. You get the same engine on your own machine: Docker Compose, your Postgres, your model provider account, and a dashboard served by the install itself. The four public tiers stay hosted; self-hosting is the fifth column above, and it starts with a call.

On the public tiers, your data is stored in our EU cloud (Helsinki, Finland). The model step on a write runs in the region you pick for each project: Europe keeps it in the EU (Scaleway), Global uses Google Gemini; both providers are sub-processors under a data processing agreement. You can erase everything about one user with one call. Self-hosted, it is your database on your machine and nothing reaches us at all. Extraction still calls a model, and you pick which and whose: Google, Mistral, or anything speaking the same API on your own network.

The audit log is on every plan, Hobby included: GET /v1/audit (or audit() in the SDK) says who wrote each memory and what an agent read when it decided, with ids and counts, never content. On-prem comes with the Self-hosted plan. On the Cloud, a data processing agreement covers every account that stores personal data: ask for it at [email protected]. SSO is available on Self-hosted: your own gateway authenticates your people and passes the result to the dashboard in a trusted header, so your identity provider decides. The Cloud has no customer SSO: people sign in to the dashboard with Google, Microsoft, GitHub, or email and password. What we do not offer is a standing SLA, because at our size that would be a promise about my nights rather than about the software; if you need one, we agree it in the call.