Explanation¶
Why the subsystems here are built the way they are: the problem each one solves, the alternatives that were weighed, and the properties the chosen design buys.
These pages give the shape of a design. A single choice, with its drivers and its consequences, is recorded instead in Decisions.
Documents¶
| Document | Summary |
|---|---|
| Kudos accounting, projection, and concurrency | Why kudos movements are recorded as typed events, how the projector materializes them, and how spends stay safe while balances lag. |
| Kudos event retention | Why the kudos event tables keep only an online window, what replaces older rows for each dataset, and what guards each irreversible drop. |
| Request feasibility and queue pressure | Practical guidance for using request progress, worker compatibility, capacity counts, queue estimates, and stall warnings in API clients. |
| Chat requests on the Horde | How chat requests use the text queue, worker capability declarations and a separate OpenAI-compatible front, with the design tradeoffs and client guarantees. |