FAQ

LiraLora is a chat-led AI workspace for high-friction creative and production workflows. It is designed to help you move through multi-step work with more continuity, clearer checkpoints, and less tool juggling.

The first public workflow set centers on recurring characters, character LoRA training support, early-reader books, and homeschool-oriented educational content. Those are the starting workflows, not the ceiling: the broader product direction is expanding into adjacent workflow families that benefit from the same memory, learning, and replay model.

No. Educational content is the first strong wedge because it exercises continuity, revision, and reusable assets well. The broader product thesis is a reusable orchestration system for high-friction AI workflows, including creator pipelines, recurring visual identity work, and other continuity-heavy projects.

It is a strong fit for people running local AI, creators producing recurring visual or content work, parents and educators making learning materials, game and world-building teams, and small teams that need shared project continuity instead of scattered notes and prompts.

LiraLora is not meant to be a generic autonomous black box, a thin prompt wrapper, or just another one-shot model shell. The point is guided orchestration with bounded control, visible progress, and replayable refinement.

A workflow is the guided outcome path. Memory preserves meaningful continuity across work. Learning is how the product adapts to preferences and accepted patterns over time. Run families and replay are how you inspect changes and continue honestly from the point where a run diverged.

Your projects and heavy work stay on your machine by default. Optional cloud-backed features are additive. Local-first mode is meant to be a real way to work, not a crippled teaser tier.

Free and local-first modes let you run workflows, use local models, and bring your own provider keys while keeping outputs local. Paid plans add the compounding layer: durable memory, stronger replay continuity, and collaboration features that reduce repeated setup and rework over time.

No. A big part of the product value is flexibility. You can keep some parts local and use cloud services for other parts. For example, you might prefer local LLMs or a local orchestrator, but use cloud infrastructure for heavier jobs like LoRA training when your own hardware is not the right fit.

Memory-backed replay means the product can retain durable context so you can stop, revise, branch, and continue from meaningful checkpoints instead of depending only on the latest prompt or rebuilding the workflow from scratch.

No. Context is useful for the current interaction, but context alone is temporary and easy to overflow, compact, or lose. LiraLora's memory model is about durable continuity over time: preserving what matters long-term and inserting the right context only when it is useful, instead of bloating every step with unnecessary prompt history.

It means the product can reflect the preferences, constraints, and accepted patterns that matter to your workflows over time. That includes getting better at bringing useful context into the right moments of a workflow instead of stuffing everything into every prompt. It is meant to reduce repeated friction and improve continuity, not to act like vague autonomous mind-reading.

It is a meaningful place in a workflow where the product can pause, preserve what was true at that moment, and give you a clean place to refine or branch later. The goal is to make revisions cheaper and clearer.

The product is designed so you can go back to the relevant point, adjust the part that changed, and continue from there instead of throwing away the whole run. That is a big part of the value of replay and run-family structure.

By default, project artifacts and provider traffic stay local to your machine. When you opt into cloud-backed features, only what the product explicitly describes is stored remotely. The product is meant to keep heavy payloads and final outputs primarily under your control.

The main posture is local ownership of outputs and heavy payloads. Remote storage exists to support memory, continuity, billing, and team features where those are enabled. The marketing promise is not “nothing ever leaves your machine,” but rather that the product should be clear and calm about what stays local versus what powers optional remote features.

Yes. That is core to the product story. LiraLora is designed to work with local providers and bring-your-own hosted provider keys instead of forcing everyone into one vendor-controlled stack.

No. The goal is to give your existing setup more structure, continuity, and replayability. If you already run local models or use your own hosted providers, LiraLora is meant to make that work easier to guide, not to erase the setup you already prefer.

Yes. That is one of the biggest design goals. You should be able to get the most out of your local equipment first, then choose cloud models or services only for the parts that are impractical to run locally. That might mean local LLMs, local orchestration, and cloud training, or fully local execution if your hardware supports it.

Billing, organizations, and seats are managed on the web so the desktop app can stay focused on running workflows. You can still work locally without turning on paid features.

Team-oriented plans are meant to give multiple people shared project memory, shared continuity, and shared visibility into runs and outputs. The idea is to help a group work from the same project truth instead of passing context around manually.

The exact operational details depend on the plan and billing implementation as it ships, but the general posture is that free and local-first use should remain genuinely useful while paid features control the durable memory, deeper replay, and collaboration layer. The FAQ and pricing pages should keep clarifying this as billing behavior hardens.

Public sign-up may be paused from time to time. If registration is closed, check with your admin or watch for announcements. Existing users can still log in.

The website currently calls out macOS, Windows, and Linux as target desktop platforms. Release readiness and installer availability vary by platform, and the download page is the place where current release status will be posted.

Not from the public download page yet. That page is where installers and release updates will appear when public builds are available.