moooon
Motir
Vibe the project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.
- Vibe Project
- Open Source
- AI Agent
- AI Loop
- 6
- requests
- 4
- upvotes
- 499
- planned
- 4,801
- shipped
- (motir-core) Two-instance follow-up cases — session signed in on A loads an authed page on B, MCP initialize on A then tools/list and a write on B, a repeated idempotent write or double plan approve applied once, an OAuth or device flow started on A completed on B, a write on B shown on a workbench stream held on Amotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Two-instance limit cases — three `/request-password-reset` calls on A and one on B refuses the fourth, the sign-in bucket likewise, an MCP volume budget spent B−1 on A and 2 on B refuses the last with 429 and the JSON-RPC envelope, and one `/api/v1` budget the samemotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Two-instance CI harness — two production-build `app` servers on one Postgres, a client that sends request N to A and N+1 to B, wired into CI for PRs touching lib/, app/ or server.js, with the scratch-commit control run (a module-level counter used as a limiter turns it red)motir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Move every inventory row classified "moved" to shared state in Postgres — each reads and writes the shared store, and a row whose answer would be wrong rather than stale on another machine is not left per instancemotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Refuse the `memory` rate-limit store on a multi-instance deployment — a startup guard on `MOTIR_RATE_LIMIT_STORE=memory` in a production build, the guard's choice (refuse to start, or a reported error the deploy fails on) namedmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Better-Auth's limiter on shared storage — read the installed version's default storage from node_modules, then move `authOptions.rateLimit` to shared storage so the password-reset and sign-in buckets count once across the fleetmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) In-process state inventory — a ref-stamped `git grep` over lib/, app/ and server.js for module-scope Maps, Sets, lets, globalThis slots, timers and library in-memory defaults, every hit a row or an excluded line with its reason, each classified shared / safe per instance (staleness in seconds) / movedmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- Many concurrent agents per user or workspace are served, not starved — rate limits keyed and sized for agent traffic, enforced the same across every instance, and a refused agent call answers a retryable limit, never a failed job (cf. the ai:internal 30/min per-user bucket, MOTIR-8423)motir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) The workspace ceiling is spent only after the caller's own limb admits — a runaway agent or job refused at its per-agent / per-job budget draws nothing from the shared `agent:workspace` ceiling, on MCP, `/api/v1` and job read-backs, so it cannot starve its workspacemotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) End-to-end — a real `motir run` loop against a local app with the `/api/v1` budget shrunk (`MOTIR_API_V1_RATE_LIMIT`; the CLI is a v1 client, not an MCP one) is refused, prints the wait, carries on, and claims no card twicemotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Story integration gate against real Postgres — 20 agents of one user served with zero refusals (and today's keys refusing them as the control arm), a runaway agent contained at its own budget, the workspace ceiling unwidened by minting, money buckets unchanged, two concurrent jobs' 100 reads/min each served, every refusal machine-retryable; coverage floormotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-ai) Story integration gate — a planning job against a core stub that answers 429 with `retryAfterSeconds` on its first N job-token reads waits, retries and ends `succeeded`; an exhausted bound ends as a rate-limit outcome; coverage floor on the changed clientmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Two-instance enforcement test — two app processes on one database split one agent's MCP calls and refuse at exactly one per-agent budget, not twomotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Job read-backs metered per job — `/api/internal/ai/*` draws a per-job bucket keyed on the token's `jobKey` (600/min, today's per-user `ai:internal` bucket as the fallback for a keyless token) plus the shared workspace ceilingmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-ai) The core client retries every job-token call refused `RATE_LIMITED` after `retryAfterSeconds`, within a bounded total, and an exhausted bound ends the job as a `rate_limited` outcome — never `validation_error` or "could not be read"motir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) The CLI's `/api/v1` transport honours a rate-limit refusal — on a 429 it says it is waiting, waits `retryAfterSeconds`, retries the same call within a bounded total, ends as a `RateLimitError` when the bound runs out, and a retried claim never claims twicemotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Volume per agent, ceiling per workspace — named, env-configurable budgets (600/min per agent, 12 000/min per workspace) with their arithmetic, `mcp:call` keyed on the presented credential's fingerprint plus a workspace-ceiling limb, `/api/v1` gaining the same ceiling, money buckets left per `(workspace, user)`motir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) One retryable refusal contract — every agent-reachable rate-limit refusal (MCP transport 429, billable tool `isError` result, job-token route 429, `/api/v1` 429) carries a numeric `retryAfterSeconds` in a machine-read field plus `Retry-After` on HTTP; code `RATE_LIMITED`, v1 keeping its frozen `RATE_LIMIT_EXCEEDED`motir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) The job token carries a per-job id claim, minted at submission and kept unchanged across `refreshJobToken`, so a job's read-backs can be keyed per job (a token without it falls back to its user key)motir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test
- (motir-core) Limiter inventory — every rate-limit call in motir-core from a ref-stamped `git grep`, each with its caller classes, today's scope, key and budget and its new ones, whether its counter write can run inside a request transaction, and the MOTIR-8423 cause settled against motir-ai's job-token 429 handlingmotir-core's web tier scales horizontally under agent traffic — each added `app` instance adds throughput (~500 req/s per instance, toward ~10k active agents), connections stay bounded, no reader is refreshed, measured first and proven by a re-runnable load test