FAQ

LiraLora is a local-first desktop workflow app for AI work that needs more structure than a single prompt. It combines provider choice, run control, reviewable memory, and replay-oriented workflow history so longer AI projects are easier to inspect and continue.

The private desktop build includes project selection, provider settings, image workflows, memory review, manual memory management, music draft planning, custom workflow surfaces, coding-assistant flows, and an AI Run Control Center for active and recent runs. Public installer release is tracked separately on the Download page.

It is the desktop surface for active and recent AI work. It shows run progress, provider/model choice, memory traces, background runs, cancellation controls, notes, likes, and save-as-memory actions where a completed result supports them.

Private-preview surfaces include image planning and generation, music draft planning, memory curation, provider setup, custom workflows, chat/general work, and coding-assistant workflows through approved local workspaces. Some areas are more mature than others, and public availability is tracked through the roadmap and download pages.

LiraLora is not meant to be a generic autonomous black box, a thin prompt wrapper, or a one-shot model shell. The product is focused on guided workflows with visible progress, reviewable continuity, provider choice, and replayable refinement.

A workflow is the guided execution path. Memory is reviewed continuity that can affect later runs. Learning is the product direction around reflecting approved preferences and useful patterns over time. Run families and replay are the lineage model for understanding where outputs came from and continuing from the point where a run changed.

Local-first means local models, local provider endpoints, and local workflow execution remain central to the product. Account-backed and cloud-backed features are additive rather than the only way to use the app.

The product direction is that local workflows, local providers, and bring-your-own endpoints should remain useful without forcing every run through hosted usage. Paid plans are intended to add deeper account-backed continuity such as memory, run history, replay durability, and collaboration. Exact paid entitlements remain pending until checkout and account surfaces are live.

No. LiraLora is designed for mixed execution. You might run local LLMs and local image tools for most work, use your own compatible endpoints for specific workflows, and reserve cloud or offloaded work for tasks that are impractical on your hardware.

Memory-backed replay means approved context and run history can help future runs explain what was applied and where a result came from. The private app exposes memory candidates, approved memory, run history, workflow steps, and memory traces; richer replay polish continues to evolve.

Workflow output can create reviewable memory candidates. Candidates stay pending until a user approves them. Users can also reject or dismiss candidates, and approved memory can be archived or disabled so it stops influencing future runs.

Yes in the desktop memory surface. You can create memory manually, search existing memory, archive or disable approved memory, restore archived memory, and use explicit confirmation where permanent deletion is available.

LiraLora keeps memory scoped to the kind of work it helps: project context, images, music, coding, chat, and system-level workflow behavior. Memory traces help show when relevant memory affected a run instead of treating everything as one hidden global prompt.

No. Context is useful for the current interaction, but context alone is temporary and easy to overflow, compact, or lose. LiraLora memory is about durable continuity over time: preserving what matters and retrieving the right context only when it helps.

It means the product can reflect reviewed preferences, constraints, and useful patterns over time. The goal is to reduce repeated setup and improve continuity, not to guess from an opaque profile or act like a mind-reading system.

It is a meaningful place in a workflow where the product can preserve what was true at that moment and give you a cleaner place to refine, branch, or continue later.

The product direction is to let you return to the relevant point, adjust the part that changed, and continue from there instead of throwing away the entire run.

The desktop app stores local configuration and local workflow state on your machine. When account-backed features are configured, project access, memory, and durable run history may use the product API. Provider traffic goes to the provider endpoint you configure. The product should stay clear about which parts are local, API-backed, or provider-bound.

The product posture is local ownership where practical, especially for heavy workflow payloads and local provider execution. Remote storage may support memory, continuity, billing, and collaboration where those features are enabled. The promise is not that nothing ever leaves your machine; the promise is that local, API-backed, and provider-bound behavior should be clear.

Private desktop builds support OpenAI-compatible LLM endpoints, local/Ollama-style model servers, ComfyUI image provider configuration, and local Codex CLI integration for approved workspace workflows.

Yes, where the endpoint exposes compatible models and the selected model can do the job the workflow needs. Different workflow steps may use different configured providers.

No. LiraLora is meant to give your existing setup more structure, continuity, and replayability. If you already run local models or use your own hosted endpoints, the product is designed to help you steer that work instead of replacing the setup you prefer.

Yes. That is one of the core design goals. You should be able to use local hardware where it fits, then choose cloud models or offloaded services only for workloads that benefit from them.

Accounts are intended for product surfaces such as billing, organizations, seats, account-backed memory, and durable continuity. The desktop app remains focused on running workflows and managing local provider configuration.

Project access and account boundaries exist as part of the product foundation. Team-oriented plans are intended to build on that with shared project memory, shared continuity, and shared visibility. Full collaboration polish is not yet generally available.

The exact operational details depend on the plan and billing implementation as it ships. The intended posture is that local-first use remains useful while paid features control deeper continuity, replay, account-backed history, and collaboration.

Public sign-up may be paused while release packaging and account surfaces mature. Existing users can still log in where access has been enabled.

macOS, Windows, and Linux are target desktop platforms. Release readiness and installer availability may vary by platform, and the Download page is where current release status will be posted.

Not from the public download page yet. Private desktop builds are being tested, but public installers remain gated on packaging, code signing, auto-update, release notes, and platform QA.

In private desktop builds, coding-assistant workflows run through the local Codex CLI and approved local workspace roots. Ask, analyze, and edit-style flows are part of the private-build direction, with public availability tracked separately.

Public installers, full billing availability, stronger team collaboration, real audio-generation providers, richer replay UX, broader workflow packs, and selective cloud offload remain private preview, release polish, or roadmap depending on the area.