Rhylthyme

Name: Rhylthyme
Author: rhylthyme

Real-time multi-track schedules for cooking, lab protocols, events and workouts.

CommunityOnlineNo sign-inGlobalFreeRead-only

What it can do

What data it sees

Do you need an account

No: the server works without sign-in

Real-time multi-track schedules for cooking, lab protocols, events and workouts. Validate and share.

Server tool list (18)

Raw names from tools/list. Only developers need these.

validate_program	Check a Rhylthyme program for structural and scheduling errors BEFORE visualizing or saving it: missing/duplicate ids, dangling afterStep references, dependency cycles, steps that overlap within a track, tasks with no resourceConstraint, unparseable durations, invalid choice references, and schema 0.3.0-alpha `instances`/`replicates` misuse (E_INSTANCES_ON_SINGLE, E_EACH_WITH_REPLICATES, E_EACH_COUNT_MISMATCH, E_INFLIGHT_GT_COUNT, E_INFLIGHT_NO_CHAIN). Every finding has a `code`, a `message` and a `fix` hint — apply the fixes and re-run until `valid` is true. Warnings (e.g. tracks that finish far apart, W_UNBARRIERED_CHAIN) are advisory; `info` notes (I_IMPLICIT_BARRIER: a replicated step referenced without `instances`) suggest making a barrier explicit. Pure computation: no network, no side effects, safe to call repeatedly.
analyze_schedule	Resolve a Rhylthyme program onto the clock and report what the live runner will do: every step's start/end (seconds from start and, if you pass `finishAt` or `startAt`, ISO wall-clock times), total makespan, the critical path, `bindingConstraints` (what gates each critical-path edge — an in-flight cap, a saturated task, an offset, or a plain dependency), resource conflicts tagged `kind: "maxConcurrent"` (more steps claim a task than its maxConcurrent allows) or `kind: "inFlight"` (more instances of a replicated step are between it and its barrier than `replicates.maxInFlight` allows), `inFlight` windows per replicated step, peak concurrency vs. declared actors, and per-track slack (instances get their own sub-track rows, tagged with `parentTrackId` / `instanceOf`). Use it to answer 'when do I start the potatoes so everything is ready at 6pm?' (pass finishAt), to find why a schedule is longer than expected (critical path and binding constraints — e.g. the cooling rack, not the oven), or to check equipment contention before visualizing. Pure computation; also returns validation findings so you can fix problems in the same turn. Analysing against real history. Pass `history` (run records from load_run, or from `rhylthyme runs` on disk) and every step with enough measurements gains `predicted: {seconds, low, high, basis, n}` beside its planned duration, plus top-level `predictedMakespan` and `predictedCriticalPath`. `basis` is `"identical"` (runs of the same program version, environment and variance factors — their median), `"model"` (a per-step regression on the factors that correlate) or `"none"` (no usable measurement). Simpler still: give `program_id` (a UUID from list_my_programs) plus `token` and the tool loads the caller's own recorded runs of that program for you. `useDurations: "predicted"` then recomputes the makespan, itinerary, critical path and conflicts from the predicted durations instead of the authored ones; the default stays `"planned"` so
visualize_schedule	Render a multi-step parallel schedule as a live timeline (cooking, lab protocols, event run-of-show, training). Call this for ANY schedule you produce — imported, catalog match, or built freehand. A schedule belongs in a visualization, never in prose. The program is validated first (same checks as validate_program); invalid programs are refused with fix hints instead of being published. Returns a markdown preview (cover photo if any, equipment list, ingredient list, ASCII Gantt timeline, chronological itinerary, schedule check) and a shareable rhylthyme.com URL with the interactive view.
import_from_source	Import a recipe or lab protocol from an external source into a Rhylthyme program. Sources: spoonacular (recipes, preferred), themealdb (recipes, fallback), protocolsio (lab protocols), cooklang (.cook recipe URL — action must be 'import', query is the URL; GitHub blob URLs are auto-converted), opentrons (Opentrons Protocol API v2 .py — pass URL as query, or paste source via text; action must be 'import'), benchling (the user's connected library). Actions: search (no login needed), import and random (need the user's Rhylthyme token from login). After import, run the returned program through visualize_schedule. Pass `enrich: true` with action='import' to split the import into parallel tracks with cross-track triggers (one model call, capped per day; inferred steps are marked `metadata.inferred`).
import_text	Turn a block of pasted text — a recipe, a lab protocol, a run-of-show, a training plan — into a validated multi-track Rhylthyme program. Use when the user pastes the steps themselves and no structural importer fits (no URL, no supported service, a photo they transcribed, a PDF they copied out of). Runs four model turns server-side: read-back, schema check, step extraction with the exact source span each step came from, then tracks and triggers. Needs the user's Rhylthyme token from login; costs a model call per turn and is capped per day. Returns the program plus a step→span table, so you can show the user which words each step came from and which steps were inferred.
create_environment	Create a Rhylthyme environment definition with resource constraints for a workspace (lab, kitchen, bakery, etc.). Returns environment JSON; copy its resourceConstraints into the program (or reference it by environmentId) before calling visualize_schedule.
login	Sign in to your Rhylthyme account so you can list and save your schedules and import from external sources. Opens a browser page where you log in (Google, Apple, or email). After signing in, copy the token displayed on the page and provide it here. Tokens expire after about an hour; if a later call reports an auth error, call login again for a fresh one.
list_my_programs	List your saved Rhylthyme schedules. Requires a login token from the login tool.
load_program	Load a specific saved program by ID. Returns a markdown summary plus a live-timeline URL.
list_runs	List the recorded executions of one saved program, newest first: when it ran, how it ended, and the actual makespan against the planned one. A run record is written whenever the live timeline is played (or the terminal runner is used); it is what makes the planned durations checkable against reality. Requires a login token; runs are private to whoever ran them.
load_run	Open one recorded execution by run id: planned versus actual start, end and duration for every step, what ended each step (a person, a timer, an abort), time the clock was paused, and the recorded variance factors. Use it to see where a plan drifts from reality. Requires a login token.
calibrate_program	Propose new durations for one of the user's saved programs from its recorded runs, with the evidence. For every non-fixed step with enough runs a person ended by hand: the median becomes the proposed default, the 10th/90th percentiles the proposed min/max, widened so the author's own range is never narrowed. A fixed step that consistently overruns gets a "consider variable" note and no number, because only the author can decide that. The result is a per-step table (n, median, IQR, current, proposed, delta) plus what accepting the lot would do to the makespan and the critical path. It never saves anything: pass `accept` to get the calibrated program back — each changed duration carrying `calibratedFrom` — and then save_program if the user wants it kept. Requires a login token; the runs are private to whoever ran them.
list_public_runs	List the runs other people have contributed for one exact program version: when each ran, how it ended, actual against planned total, and the variance factors that run was recorded with. Contribution is opt-in per run and contributed records carry no user id and no step notes, so this is anonymous, aggregate evidence about how long a program really takes. No login needed. Identify the program either by `program_hash` (`sha256:<hex>`, as `programVersion` in a run record) or by passing the `program` JSON, which is hashed here.
search_public_recipes	Search the public Rhylthyme catalog of cookable recipes, lab protocols, event templates, and workouts. Returns up to 50 matching programs (id, name, description, view URL) — no sign-in required. The catalog is split by environment: pass environment='kitchen' (default), 'laboratory', 'event' or 'gym' to pick the collection. Pass an id to load_public_recipe for the full schedule (its result already includes the live URL).
load_public_recipe	Load a single public recipe / protocol / workout / event template by id. Returns a markdown summary plus a live-timeline URL (no visualize_schedule call needed).
save_program	Save a Rhylthyme program to your account. If a program with the same programId already exists, it will be updated. Requires a login token.
preview_timeline	Render a Rhylthyme program as a static Gantt-chart image so the user can SEE what the live timeline looks like, without committing to opening the live URL. Use this when the user asks for a 'preview' or 'picture' of the timeline, or when you have just built a freehand program and want to give the user a visual before they commit. The tool returns ONLY an image plus a one-line caption — no recipe prose, no ingredient list, no copyright concerns. Just the structural visualization of which step runs when on which track. Pair with visualize_schedule when the user wants the full shareable interactive URL too. This tool is for the visual-only quick preview case. Planned versus actual. Pass `run` — a recorded run of the same program, as load_run returns it in `run` — and the picture becomes a comparison: each step's real bar over a thin ghost bar at its planned position, outlined green where it finished early and amber where it ran late. That is the fastest way to show a person where a plan drifted. Rendering option for HTML-artifact-capable clients (Claude.ai etc.): Claude.ai's artifact sandbox blocks external scripts from non-cdnjs sources, so a `<script src="https://kitchen.rhylthyme.com/...">` tag will fail. To render the timeline yourself with the official Rhylthyme look, call get_renderer_source first to fetch the renderer's full source as a string, then embed that source verbatim inside a `<script>…</script>` block in your HTML artifact, followed by your program JSON and a call to `Rhylthyme.renderTimeline(document.getElementById('t'), program)`. The renderer is open-source (Apache-2.0), zero-dependency, ~9KB.
get_renderer_source	Returns the source code of the open-source Rhylthyme timeline renderer (Apache-2.0, ~9KB, zero dependencies). Use this when you're building an HTML artifact and the artifact sandbox blocks external scripts (e.g., Claude.ai's CSP only allows cdnjs.cloudflare.com). The returned text is plain JavaScript with a UMD wrapper — paste it verbatim inside a `<script>…</script>` block in your artifact, then call `Rhylthyme.renderTimeline(container, program)` where `program` is the Rhylthyme program JSON. After this call, the global `Rhylthyme` object exposes: `renderTimeline(container, program)`, `renderTimelineSvg(program)`, `computeStepTimings(program)`, `parseSeconds(value)` and `stepDurationSeconds(step)`.