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
- 497
- planned
- 4,958
- shipped
- Continue a dead run from your own agent — confirm the continue tools live, then the continue protocol in the runbook (`prompts/continue.md`) and the two-mode `motir-continue` skill on `motir-skills` `main`, CI-aware from the start
- (motir-ai · test) E2E — two planning processes and a stand-in Fly API: a fifth job waits on a full machine, a peer is woken, a "suspended" machine is resumed, an idle one suspends, and the exhausted alert fires onceA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · test) Integration gate — the pool story's coverage floor, slot claims and the scale-out debounce against the real database, and the seams between slots, idle tracking, peer wake and resumeA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) `fly.toml` provisions the pool by suspend — `min_machines_running = 0`, Fly auto-stop off, the private wake port, rewritten scaling comments — and the deploy step starts every machine afterwardsA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) With every running machine 4/4 busy, a queued job resumes exactly one suspended machine — debounced 10 s across the pool, checked at submit, at finish and every 5 s while busy — and with none left raises "planning pool exhausted"A dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) A full machine hands a queued job to an idle running peer — a private wake listener on port 8081, called at submit and at job finish when another running machine has a free slotA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) The planning pool's view of itself — running peers from `vms.motir-ai.internal`, each machine's busy slots from `PlanJob`, and a Machines API client that lists and resumes suspended machinesA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) A planning machine idle for 5 minutes suspends itself — job slots and in-flight HTTP tracked, re-checked at the moment of suspend, through the local `/.fly/api` socketA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) The first database query after a resume reconnects — stale pooled sockets dropped before suspend, and one retry on a connection error at the worker's and submit's first queryA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai) The worker runs up to 4 jobs at once — claim slots instead of the `ticking` single-flight guard, per-job lease renewal, and a drain that waits for every slotA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-ai · research) MEASURE suspend → resume on a real 2 GB motir-ai machine — first response ≤ 1 s and a clean database reconnect, the pool's rollout conditionA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- Planning machines run four sessions each, suspend when idle, and resume in about a second when someone starts planningA dedicated code-graph service serves every tenant's graph reads, so any number of planning sessions read current code and the planning machines hold no graphs
- (motir-gateway) The refresh report, pricecheck and the catalog generator still tell a person to edit a sourced price in `model.go` and its ReadDate in `price_provenance.go`, which no longer hold them
- (motir-gateway) The catalog refresh REMOVES the hand price of a model its provider no longer lists — the refresh PR deletes that id from `provider_direct_prices.json` and names it in the body, instead of the price staying on the books with no check reading it
- (motir-core) The hosted smoke test "a parent, continued" flakes under load: the run's close is sometimes never recorded
- (motir-gateway) The SOURCED provider-direct prices move into a data file the refresh can rewrite — each one's prompt, completion and provenance leave `model.go` / `price_provenance.go` for `relay/billing/ratio/provider_direct_prices.json`, and every charged price stays the same
- (verification) The continue tools are LIVE on app.motir.co — `tools/list` names them, `dispatch_prompt` takes `continueFrom`, and a claim → touch → prompt → close round trip works on a scratch card whose run was killed
- Remove the hand-kept leftovers of RETIRED `deepseek-v4-flash`: its price rows in the gateway and the "fast" planner option in motir-core. The catalog refresh has already stopped routing it
- An agent can add and tick a card's to-do step over the MCP but never delete or edit one — `workItemTodosService.deleteTodo` / `updateTodo` ship with a UI door and no MCP tool
- (motir-meta) `install.sh` and `SKILLS_DRIFT.check.py` read the public skills from the release's `plugins/motir/skills/` via a `skills_dir=` pin key, so motir-meta can pin `v0.4.4`