Skip to content

Recipes ​

A recipe is Echo's automation unit: a name and description, one or more actions, optional graph connections, and one or more ways to trigger it. The embedded workflow body is what executes; the recipe wraps it so it can be listed, published, and installed. You work on recipes in the Recipes window, which opens from the popup's Recipes action.

The usual lifecycle is create or import → configure → connect actions → save → test → trigger → inspect the run.

What a recipe can do ​

A recipe can be triggered in several ways:

  • a primary Trigger phrase plus additional spoken Voice aliases;
  • a global keyboard shortcut bound under Settings → App → General → Keyboard Shortcuts;
  • the post-transcription and History Apply menus when Show in Apply menu is enabled;
  • always-on listening, which hears the trigger phrase in the background;
  • a Test run inside the editor.

Once triggered, a recipe runs its actions in sequence or as a graph: text transformations, LLM prompts, speech output, app control, keystrokes, file operations, HTTP requests, shell commands, and plugins. The generated Action Reference is the contract for every action's fields, permissions, and side effects.

What a recipe cannot do ​

A few hard boundaries are worth knowing before you build:

  • Nothing is preinstalled. Echo currently ships and initializes zero bundled recipes. The active startup creates an empty in-memory default list and does not populate it with bundled content — recipes exist because you created or imported them.
  • Voice triggers need a local model. Always-on listening requires a downloaded, selected speech-to-text model, and no recording happens without one.
  • There is no separate continuous mode. Both voice paths — standard recording and always-on listening — go through the same normalized-prefix matcher and the same Voice Slot parser. The former continuous listener, which had its own exact, contains, and fuzzy matching and no Voice Slots, has been removed from Echo; text that does not start with a trigger phrase stays a regular transcription in standard recording and is simply dropped by always-on listening.
  • Third-party recipes are gated, not trusted. Imported recipes run under a capability review and runtime confirmation prompts; self-authored recipes are trusted by default, so review your own side effects.
  • Editor graphs have structural rules. Outputs are forward-only, ordinary cycles are rejected, and entry points are derived from the graph — see The Recipe Editor.

Network-bound actions (HTTP, downloads, shell, plugins) remain explicit trust boundaries inside an otherwise local run; see Recipe security before processing sensitive text.

Voice triggers and Voice Slots ​

Voice aliases are alternate spoken names for the same recipe. Standard recording with always-on disabled and always-on listening both check enabled recipes in order and accept the first primary phrase or alias that is a normalized prefix of the transcription. These standard recording and always-on paths also parse Voice Slots. Normalization removes accents and punctuation, lowercases the text, and collapses whitespace. Text after the matched prefix becomes the recipe input.

There is no other trigger path: a transcription that does not begin with a trigger phrase or alias is never matched by similarity, and no continuous mode without Voice Slots exists any more.

Voice Slots split the speech after the trigger into named fields that actions can reference as {{field}}. Configure them under Recipe settings → Voice Slots. Each slot has:

  • a field name;
  • one or more keyword delimiters, including multi-word keywords;
  • a type: free-form text, canonicalizing enum, or trailing rest;
  • optional enum options and spoken aliases;
  • an optional default.

Echo finds each slot's earliest keyword, orders matches by their position in the speech, and captures the original text between keyword boundaries. Missing keywords are not fatal; a configured default is inserted when present. Reserved runtime variable names cannot be used as slot fields.

For an enum slot, the spoken value is normalized and checked first against each canonical option, then against that option's aliases. A match returns the canonical value. For example, aliases such as "anglais" and "in English" can both resolve to a canonical value such as English; the action then reads {{language}}.

Continue ​

Released under the MIT License.