diff --git a/AIChat-Migration.md b/AIChat-Migration.md index 0948d48..868b67e 100644 --- a/AIChat-Migration.md +++ b/AIChat-Migration.md @@ -1,17 +1,17 @@ -Loki originally started as a fork of AIChat but has since evolved into its own separate project with separate goals. +Coyote originally started as a fork of AIChat but has since evolved into its own separate project with separate goals. -As a result, there's some changes you'll need to make to your AIChat configuration to be able to use Loki. +As a result, there's some changes you'll need to make to your AIChat configuration to be able to use Coyote. -Be sure you've run `loki` at least once so that the Loki configuration directory and subdirectories exist and is +Be sure you've run `coyote` at least once so that the Coyote configuration directory and subdirectories exist and is populated with the built-in defaults. # Global Configuration File -You should be able to copy/paste your AIChat configuration file into your Loki configuration directory. Since the -location of the Loki configuration directory varies between systems, you can use the following command to locate your +You should be able to copy/paste your AIChat configuration file into your Coyote configuration directory. Since the +location of the Coyote configuration directory varies between systems, you can use the following command to locate your config directory: ```shell -loki --info | grep 'config_dir' | awk '{print $2}' +coyote --info | grep 'config_dir' | awk '{print $2}' ``` Then, you'll need to make the following changes: @@ -27,7 +27,7 @@ Then, you'll need to make the following changes: Locate your `roles` directory using the following command: ```shell -loki --info | grep 'roles_dir' | awk '{print $2}' +coyote --info | grep 'roles_dir' | awk '{print $2}' ``` Update any roles that have `use_tools` to `enabled_tools`. @@ -36,7 +36,7 @@ Update any roles that have `use_tools` to `enabled_tools`. Locate your `sessions` directory using the following command: ```shell -loki --info | grep 'sessions_dir' | awk '{print $2}' +coyote --info | grep 'sessions_dir' | awk '{print $2}' ``` Update the following settings: @@ -48,27 +48,27 @@ Update the following settings: --- # LLM Functions Changes -Probably the most significant difference between AIChat and Loki is how tools are handled. So if you cloned the +Probably the most significant difference between AIChat and Coyote is how tools are handled. So if you cloned the [llm-functions](https://github.com/sigoden/llm-functions) repo, you'll need to make the following changes. -**Note: JavaScript functions are not supported in Loki.** +**Note: JavaScript functions are not supported in Coyote.** The following guide assumes you're using the `llm-functions` repository as your base for custom functions, and thus follows that directory structure. ## Agents -Agents are now all handled in one place: the `agents` directory (`/agents`): +Agents are now all handled in one place: the `agents` directory (`/agents`): ```shell -loki --info | grep 'agents_dir' | awk '{print $2}' +coyote --info | grep 'agents_dir' | awk '{print $2}' ``` And instead of separate `index.yaml` and `config.yaml` files, they're now both in a single `config.yaml` file. -So now for all of your agents, copy all the contents of those directories to the corresponding directory in the Loki +So now for all of your agents, copy all the contents of those directories to the corresponding directory in the Coyote `agents` directory. Then make the following changes: -* Copy the contents of your `/functions/agents` directory into `/functions/agents` directory into `/agents//tools.txt` -* No `/agents//index.yaml` +* No `functions/agents.txt` file (Coyote assumes that if the agent directory exists, it is loadable) +* No `/agents//tools.txt` +* No `/agents//index.yaml` ## Functions -Loki consolidates much of the `llm-functions` repo functionality into one binary. So this means +Coyote consolidates much of the `llm-functions` repo functionality into one binary. So this means * There's no need to have `argc` installed anymore * No separate repository to manage @@ -142,10 +142,10 @@ Loki consolidates much of the `llm-functions` repo functionality into one binary * No `functions/mcp` directory at all * No `functions/scripts` -Here's how to migrate your functions over to Loki from the `llm-functions` repository. +Here's how to migrate your functions over to Coyote from the `llm-functions` repository. -* Copy your AIChat `/functions` directory into your Loki config directory -* Delete the following files and directories from your `/functions` directory: +* Copy your AIChat `/functions` directory into your Coyote config directory +* Delete the following files and directories from your `/functions` directory: * `scripts/` * `agents.txt` * `functions.json` @@ -163,7 +163,7 @@ Here's how to migrate your functions over to Loki from the `llm-functions` repos #execute_py_code.py query_jira_issues.sh ``` - becomes the following in your `/config.yaml` + becomes the following in your `/config.yaml` ```yaml visible_tools: - get_current_weather.sh @@ -207,4 +207,4 @@ Here's how to migrate your functions over to Loki from the `llm-functions` repos ``` Refer to the [custom bash tools docs](Custom-Bash-Tools) to learn how to compile and test bash -tools in Loki without needing to use `argc`. +tools in Coyote without needing to use `argc`. diff --git a/Agents.md b/Agents.md index 3e062d1..ce73749 100644 --- a/Agents.md +++ b/Agents.md @@ -1,4 +1,4 @@ -Agents in Loki follow the same style as OpenAI's GPTs. They consist of 3 parts: +Agents in Coyote follow the same style as OpenAI's GPTs. They consist of 3 parts: * [Role](Roles) - Tell the LLM how to behave * [RAG](RAG) - Pre-built knowledge bases specifically for the agent @@ -12,14 +12,14 @@ Agents in Loki follow the same style as OpenAI's GPTs. They consist of 3 parts: ![Agent example](./images/agents/sql.gif) -Agent configuration files are stored in the `agents` subdirectory of your Loki configuration directory. The location of +Agent configuration files are stored in the `agents` subdirectory of your Coyote configuration directory. The location of this directory varies between systems so you can use the following command to locate yours: ```shell -loki --info | grep 'agents_dir' | awk '{print $2}' +coyote --info | grep 'agents_dir' | awk '{print $2}' ``` -If you're looking for more example agents, refer to the [built-in agents](https://github.com/Dark-Alex-17/loki/blob/main/assets/agents). +If you're looking for more example agents, refer to the [built-in agents](https://github.com/Dark-Alex-17/coyote/blob/main/assets/agents). --- @@ -27,7 +27,7 @@ If you're looking for more example agents, refer to the [built-in agents](https: Agent configurations often have the following directory structure: ``` -/agents +/agents └── my-agent ├── config.yaml ├── tools.sh @@ -40,7 +40,7 @@ Agent configurations often have the following directory structure: This means that agent configurations often are only two files: the agent configuration file (`config.yaml`), and the tool definitions (`agents/my-agent/tools.sh`, `tools.py`, or `tools.ts`). -To see a full example configuration file, refer to the [example agent config file](https://github.com/Dark-Alex-17/loki/blob/main/config.agent.example.yaml). +To see a full example configuration file, refer to the [example agent config file](https://github.com/Dark-Alex-17/coyote/blob/main/config.agent.example.yaml). The best way to understand how an agent is built is to go step by step in the following manner: @@ -62,7 +62,7 @@ description: # Description of the agent, used in the UI version: 1 # Version of the agent # Function Calling Configuration mcp_servers: # Optional list of MCP servers that the agent utilizes - - github # Corresponds to the name of an MCP server in the `/functions/mcp.json` file + - github # Corresponds to the name of an MCP server in the `/functions/mcp.json` file global_tools: # Optional list of additional global tools to enable for the agent; i.e. not tools specific to the agent - web_search - fs @@ -93,7 +93,7 @@ And if you don't define a `agents/my-agent/tools.sh`, `agents/my-agent/tools.py` You'll notice there are no settings for agent-specific tooling. This is because they are handled separately and automatically. See the [Building Tools for Agents](#4-building-tools-for-agents) section below for more information. -To see a full example configuration file, refer to the [example agent config file](https://github.com/Dark-Alex-17/loki/blob/main/config.agent.example.yaml). +To see a full example configuration file, refer to the [example agent config file](https://github.com/Dark-Alex-17/coyote/blob/main/config.agent.example.yaml). # 2. Define the Instructions At their heart, agents function similarly to roles in that they tell the model how to behave. Agent configuration files @@ -106,7 +106,7 @@ variables: # An array of optional variables that the agent expect ``` ## Static Instructions -By default, Loki agents use statically defined instructions. Think of them as being identical to the instructions for a +By default, Coyote agents use statically defined instructions. Think of them as being identical to the instructions for a [role](Roles#instructions), because they virtually are. **Example:** @@ -117,10 +117,10 @@ instructions: | Just like roles, agents support variable interpolation at runtime. There's two types of variables that can be interpolated into the instructions at runtime: special variables (like roles have), and user-defined variables. Just -like roles, variables are interpolated into your instructions anywhere Loki sees the `{{variable}}` syntax. +like roles, variables are interpolated into your instructions anywhere Coyote sees the `{{variable}}` syntax. ### Special Variables -The following special variables are provided by Loki at runtime and can be injected into your agent's instructions: +The following special variables are provided by Coyote at runtime and can be injected into your agent's instructions: | Name | Description | Example | |-----------------|---------------------------------------------------------------------|----------------------------| @@ -176,8 +176,8 @@ variables: ``` ## Dynamic Instructions -Sometimes you may find it useful to dynamically generate instructions on startup. Whether that be via a call to Loki -itself to generate them, or by some other means. Loki supports this type of behavior using a special function defined +Sometimes you may find it useful to dynamically generate instructions on startup. Whether that be via a call to Coyote +itself to generate them, or by some other means. Coyote supports this type of behavior using a special function defined in your `agents/my-agent/tools.py`, `agents/my-agent/tools.sh`, or `agents/my-agent/tools.ts`. **Example: Instructions for a JSON-reader agent that specializes on each JSON input it receives** @@ -296,11 +296,11 @@ configuration file: documents: - https://www.ohdsi.org/data-standardization/ - https://github.com/OHDSI/Vocabulary-v5.0/wiki/** - - OMOPCDM_ddl.sql # Relative path to agent (i.e. file lives at '/agents/my-agent/OMOPCDM_ddl.sql') + - OMOPCDM_ddl.sql # Relative path to agent (i.e. file lives at '/agents/my-agent/OMOPCDM_ddl.sql') ``` These documents use the same syntax as those you'd define when constructing RAG normally. To see all the available types -of documents that Loki supports and how to use custom document loaders, refer to the [RAG documentation](RAG#supported-document-sources). +of documents that Coyote supports and how to use custom document loaders, refer to the [RAG documentation](RAG#supported-document-sources). Anytime your agent starts up, it will automatically be using the RAG you've defined here. @@ -310,16 +310,16 @@ defining a single function that gets executed at runtime (e.g. `main` for bash t tools define a number of *subcommands*. ## Limitations -You can only utilize one of: a bash-based `/agents/my-agent/tools.sh`, a Python-based -`/agents/my-agent/tools.py`, or a TypeScript-based `/agents/my-agent/tools.ts`. +You can only utilize one of: a bash-based `/agents/my-agent/tools.sh`, a Python-based +`/agents/my-agent/tools.py`, or a TypeScript-based `/agents/my-agent/tools.ts`. However, if it's easier to achieve a task in one language vs the other, you're free to define other scripts in your agent's configuration directory and reference them from the main -tools file. **Any scripts *not* named `tools.{py,sh,ts}` will not be picked up by Loki's compiler**, meaning they +tools file. **Any scripts *not* named `tools.{py,sh,ts}` will not be picked up by Coyote's compiler**, meaning they can be used like any other set of scripts. It's important to keep in mind the following: -* **Do not give agents the same name as an executable**. Loki compiles the tools for each agent into a binary that it +* **Do not give agents the same name as an executable**. Coyote compiles the tools for each agent into a binary that it temporarily places on your path during execution. If you have a binary with the same name as your agent, then your shell may execute the existing binary instead of your agent's tools * **`LLM_ROOT_DIR` points to the agent's configuration directory**. This is where agents differ slightly from normal @@ -328,7 +328,7 @@ It's important to keep in mind the following: miscellaneous files ## .env File Support -When Loki loads an agent, it will also search the agent's configuration directory for a `.env` file. If found, all +When Coyote loads an agent, it will also search the agent's configuration directory for a `.env` file. If found, all environment variables defined in the file will be made available to the agent's tools. ## Python-Based Agent Tools @@ -357,7 +357,7 @@ def get_ip_address_from_aws(): return data.decode('utf-8') ``` -Loki automatically compiles these as separate functions for the LLM to call. No extra work is needed. Just make sure you +Coyote automatically compiles these as separate functions for the LLM to call. No extra work is needed. Just make sure you follow all the same steps to define each function as you would when creating custom Python tools. For more information on how to build tools in Python, refer to the [custom Python tools documentation](Custom-Tools#custom-python-based-tools) @@ -387,7 +387,7 @@ get_ip_address_from_aws() { ``` To compile the script so it's executable and testable: ```bash -$ loki --build-tools +$ coyote --build-tools ``` Then you can execute your script (assuming your current working directory is `agents/my-agent`): @@ -432,7 +432,7 @@ function formatResponse(data: string): string { } ``` -Loki automatically compiles each exported function as a separate tool for the LLM to call. Just make sure you +Coyote automatically compiles each exported function as a separate tool for the LLM to call. Just make sure you follow the same JSDoc and parameter conventions as you would when creating custom TypeScript tools. TypeScript agent tools also support dynamic instructions via an exported `_instructions()` function: @@ -472,7 +472,7 @@ conversation_starters: # 6. Todo System & Auto-Continuation -Loki includes a built-in task tracking system designed to improve the reliability of LLM interactions, especially +Coyote includes a built-in task tracking system designed to improve the reliability of LLM interactions, especially when using smaller language models. The Todo System helps models: - Break complex tasks into manageable steps @@ -498,11 +498,11 @@ continuation_prompt: null # Custom prompt used when auto-continuing if in - `todo__list`: View current todo state - `todo__clear`: Clear the entire todo list and reset the goal - These instructions are a reasonable default that detail how to use Loki's To-Do System. If you wish, + These instructions are a reasonable default that detail how to use Coyote's To-Do System. If you wish, you can disable the injection of the default instructions and specify your own instructions for how to use the To-Do System into your main `instructions` for the agent. -2. When `auto_continue` is enabled and the model stops with incomplete tasks, Loki automatically sends a +2. When `auto_continue` is enabled and the model stops with incomplete tasks, Coyote automatically sends a continuation prompt with the current todo state, nudging the model to continue working. 3. This continues until all tasks are done or `max_auto_continues` is reached. @@ -518,13 +518,13 @@ For complete documentation including all configuration options, tool details, an # 7. Sub-Agent Spawning System -Loki agents can spawn and manage child agents that run **in parallel** as background tasks inside the same process. +Coyote agents can spawn and manage child agents that run **in parallel** as background tasks inside the same process. This enables orchestrator-style agents that delegate specialized work to other agents, similar to how tools like Claude Code or OpenCode handle complex multi-step tasks. For a working example of an orchestrator agent that uses sub-agent spawning, see the built-in -[sisyphus](https://github.com/Dark-Alex-17/loki/blob/main/assets/agents/sisyphus) agent. For an example of the teammate messaging pattern with parallel sub-agents, -see the [code-reviewer](https://github.com/Dark-Alex-17/loki/blob/main/assets/agents/code-reviewer) agent. +[sisyphus](https://github.com/Dark-Alex-17/coyote/blob/main/assets/agents/sisyphus) agent. For an example of the teammate messaging pattern with parallel sub-agents, +see the [code-reviewer](https://github.com/Dark-Alex-17/coyote/blob/main/assets/agents/code-reviewer) agent. ## Spawning Configuration @@ -579,7 +579,7 @@ agent__collect --id agent_explore_a1b2c3d4 agent__collect --id agent_explore_e5f6g7h8 ``` -Any agent defined in your `/agents/` directory can be spawned as a child. Child agents: +Any agent defined in your `/agents/` directory can be spawned as a child. Child agents: - Run in a fully isolated environment (separate session, config, and tools) - Have their output suppressed from the terminal (no spinner, no tool call logging) - Return their accumulated output to the parent when collected @@ -654,7 +654,7 @@ agent__check_inbox Messages are routed through the parent's supervisor. A parent can message its children, and children can message their siblings. For a working example of the teammate pattern, see the built-in -[code-reviewer](https://github.com/Dark-Alex-17/loki/blob/main/assets/agents/code-reviewer) agent, which spawns file-specific reviewers that share +[code-reviewer](https://github.com/Dark-Alex-17/coyote/blob/main/assets/agents/code-reviewer) agent, which spawns file-specific reviewers that share cross-cutting findings with each other. ## Runaway Safeguards @@ -671,7 +671,7 @@ The spawning system includes built-in safeguards to prevent runaway agent chains # 8. User Interaction Tools -Loki includes built-in tools for agents (and the REPL) to interactively prompt the user for input. These tools +Coyote includes built-in tools for agents (and the REPL) to interactively prompt the user for input. These tools are **always available**. No configuration needed. They are automatically injected into every agent and into REPL mode when function calling is enabled. @@ -717,7 +717,7 @@ This tool is automatically available to any agent with `can_spawn_agents: true`. # 9. Auto-Injected Prompts -Loki automatically appends usage instructions to your agent's system prompt for each enabled built-in system. +Coyote automatically appends usage instructions to your agent's system prompt for each enabled built-in system. These instructions are injected into both **static and dynamic instructions** after your own instructions, ensuring agents always know how to use their available tools. @@ -733,7 +733,7 @@ and include your custom instructions in the agent's `instructions` field. The bu available; only the auto-injected prompt text is suppressed. # Built-In Agents -Loki comes packaged with some useful built-in agents: +Coyote comes packaged with some useful built-in agents: * `coder`: An agent to assist you with all your coding tasks * `code-reviewer`: A [CodeRabbit](https://coderabbit.ai)-style code reviewer that spawns per-file reviewers using the teammate messaging pattern @@ -746,7 +746,7 @@ Loki comes packaged with some useful built-in agents: * `sisyphus`: A powerhouse orchestrator agent for writing complex code and acting as a natural language interface for your codebase (similar to ClaudeCode, Gemini CLI, Codex, or OpenCode). Uses sub-agent spawning to delegate to `explore`, `coder`, and `oracle`. * `sql`: A universal SQL agent that enables you to talk to any relational database in natural language -Loki writes these built-in agents to your agents directory on first run and never overwrites them afterward, so any -edits you make to them are preserved across Loki updates. To discard your local changes and reinstall the built-in -agents from the current Loki build, run `loki --install agents` (or `.install agents` in the REPL). Agents you created +Coyote writes these built-in agents to your agents directory on first run and never overwrites them afterward, so any +edits you make to them are preserved across Coyote updates. To discard your local changes and reinstall the built-in +agents from the current Coyote build, run `coyote --install agents` (or `.install agents` in the REPL). Agents you created yourself are not affected. diff --git a/Bash-Prompt-Helpers.md b/Bash-Prompt-Helpers.md index 4030374..91b4794 100644 --- a/Bash-Prompt-Helpers.md +++ b/Bash-Prompt-Helpers.md @@ -1,22 +1,22 @@ When creating bash based tools, it's often helpful to prompt the user for input or confirmation. -Loki comes pre-packaged with a handful of prompt helpers for your bash-based tools. These helpers +Coyote comes pre-packaged with a handful of prompt helpers for your bash-based tools. These helpers can be used to prompt the user for various types of input, such as yes/no confirmations, text input, and selections from a list. -The utility script is located at `functions/utils/prompt-utils.sh` within your Loki `functions` directory. +The utility script is located at `functions/utils/prompt-utils.sh` within your Coyote `functions` directory. -The Loki `functions` directory varies between machines, so you can find its location on your system by running the following command in your terminal: +The Coyote `functions` directory varies between machines, so you can find its location on your system by running the following command in your terminal: ```shell -loki --info | grep functions_dir | awk '{print $2}' +coyote --info | grep functions_dir | awk '{print $2}' ``` --- # Import The Prompt Utils Into Your Tools Script In order to use the bash prompt helpers in your bash scripts, you need to source the provided `prompt-utils.sh` script. -This script is pre-packaged with Loki and is located [here](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/utils/prompt-utils.sh). +This script is pre-packaged with Coyote and is located [here](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/utils/prompt-utils.sh). When sourcing the file in your bash script, you use the `LLM_PROMPT_UTILS_FILE` environment variable that automatically populates the `functions/utils/prompt-utils.sh` path for you. diff --git a/Clients.md b/Clients.md index 5ed86cf..855229c 100644 --- a/Clients.md +++ b/Clients.md @@ -1,17 +1,17 @@ -Loki supports a large number of model providers (referred to as `clients` since Loki is a client of these providers). In -order to use them, you must configure each one in the `clients` array in the global Loki configuration file. +Coyote supports a large number of model providers (referred to as `clients` since Coyote is a client of these providers). In +order to use them, you must configure each one in the `clients` array in the global Coyote configuration file. -The location of the global Loki configuration file varies between systems, so you can use the following command to +The location of the global Coyote configuration file varies between systems, so you can use the following command to locate your configuration file: ```shell -loki --info | grep 'config_file' | awk '{print $2}' +coyote --info | grep 'config_file' | awk '{print $2}' ``` --- # Supported Clients -Loki supports the following model client types: +Coyote supports the following model client types: * Azure AI Foundry * AWS Bedrock @@ -23,11 +23,11 @@ Loki supports the following model client types: * GCP Vertex AI In addition to the settings detailed below, each client may have additional settings specific to the provider. Check the -[example global configuration file](https://github.com/Dark-Alex-17/loki/blob/main/config.example.yaml) to verify that your client has all the necessary fields +[example global configuration file](https://github.com/Dark-Alex-17/coyote/blob/main/config.example.yaml) to verify that your client has all the necessary fields defined. # Client Configuration -Each client in Loki has the same configuration settings available to them, with only special authentication fields added +Each client in Coyote has the same configuration settings available to them, with only special authentication fields added for specific clients as necessary. They are each placed under the `clients` array in your global configuration file: ```yaml @@ -39,7 +39,7 @@ clients: ``` ## Metadata -The client metadata uniquely identifies the client in Loki so you can reference it across your configurations. The +The client metadata uniquely identifies the client in Coyote so you can reference it across your configurations. The available settings are listed below: | Setting | Description | @@ -58,10 +58,10 @@ The `models` array lists the available models from the model client. Each one ha | Setting | Required | Model Type | Description | |-----------------------------|----------|-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `name` | * | `all` | The name of the model | -| `real_name` | | `all` | You can define model aliases via the `name` field. However, Loki still needs to know the real name
of the model so it can query it. For example: If you have `name: gpt-alias`, then you must
also define `real_name: gpt-oss:latest` | -| `type` | * | `all` | The type of model. Loki supports only 3 types of models:
  • `chat`
  • `embedding`
  • `reranker`
| -| `input_price` | | `all` | The cost in USD per 1M tokens for each input sequence; Loki will keep track of usage costs if this is defined | -| `output_price` | | `all` | The cost in USD per 1M tokens of the model output; Loki will keep track of usage costs if this is defined | +| `real_name` | | `all` | You can define model aliases via the `name` field. However, Coyote still needs to know the real name
of the model so it can query it. For example: If you have `name: gpt-alias`, then you must
also define `real_name: gpt-oss:latest` | +| `type` | * | `all` | The type of model. Coyote supports only 3 types of models:
  • `chat`
  • `embedding`
  • `reranker`
| +| `input_price` | | `all` | The cost in USD per 1M tokens for each input sequence; Coyote will keep track of usage costs if this is defined | +| `output_price` | | `all` | The cost in USD per 1M tokens of the model output; Coyote will keep track of usage costs if this is defined | | `patch` | | `all` | See the [model-specific patch configuration](Patches#model-specific-patches) documentation | | `max_input_tokens` | | `all` | The maximum number of input tokens for the model | | `max_output_tokens` | | `chat` | The maximum number of output tokens for the model | @@ -77,13 +77,13 @@ The `models` array lists the available models from the model client. Each one ha # Authentication -Loki clients support two authentication methods: **API keys** and **OAuth**. Each client entry in your configuration +Coyote clients support two authentication methods: **API keys** and **OAuth**. Each client entry in your configuration must use one or the other. ## API Key Authentication Most clients authenticate using an API key. Simply set the `api_key` field directly or inject it from the -[Loki vault](Vault): +[Coyote vault](Vault): ```yaml clients: @@ -116,47 +116,47 @@ clients: Run the `--authenticate` flag with the client name: ```sh -loki --authenticate my-claude-oauth +coyote --authenticate my-claude-oauth ``` Or if you have only one OAuth-configured client, you can omit the name: ```sh -loki --authenticate +coyote --authenticate ``` Alternatively, you can use the REPL command `.authenticate`. -This opens your browser for the OAuth authorization flow. Depending on the provider, Loki will either start a +This opens your browser for the OAuth authorization flow. Depending on the provider, Coyote will either start a temporary localhost server to capture the callback automatically (e.g. Gemini) or ask you to paste the authorization -code back into the terminal (e.g. Claude). Loki stores the tokens in `~/.cache/loki/oauth` and automatically refreshes +code back into the terminal (e.g. Claude). Coyote stores the tokens in `~/.cache/coyote/oauth` and automatically refreshes them when they expire. ### Gemini OAuth Note -Loki uses the following scopes for OAuth with Gemini: +Coyote uses the following scopes for OAuth with Gemini: * https://www.googleapis.com/auth/generative-language.peruserquota * https://www.googleapis.com/auth/userinfo.email * https://www.googleapis.com/auth/generative-language.retriever (Sensitive) -Since the `generative-language.retriever` scope is a sensitive scope, Google needs to verify Loki, which requires full -branding (logo, official website, privacy policy, terms of service, etc.). The Loki app is open-source and is designed +Since the `generative-language.retriever` scope is a sensitive scope, Google needs to verify Coyote, which requires full +branding (logo, official website, privacy policy, terms of service, etc.). The Coyote app is open-source and is designed to be used as a simple CLI. As such, there's no terms of service or privacy policy associated with it, and thus Google -cannot verify Loki. +cannot verify Coyote. So, when you kick off OAuth with Gemini, you may see a page similar to the following: ![](./images/clients/gemini-oauth-page.png) -Simply click the `Advanced` link and click `Go to Loki (unsafe)` to continue the OAuth flow. +Simply click the `Advanced` link and click `Go to Coyote (unsafe)` to continue the OAuth flow. ![](./images/clients/gemini-oauth-unverified.png) ![](./images/clients/gemini-oauth-unverified-allow.png) **Step 3: Use normally** -Once authenticated, the client works like any other. Loki uses the stored OAuth tokens automatically: +Once authenticated, the client works like any other. Coyote uses the stored OAuth tokens automatically: ```sh -loki -m my-claude-oauth:claude-sonnet-4-20250514 "Hello!" +coyote -m my-claude-oauth:claude-sonnet-4-20250514 "Hello!" ``` > **Note:** You can have multiple clients for the same provider. For example: you can have one with an API key and @@ -167,7 +167,7 @@ loki -m my-claude-oauth:claude-sonnet-4-20250514 "Hello!" * Gemini # Extra Settings -Loki also lets you customize some extra settings for interacting with APIs: +Coyote also lets you customize some extra settings for interacting with APIs: | Setting | Description | |-------------------|-------------------------------------------------------| diff --git a/Custom-Bash-Tools.md b/Custom-Bash-Tools.md index 9c4b885..b138d81 100644 --- a/Custom-Bash-Tools.md +++ b/Custom-Bash-Tools.md @@ -1,16 +1,16 @@ -Loki supports tools written in Bash. However, they must be written in a special format with special annotations in order -for Loki to be able to properly parse and utilize them. This formatting ensures that each Bash script is -self-describing, and formatted in such a way that Loki can anticipate how to execute it and what parameters to pass to -it. This standardization also lets Loki compile the script into a JSON schema that can be used to inform the LLM about +Coyote supports tools written in Bash. However, they must be written in a special format with special annotations in order +for Coyote to be able to properly parse and utilize them. This formatting ensures that each Bash script is +self-describing, and formatted in such a way that Coyote can anticipate how to execute it and what parameters to pass to +it. This standardization also lets Coyote compile the script into a JSON schema that can be used to inform the LLM about how to use the tool. -Each Bash-based tool must follow a specific structure in order for Loki to be able to properly compile and execute it: +Each Bash-based tool must follow a specific structure in order for Coyote to be able to properly compile and execute it: * The tool must be a Bash script with a `.sh` file extension. * The script must have the following comments: * `# @describe ...` comment at the top that describes the tool. * `# @env LLM_OUTPUT=/dev/stdout The output path` comment to describe the `LLM_OUTPUT` environment variable. This - syntax in particular assigns `/dev/stdout` as the default value for `LLM_OUTPUT`, so that if it's not set by Loki, + syntax in particular assigns `/dev/stdout` as the default value for `LLM_OUTPUT`, so that if it's not set by Coyote, the script will still function properly. * `# @option --option An example option` comments to define each option that the tool accepts. * Use `--flag` syntax for boolean flags. @@ -18,7 +18,7 @@ Each Bash-based tool must follow a specific structure in order for Loki to be ab * Use `--option ` syntax for options that accept multiple values (i.e. arrays). * The script must have a `main` function * The `main` function must redirect the return value to the `>> "$LLM_OUTPUT"` environment variable. - * This is necessary because Loki relies on the `$LLM_OUTPUT` environment variable to capture the output of the tool. + * This is necessary because Coyote relies on the `$LLM_OUTPUT` environment variable to capture the output of the tool. Essentially, you can think of the Bash-based tool script as just a normal Bash script that uses special comments to define a CLI. @@ -30,18 +30,18 @@ The following section explains how you can add parameters to your bash functions --- -# Loki Bash Tools Syntax -Loki Bash tools work via `@___` annotations that describe specific functionality of a script. The following reference -explains the general syntax of these annotations and how to use them to create a CLI that Loki can recognize. +# Coyote Bash Tools Syntax +Coyote Bash tools work via `@___` annotations that describe specific functionality of a script. The following reference +explains the general syntax of these annotations and how to use them to create a CLI that Coyote can recognize. Refer to the [Execute and Test Your Bash Tools](#execute-and-test-your-bash-tools) section to learn how to test out your Bash tools -without needing to go through Loki itself. +without needing to go through Coyote itself. It's important to note that any functions prefixed with `_` are not sent to the LLM, so they will be invisible to the LLM at runtime. ## Metadata: -You can define different metadata about your script to help Loki understand its dependencies and purpose. +You can define different metadata about your script to help Coyote understand its dependencies and purpose. ```bash # Use the `@meta require-tools` annotation to specify any external tools that your script depends on. @@ -74,12 +74,12 @@ main() { [[ $CHOICE == "even" ]] || { echo "The value of the 'CHOICE' env var is not 'even'" >> "$LLM_OUTPUT" && exit 1 } } -# Loki does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions +# Coyote does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions _default_env_fn() { echo "calculated default env value" } -# Loki does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions +# Coyote does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions _choice_env_fn() { echo even echo odd @@ -128,12 +128,12 @@ main() { } -# Loki does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions +# Coyote does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions _default_arg_fn() { echo "default arg value" } -# Loki does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions +# Coyote does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions _choice_arg_fn() { echo even echo odd @@ -214,12 +214,12 @@ main() { } -# Loki does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions +# Coyote does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions _default_opt_fn() { echo "calculated default option value" } -# Loki does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions +# Coyote does not pass functions prefixed with `_` to the LLM, so these are essentially `private` functions _choice_opt_fn() { echo even echo odd @@ -253,26 +253,26 @@ cat() { # Execute and Test Your Bash Tools Your bash tools are just normal bash scripts stored in the `functions/tools` directory. So you can execute and test them -directly by first having Loki compile them so all this syntactic sugar means something. +directly by first having Coyote compile them so all this syntactic sugar means something. -This is achieved via the `loki --build-tools` command. +This is achieved via the `coyote --build-tools` command. ## Example Suppose we want to execute the `functions/tools/get_current_time.sh` script for testing. We'd first make sure the script is visible in all contexts by ensuring it's in the `visible_tools` array in your global -`config.yaml` file. This ensures Loki builds the tool so it's ready to use in any context. +`config.yaml` file. This ensures Coyote builds the tool so it's ready to use in any context. You can find the location of your global `config.yaml` file with the following command: ```shell -loki --info | grep 'config_file' | awk '{print $2}' +coyote --info | grep 'config_file' | awk '{print $2}' ``` -Then, we can instruct Loki to build the script so we can test it out: +Then, we can instruct Coyote to build the script so we can test it out: ```shell -loki --build-tools +coyote --build-tools ``` This will add additional boilerplate to the top of the script so that it can be executed directly. @@ -288,7 +288,7 @@ Fri Oct 24 05:55:04 PM MDT 2025 It's often useful to create interactive prompts for our bash tools so that our tools can get input from users. -To accommodate this, Loki provides a set of prompt helper functions that can be referenced and used within your Bash +To accommodate this, Coyote provides a set of prompt helper functions that can be referenced and used within your Bash tools. For more information, refer to the [Bash Prompt Helpers documentation](Bash-Prompt-Helpers). diff --git a/Custom-Tools.md b/Custom-Tools.md index 3cc8590..00d3f99 100644 --- a/Custom-Tools.md +++ b/Custom-Tools.md @@ -1,11 +1,11 @@ -Loki is designed to be as flexible and as customizable as possible. One of the key +Coyote is designed to be as flexible and as customizable as possible. One of the key features that enables this flexibility is the ability to create and integrate custom tools -into your Loki setup. This document provides a guide on how to create and use custom tools within Loki. +into your Coyote setup. This document provides a guide on how to create and use custom tools within Coyote. --- # Supported Languages -Loki supports custom tools written in the following programming languages: +Coyote supports custom tools written in the following programming languages: * Python * Bash @@ -17,11 +17,11 @@ The location of the `functions` directory varies between systems, so you can use your `functions` directory: ```shell -loki --info | grep functions_dir | awk '{print $2}' +coyote --info | grep functions_dir | awk '{print $2}' ``` Once you've created your custom tool, remember to add it to the `visible_tools` array in your global `config.yaml` file -to enable it globally. See the [Tools](Tools#enablingdisabling-global-tools) documentation for more information on how Loki utilizes the +to enable it globally. See the [Tools](Tools#enablingdisabling-global-tools) documentation for more information on how Coyote utilizes the `visible_tools` array. ## Environment Variables @@ -30,20 +30,20 @@ All tools have access to the following environment variables that provide contex | Variable | Description | |----------------------|--------------------------------------------------------------------------------------------------------------------------------------------| | `LLM_OUTPUT` | Indicates where the output of the tool should go.
In certain situations, this may be set to a temporary file instead of `/dev/stdout`. | -| `LLM_ROOT_DIR` | The root `config_dir` directory for Loki
(i.e. `dirname $(loki --info \| grep config_file \| awk '{print $2}')`) | +| `LLM_ROOT_DIR` | The root `config_dir` directory for Coyote
(i.e. `dirname $(coyote --info \| grep config_file \| awk '{print $2}')`) | | `LLM_TOOL_NAME` | The name of the tool being executed | | `LLM_TOOL_CACHE_DIR` | A directory specific to the tool for storing cache or temporary files | -Loki also searches the tools directory on startup for a `.env` file. If found, all tools in `functions/tools/` will have +Coyote also searches the tools directory on startup for a `.env` file. If found, all tools in `functions/tools/` will have the environment variables defined in the `.env` file available to them. ## Custom Bash-Based Tools To create a Bash-based tool, refer to the [custom bash tools documentation](Custom-Bash-Tools). ## Custom Python-Based Tools -Loki supports tools written in Python. +Coyote supports tools written in Python. -Each Python-based tool must follow a specific structure in order for Loki to be able to properly compile and +Each Python-based tool must follow a specific structure in order for Coyote to be able to properly compile and execute it: * The tool must be a Python script with a `.py` file extension. @@ -65,8 +65,8 @@ execute it: It's important to note that any functions prefixed with `_` are not sent to the LLM, so they will be invisible to the LLM at runtime. -Below is the [`demo_py.py`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/demo_py.py) tool definition that comes pre-packaged with -Loki and demonstrates how to create a Python-based tool: +Below is the [`demo_py.py`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/demo_py.py) tool definition that comes pre-packaged with +Coyote and demonstrates how to create a Python-based tool: ```python import os @@ -123,10 +123,10 @@ array_optional: {array_optional}""" ``` ## Custom TypeScript-Based Tools -Loki supports tools written in TypeScript. TypeScript tools require [Node.js](https://nodejs.org/) and +Coyote supports tools written in TypeScript. TypeScript tools require [Node.js](https://nodejs.org/) and [tsx](https://tsx.is/) (`npx tsx` is used as the default runtime). -Each TypeScript-based tool must follow a specific structure in order for Loki to properly compile and execute it: +Each TypeScript-based tool must follow a specific structure in order for Coyote to properly compile and execute it: * The tool must be a TypeScript file with a `.ts` file extension. * The tool must have an `export function run(...)` that serves as the entry point for the tool. @@ -167,8 +167,8 @@ Each TypeScript-based tool must follow a specific structure in order for Loki to Only `export function` declarations are recognized. Non-exported functions are invisible to the compiler. -Below is the [`demo_ts.ts`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/demo_ts.ts) tool definition that comes pre-packaged with -Loki and demonstrates how to create a TypeScript-based tool: +Below is the [`demo_ts.ts`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/demo_ts.ts) tool definition that comes pre-packaged with +Coyote and demonstrates how to create a TypeScript-based tool: ```typescript /** @@ -227,7 +227,7 @@ export function run( ``` # Custom Runtime -By default, Loki uses the following runtimes to execute tools: +By default, Coyote uses the following runtimes to execute tools: | Language | Default Runtime | Requirement | |------------|-----------------|--------------------------------| @@ -236,7 +236,7 @@ By default, Loki uses the following runtimes to execute tools: | Bash | `bash` | Bash on `$PATH` | You can override the runtime for Python and TypeScript tools using a **shebang line** (`#!`) at the top of your -script. Loki reads the first line of each tool file; if it starts with `#!`, the specified interpreter is used instead +script. Coyote reads the first line of each tool file; if it starts with `#!`, the specified interpreter is used instead of the default. **Examples:** diff --git a/Environment-Variables.md b/Environment-Variables.md index bd97831..086d96f 100644 --- a/Environment-Variables.md +++ b/Environment-Variables.md @@ -1,72 +1,72 @@ -Loki is designed to be highly dynamic and customizable. As a result, Loki utilizes a number of environment variables +Coyote is designed to be highly dynamic and customizable. As a result, Coyote utilizes a number of environment variables that can be used to modify its behavior at runtime without needing to modify the existing configuration files. -Loki also supports defining environment variables via a `.env` file in the Loki configuration directory. This directory +Coyote also supports defining environment variables via a `.env` file in the Coyote configuration directory. This directory varies between systems, so you can find the location of your configuration directory using the following command: ```shell -loki --info | grep 'config_dir' | awk '{print $2}' +coyote --info | grep 'config_dir' | awk '{print $2}' ``` --- # Global Configuration Related Variables All configuration items in the global config file have environment variables that can be overridden at runtime. To see -all configuration options and more thorough descriptions, refer to the [example config file](https://github.com/Dark-Alex-17/loki/blob/main/config.example.yaml). +all configuration options and more thorough descriptions, refer to the [example config file](https://github.com/Dark-Alex-17/coyote/blob/main/config.example.yaml). Below are the most commonly used configuration settings and their corresponding environment variables: | Setting | Environment Variable | |----------------------------|---------------------------------| -| `model` | `LOKI_MODEL` | -| `temperature` | `LOKI_TEMPERATURE` | -| `top_p` | `LOKI_TOP_P` | -| `stream` | `LOKI_STREAM` | -| `save` | `LOKI_SAVE` | -| `editor` | `LOKI_EDITOR` | -| `wrap` | `LOKI_WRAP` | -| `wrap_code` | `LOKI_WRAP_CODE` | -| `save_session` | `LOKI_SAVE_SESSION` | -| `compression_threshold` | `LOKI_COMPRESSION_THRESHOLD` | -| `function_calling_support` | `LOKI_FUNCTION_CALLING_SUPPORT` | -| `enabled_tools` | `LOKI_ENABLED_TOOLS` | -| `mcp_server_support` | `LOKI_MCP_SERVER_SUPPORT` | -| `enabled_mcp_servers` | `LOKI_ENABLED_MCP_SERVERS` | -| `rag_embedding_model` | `LOKI_RAG_EMBEDDING_MODEL` | -| `rag_reranker_model` | `LOKI_RAG_RERANKER_MODEL` | -| `rag_top_k` | `LOKI_RAG_TOP_K` | -| `rag_chunk_size` | `LOKI_RAG_CHUNK_SIZE` | -| `rag_chunk_overlap` | `LOKI_RAG_CHUNK_OVERLAP` | -| `highlight` | `LOKI_HIGHLIGHT` | -| `theme` | `LOKI_THEME` | -| `serve_addr` | `LOKI_SERVE_ADDR` | -| `user_agent` | `LOKI_USER_AGENT` | -| `save_shell_history` | `LOKI_SAVE_SHELL_HISTORY` | -| `sync_models_url` | `LOKI_SYNC_MODELS_URL` | +| `model` | `COYOTE_MODEL` | +| `temperature` | `COYOTE_TEMPERATURE` | +| `top_p` | `COYOTE_TOP_P` | +| `stream` | `COYOTE_STREAM` | +| `save` | `COYOTE_SAVE` | +| `editor` | `COYOTE_EDITOR` | +| `wrap` | `COYOTE_WRAP` | +| `wrap_code` | `COYOTE_WRAP_CODE` | +| `save_session` | `COYOTE_SAVE_SESSION` | +| `compression_threshold` | `COYOTE_COMPRESSION_THRESHOLD` | +| `function_calling_support` | `COYOTE_FUNCTION_CALLING_SUPPORT` | +| `enabled_tools` | `COYOTE_ENABLED_TOOLS` | +| `mcp_server_support` | `COYOTE_MCP_SERVER_SUPPORT` | +| `enabled_mcp_servers` | `COYOTE_ENABLED_MCP_SERVERS` | +| `rag_embedding_model` | `COYOTE_RAG_EMBEDDING_MODEL` | +| `rag_reranker_model` | `COYOTE_RAG_RERANKER_MODEL` | +| `rag_top_k` | `COYOTE_RAG_TOP_K` | +| `rag_chunk_size` | `COYOTE_RAG_CHUNK_SIZE` | +| `rag_chunk_overlap` | `COYOTE_RAG_CHUNK_OVERLAP` | +| `highlight` | `COYOTE_HIGHLIGHT` | +| `theme` | `COYOTE_THEME` | +| `serve_addr` | `COYOTE_SERVE_ADDR` | +| `user_agent` | `COYOTE_USER_AGENT` | +| `save_shell_history` | `COYOTE_SAVE_SHELL_HISTORY` | +| `sync_models_url` | `COYOTE_SYNC_MODELS_URL` | # Client Related Variables -The following environment variables are available for clients in Loki: +The following environment variables are available for clients in Coyote: | Environment Variable | Description | |----------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `{client}_API_KEY` | For clients that require an API key, you can define the keys either through environment variables or
using the [vault](Vault). The variables are named after the client to which they apply;
e.g. `OPENAI_API_KEY`, `GEMINI_API_KEY`, etc. | -| `LOKI_PLATFORM` | Combine with `{client}_API_KEY` to run Loki without a configuration file.
This variable is ignored if a configuration file exists. | -| `LOKI_PATCH_{client}_CHAT_COMPLETIONS` | Patch chat completion requests to models on the corresponding client; Can modify the URL, body,
or headers. | -| `LOKI_SHELL` | Specify the shell that Loki should be using when executing commands | +| `COYOTE_PLATFORM` | Combine with `{client}_API_KEY` to run Coyote without a configuration file.
This variable is ignored if a configuration file exists. | +| `COYOTE_PATCH_{client}_CHAT_COMPLETIONS` | Patch chat completion requests to models on the corresponding client; Can modify the URL, body,
or headers. | +| `COYOTE_SHELL` | Specify the shell that Coyote should be using when executing commands | # Files and Directory Related Variables -You can also customize the files and directories that Loki loads its configuration files from: +You can also customize the files and directories that Coyote loads its configuration files from: | Environment Variable | Description | Default Value | |----------------------|------------------------------------------------------------------------|---------------------------------| -| `LOKI_CONFIG_DIR` | Customize the location of the Loki configuration directory. | `/loki` | -| `LOKI_ENV_FILE` | Customize the location of the `.env` file to load at startup. | `/.env` | -| `LOKI_CONFIG_FILE` | Customize the location of the global `config.yaml` configuration file. | `/config.yaml` | -| `LOKI_ROLES_DIR` | Customize the location of the `roles` directory. | `/roles` | -| `LOKI_SESSIONS_DIR` | Customize the location of the `sessions` directory. | `/sessions` | -| `LOKI_RAGS_DIR` | Customize the location of the `rags` directory. | `/rags` | -| `LOKI_FUNCTIONS_DIR` | Customize the location of the `functions` directory. | `/functions` | +| `COYOTE_CONFIG_DIR` | Customize the location of the Coyote configuration directory. | `/coyote` | +| `COYOTE_ENV_FILE` | Customize the location of the `.env` file to load at startup. | `/.env` | +| `COYOTE_CONFIG_FILE` | Customize the location of the global `config.yaml` configuration file. | `/config.yaml` | +| `COYOTE_ROLES_DIR` | Customize the location of the `roles` directory. | `/roles` | +| `COYOTE_SESSIONS_DIR` | Customize the location of the `sessions` directory. | `/sessions` | +| `COYOTE_RAGS_DIR` | Customize the location of the `rags` directory. | `/rags` | +| `COYOTE_FUNCTIONS_DIR` | Customize the location of the `functions` directory. | `/functions` | # Agent Related Variables You can also customize the location of full agent configurations using the following environment variables: @@ -84,18 +84,18 @@ You can also customize the location of full agent configurations using the follo | `_VARIABLES` | Customize the `variables` used for the agent (in JSON format of `[{"key1": "value1", "key2": "value2"}]`);
e.g. `SQL_VARIABLES` | # Logging Related Variables -The following variables can be used to change the log level of Loki or the location of the log file: +The following variables can be used to change the log level of Coyote or the location of the log file: | Environment Variable | Description | Default Value | |----------------------|---------------------------------------------|----------------------------------| -| `LOKI_LOG_LEVEL` | Customize the log level of Loki | `INFO` | -| `LOKI_LOG_FILE` | Customize the location of the Loki log file | `/loki/loki.log` | +| `COYOTE_LOG_LEVEL` | Customize the log level of Coyote | `INFO` | +| `COYOTE_LOG_FILE` | Customize the location of the Coyote log file | `/coyote/coyote.log` | -**Pro-Tip:** You can always tail the Loki logs using the `--tail-logs` flag. If you need to disable color output, you +**Pro-Tip:** You can always tail the Coyote logs using the `--tail-logs` flag. If you need to disable color output, you can also pass the `--disable-log-colors` flag as well. # Miscellaneous Variables | Environment Variable | Description | Default Value | |----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------| | `AUTO_CONFIRM` | Bypass all `guard_*` checks in the bash prompt helpers; useful for agent composition and routing | | -| `LLM_TOOL_DATA_FILE` | Set automatically by Loki on Windows. Points to a temporary file containing the JSON tool call data.
Tool scripts (`run-tool.sh`, `run-agent.sh`, etc.) read from this file instead of command-line args
to avoid JSON escaping issues when data passes through `cmd.exe` → bash. **Not intended to be set by users.** | | +| `LLM_TOOL_DATA_FILE` | Set automatically by Coyote on Windows. Points to a temporary file containing the JSON tool call data.
Tool scripts (`run-tool.sh`, `run-agent.sh`, etc.) read from this file instead of command-line args
to avoid JSON escaping issues when data passes through `cmd.exe` → bash. **Not intended to be set by users.** | | diff --git a/Getting-Started.md b/Getting-Started.md index 44b3312..71060ec 100644 --- a/Getting-Started.md +++ b/Getting-Started.md @@ -1,14 +1,14 @@ After installation, you can generate the configuration files and directories by simply running: ```sh -loki --info +coyote --info ``` -Then, you need to set up the Loki vault by creating a vault password file. Loki will do this for you automatically and +Then, you need to set up the Coyote vault by creating a vault password file. Coyote will do this for you automatically and guide you through the process when you first attempt to access the vault. So, to get started, you can run: ```sh -loki --list-secrets +coyote --list-secrets ``` # Authentication @@ -25,25 +25,25 @@ clients: ``` ```sh -loki --authenticate my-claude-oauth +coyote --authenticate my-claude-oauth # Or via the REPL: .authenticate ``` For full details, see the [authentication documentation](Clients#authentication). # Configuration -The location of the global Loki configuration varies between systems, so you can use the following command to find your +The location of the global Coyote configuration varies between systems, so you can use the following command to find your `config.yaml` file: ```shell -loki --info | grep 'config_file' | awk '{print $2}' +coyote --info | grep 'config_file' | awk '{print $2}' ``` The configuration file consists of a number of settings. To see a full example configuration file with every setting -defined, refer to the [example configuration file](https://github.com/Dark-Alex-17/loki/blob/main/config.example.yaml). +defined, refer to the [example configuration file](https://github.com/Dark-Alex-17/coyote/blob/main/config.example.yaml). ## Default LLM -The following settings are available to configure the default LLM that is used when you start Loki, and its +The following settings are available to configure the default LLM that is used when you start Coyote, and its hyperparameters: | Setting | Description | @@ -53,34 +53,34 @@ hyperparameters: | `top_p` | The default `top_p` hyperparameter value to use for all models, with a range of (0,1) (or (0,2) for some models);
Used unless explicitly overridden | ## CLI Behavior -You can use the following settings to modify the behavior of Loki: +You can use the following settings to modify the behavior of Coyote: | Setting | Default Value | Description | |---------------|---------------|-------------------------------------------------------------------------------------------------------------------------------------| | `stream` | `true` | Controls whether to use stream-style APIs when querying for completions from LLM providers | | `save` | `true` | Controls whether to save each query/response to every model to `messages.md` for posterity; Useful for debugging | | `keybindings` | `emacs` | Specifies which keybinding schema to use; can either be `emacs` or `vi` | -| `editor` | `null` | What text editor Loki should use to edit the input buffer or session (e.g. `vim`, `emacs`, `nano`, `hx`);
Defaults to `$EDITOR` | +| `editor` | `null` | What text editor Coyote should use to edit the input buffer or session (e.g. `vim`, `emacs`, `nano`, `hx`);
Defaults to `$EDITOR` | | `wrap` | `no` | Controls whether text is wrapped (can be `no`, `auto`, or some `` | | `wrap_code` | `false` | Enables or disables the wrapping of code blocks | ## Preludes -Preludes let you define the default behavior for the different operating modes of Loki. The available settings are +Preludes let you define the default behavior for the different operating modes of Coyote. The available settings are shown below: | Setting | Description | |-----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `repl_prelude` | This setting lets you specify a default `session` or `role` to use when starting Loki in [REPL](REPL) mode.
Values can be
  • `role:` to define a role
  • `session:` to define a session
  • `:` to define both a session and a role to use
| -| `cmd_prelude` | This setting lets you specify a default `session` or `role` to use when running one-off queries in Loki via the CLI.
Values can be
  • `role:` to define a role
  • `session:` to define a session
  • `:` to define both a session and a role to use
| +| `repl_prelude` | This setting lets you specify a default `session` or `role` to use when starting Coyote in [REPL](REPL) mode.
Values can be
  • `role:` to define a role
  • `session:` to define a session
  • `:` to define both a session and a role to use
| +| `cmd_prelude` | This setting lets you specify a default `session` or `role` to use when running one-off queries in Coyote via the CLI.
Values can be
  • `role:` to define a role
  • `session:` to define a session
  • `:` to define both a session and a role to use
| | `agent_session` | This setting is used to specify a default session that all agents should start into, unless otherwise specified in the agent configuration. (e.g. `temp`, `default`) | ## Appearance -The appearance of Loki can be modified using the following settings: +The appearance of Coyote can be modified using the following settings: | Setting | Default Value | Description | |---------------|---------------|------------------------------------------------------| | `highlight` | `true` | This setting enables or disables syntax highlighting | -| `light_theme` | `false` | This setting toggles light mode in Loki | +| `light_theme` | `false` | This setting toggles light mode in Coyote | ## Miscellaneous Settings | Setting | Default Value | Description | diff --git a/Graph-Agents.md b/Graph-Agents.md index 2238fbf..9d00a0b 100644 --- a/Graph-Agents.md +++ b/Graph-Agents.md @@ -1,5 +1,5 @@ Graph-based agents are a declarative, YAML-driven workflow engine layered on -top of Loki's existing agent system. Where a normal [agent](Agents) runs as a +top of Coyote's existing agent system. Where a normal [agent](Agents) runs as a single LLM loop driven by tool calls, a **graph agent** is a directed graph of typed nodes. Each node performs one well-defined step (call an LLM, run a script, ask the user a question, spawn a child agent, etc.) and routes to the @@ -26,7 +26,7 @@ A graph agent is defined by a single `graph.yaml`. It holds *both* the agent-level config (model, tools, MCP servers) *and* the workflow: ``` -/agents +/agents └── my-graph-agent ├── graph.yaml # agent config + workflow definition ├── tools.sh # optional custom tools @@ -36,17 +36,17 @@ agent-level config (model, tools, MCP servers) *and* the workflow: └── verify.py ``` -`.yaml` files are generated by Loki at agent load time - one +`.yaml` files are generated by Coyote at agent load time - one per `rag` node - and should not be hand-edited. An agent directory must contain **either** a `config.yaml` (a normal, LLM-loop agent (see [Agents](Agents))) **or** a `graph.yaml` (a graph agent). Never both. The presence of `graph.yaml` is what marks an agent -as a graph agent; when Loki runs it, execution is driven entirely by the +as a graph agent; when Coyote runs it, execution is driven entirely by the graph. **Both files present is an error.** If an agent directory contains both -`config.yaml` and `graph.yaml`, Loki refuses to load it and tells you to +`config.yaml` and `graph.yaml`, Coyote refuses to load it and tells you to remove one. Pick the model that fits: `config.yaml` for an open-ended LLM-loop agent, `graph.yaml` for a fixed-shape workflow. @@ -65,7 +65,7 @@ model: anthropic:claude-sonnet-4-6 # default model for llm nodes temperature: 0.0 # default sampling temperature top_p: null # default sampling top-p global_tools: # global tools available to nodes - - web_search_loki.sh + - web_search_coyote.sh mcp_servers: # MCP servers available to nodes - pubmed-search conversation_starters: # suggested prompts in the UI @@ -111,7 +111,7 @@ nodes: Each declared variable becomes available to script nodes as the env var `LLM_AGENT_VAR_`, exactly like bash tools called by normal agents. Values may be overridden at runtime via - `loki -a --agent-variable "..."`. For LLM nodes to + `coyote -a --agent-variable "..."`. For LLM nodes to see a variable inside prompts, seed its value into state (typically via a setup script that reads the env var and writes it into state) so `{{name}}` resolves. @@ -141,8 +141,8 @@ nodes: ### `{{initial_prompt}}`: Automatically Seeded -When Loki invokes a graph agent with a user prompt (whether from the -command line `loki -a my-agent "what is X?"`, from the REPL, or from a +When Coyote invokes a graph agent with a user prompt (whether from the +command line `coyote -a my-agent "what is X?"`, from the REPL, or from a parent agent that spawned it as a sub-agent), the dispatcher automatically seeds the prompt text into state under the key **`initial_prompt`** before any node runs. @@ -189,15 +189,15 @@ prompts). See [Parallel Execution](#parallel-execution) for the full model. ## agent -Spawns a Loki sub-agent and waits for it to finish. This is how a graph agent -delegates a sub-goal to a fully autonomous Loki agent (with its own tool loop +Spawns a Coyote sub-agent and waits for it to finish. This is how a graph agent +delegates a sub-goal to a fully autonomous Coyote agent (with its own tool loop and configuration). ```yaml research_topic: id: research_topic type: agent - agent: deep-researcher # name of an existing Loki agent + agent: deep-researcher # name of an existing Coyote agent prompt: "Research {{topic}}" # interpolated against state timeout: 600 # optional, in seconds (default 300) state_updates: @@ -207,7 +207,7 @@ research_topic: ``` - **`agent`:** Name of the child agent to spawn. Must exist in - `/agents/`. + `/agents/`. - **`prompt`:** The user message sent to the child agent. Templated against the current graph state. - **`timeout`:** Hard wall-clock cap. If the child agent exceeds it, the @@ -262,15 +262,15 @@ from normal agents: | Env var | Contents | |--------------------------|----------------------------------------------------------------| -| `LLM_ROOT_DIR` | Loki config dir (e.g. `~/.config/loki`) | +| `LLM_ROOT_DIR` | Coyote config dir (e.g. `~/.config/coyote`) | | `LLM_PROMPT_UTILS_FILE` | Absolute path to `.shared/prompt-utils.sh` | | `LLM_AGENT_DATA_DIR` | The agent's own data directory (where this `graph.yaml` lives) | | `LLM_AGENT_VAR_` | One per declared `variables:` entry; uppercased name | -| `PATH` | Loki's functions bin dir prepended to the inherited `PATH` | +| `PATH` | Coyote's functions bin dir prepended to the inherited `PATH` | | `CLICOLOR_FORCE`, `FORCE_COLOR` | Both set to `1` so child tools emit ANSI colors | -The script's **working directory** is the loki invocation directory (where -the user ran `loki -a ...`), not the agent directory. This matches +The script's **working directory** is the coyote invocation directory (where +the user ran `coyote -a ...`), not the agent directory. This matches the behavior of bash tools called by normal agents, and lets scripts use `"."` or relative paths to refer to the user's project. To resolve sibling files inside the agent directory (for example `.shared/utils.sh`), use @@ -330,7 +330,7 @@ approve: ### The `on_other` field -This field is **required** and easy to miss. Loki's `user__ask` tool *always* +This field is **required** and easy to miss. Coyote's `user__ask` tool *always* gives the user a "type your own answer" option in addition to the listed options. There is no way to disable this. Without `on_other`, a user who types something other than the listed options would crash the graph at @@ -534,10 +534,10 @@ Each `rag` node's knowledge base is built **once, at agent load time**, into - If it's missing and the node is **fully specified** (`embedding_model` + `chunk_size` + `chunk_overlap` all set) -> it is built directly, no prompts. Works in non-interactive runs. -- If it's missing, not fully specified, and Loki is interactive -> you are +- If it's missing, not fully specified, and Coyote is interactive -> you are asked to initialize it, then prompted for the missing build values; declining is a hard error. -- If it's missing, not fully specified, and Loki is non-interactive +- If it's missing, not fully specified, and Coyote is non-interactive (no TTY) -> hard error, with a hint to set the build-config fields or run the agent once interactively. @@ -548,7 +548,7 @@ inspected, not run, so knowledge-base building is skipped entirely.) ### Retrieval Retrieval at execution time is fast (no re-embedding of the corpus). It's -the same hybrid vector + keyword search normal Loki RAG uses. The corpus +the same hybrid vector + keyword search normal Coyote RAG uses. The corpus embedding/chunking cost is paid once, at load time. --- @@ -1087,7 +1087,7 @@ When `output_schema` is set: 2. The raw text output is **tried as JSON first** (with light cleanup of markdown code fences); the fast path. If parsing succeeds, that's the structured output. -3. Otherwise Loki invokes a built-in `__structured_output__` role +3. Otherwise Coyote invokes a built-in `__structured_output__` role (constructed inline; not visible in the user's role list) to extract a JSON object matching the schema. One repair retry on extractor failure. 4. When the parsed value is a JSON **object**, its **top-level keys @@ -1105,13 +1105,13 @@ After the example above, downstream nodes can use `{{action}}`, `{{items}}`, This is the **most important behavioral difference** between the two node types when `output_schema` is set: -- **LLM nodes**: Loki automatically appends a schema hint to the prompt +- **LLM nodes**: Coyote automatically appends a schema hint to the prompt (to the system prompt if `instructions` is set, otherwise to the user prompt). The hint tells the model to respond with JSON matching the schema. This means the main LLM call usually emits valid JSON directly -> the fast path succeeds -> the extractor LLM call is skipped entirely (cheaper, faster, more reliable). -- **Agent nodes**: Loki does NOT inject any schema hint. Agents are +- **Agent nodes**: Coyote does NOT inject any schema hint. Agents are multi-turn with their own tool-use loop; stuffing a schema into the initial prompt risks the agent fixating on JSON output instead of doing its actual work. The agent runs to completion freely, and the extractor @@ -1143,7 +1143,7 @@ Schema: A compact illustrative graph -`input` -> `llm` (with `output_schema`) -> `end` - exercising structured output and all template-path forms. For a **full-featured reference** covering every node type and field, see the -heavily-commented `graph.example.yaml` at the root of the Loki repository. +heavily-commented `graph.example.yaml` at the root of the Coyote repository. Illustrative `graph.yaml`: @@ -1221,7 +1221,7 @@ Sample state after `extract_task`: # Validation -When `validate_before_run: true` (the default), Loki validates the graph at +When `validate_before_run: true` (the default), Coyote validates the graph at startup. **Errors (abort startup)**: @@ -1236,7 +1236,7 @@ startup. - `approval` option without a matching `routes` entry - `script` file path does not exist relative to the agent's directory - `agent` node references an agent name that doesn't exist in the - loki agents directory, or that exists but has neither a `config.yaml` + coyote agents directory, or that exists but has neither a `config.yaml` nor a `graph.yaml` - `rag` node with no `documents` (at least one knowledge source is required) - `llm` node referencing an unknown tool or `mcp:` in its `tools` @@ -1293,12 +1293,12 @@ startup. A graph agent can be entered from three places, all of which seed the caller's prompt into state as `{{initial_prompt}}`: -1. **Top-level CLI:** `loki -a my-graph-agent "user prompt here"` +1. **Top-level CLI:** `coyote -a my-graph-agent "user prompt here"` 2. **REPL:** When the active agent has a `graph.yaml`, every user message in the REPL runs the graph fresh; the message becomes `{{initial_prompt}}` 3. **Child-agent spawn:** When another (graph or normal) agent invokes - this one via Loki's sub-agent mechanism, the parent's request becomes + this one via Coyote's sub-agent mechanism, the parent's request becomes `{{initial_prompt}}` for the child graph After the graph finishes, any sub-agents this graph spawned via @@ -1339,7 +1339,7 @@ This is the developer-facing channel and includes: ``` **State snapshots**: when `log_state_snapshots: true` (the default), before -each node runs Loki logs the state's byte size and key list at `debug` +each node runs Coyote logs the state's byte size and key list at `debug` level, and the *full* state at `trace` level. The full state is deliberately kept at `trace` because graph state can contain secrets so be careful sharing `trace`-level logs. @@ -1349,9 +1349,9 @@ be careful sharing `trace`-level logs. Control the `tracing` channel with `RUST_LOG`: ```sh -RUST_LOG=loki::graph=debug loki -a my-agent "..." # graph debug logs -RUST_LOG=loki::graph=trace loki -a my-agent "..." # + full state snapshots -RUST_LOG=loki::graph=info loki -a my-agent "..." # start/end/perf summary +RUST_LOG=coyote::graph=debug coyote -a my-agent "..." # graph debug logs +RUST_LOG=coyote::graph=trace coyote -a my-agent "..." # + full state snapshots +RUST_LOG=coyote::graph=info coyote -a my-agent "..." # start/end/perf summary ``` The stderr `▸` narration is always shown and is not affected by `RUST_LOG`. @@ -1441,8 +1441,8 @@ A short, honest list of things that bite people: # See Also -- [`graph.example.yaml`](https://github.com/Dark-Alex-17/loki/blob/main/graph.example.yaml) - A fully-commented, full-featured reference - graph agent at the root of the Loki repository (every top-level field, +- [`graph.example.yaml`](https://github.com/Dark-Alex-17/coyote/blob/main/graph.example.yaml) - A fully-commented, full-featured reference + graph agent at the root of the Coyote repository (every top-level field, every node type). - [Agents](Agents) - non-graph agent system (config.yaml + LLM loop) - [Custom Tools](Custom-Tools) - building `tools.sh` / `tools.py` / diff --git a/Home.md b/Home.md index 3781828..e791962 100644 --- a/Home.md +++ b/Home.md @@ -1,16 +1,16 @@ -Welcome to the Loki Wiki! +Welcome to the Coyote Wiki! -A helpful way to use this wiki is to create a RAG from it and then ask questions about Loki, with Loki! Here's an example -on how to create a RAG from this wiki and then ask a question about Loki: +A helpful way to use this wiki is to create a RAG from it and then ask questions about Coyote, with Coyote! Here's an example +on how to create a RAG from this wiki and then ask a question about Coyote: -![Loki RAG](images/loki_rag.png) +![Coyote RAG](images/coyote_rag.png) --- -Loki is an all-in-one, batteries-included, LLM CLI tool featuring Shell Assistant, CLI & REPL Mode, RAG, AI Tools & +Coyote is an all-in-one, batteries-included, LLM CLI tool featuring Shell Assistant, CLI & REPL Mode, RAG, AI Tools & Agents, and More. -It is designed to include a number of useful agents, roles, macros, and more so users can get up and running with Loki +It is designed to include a number of useful agents, roles, macros, and more so users can get up and running with Coyote in as little time as possible. ![Agent example](./images/agents/sql.gif) @@ -21,41 +21,41 @@ Coming from [AIChat](https://github.com/sigoden/aichat)? Follow the [migration g # Quick Links * [AIChat Migration Guide](AIChat-Migration): Coming from AIChat? Follow the migration guide to get started. -* [Installation](Installation): Install Loki -* [Getting Started](Getting-Started): Get started with Loki by doing first-run setup steps, and learn the basics. +* [Installation](Installation): Install Coyote +* [Getting Started](Getting-Started): Get started with Coyote by doing first-run setup steps, and learn the basics. * [Sharing Configurations](Sharing-Configurations): Install bundles of agents, roles, macros, tools, and MCP servers from any git repo, and share your own. -* [REPL](REPL): Interactive Read-Eval-Print Loop for conversational interactions with LLMs and Loki. +* [REPL](REPL): Interactive Read-Eval-Print Loop for conversational interactions with LLMs and Coyote. * [Custom REPL Prompt](REPL-Prompt): Customize the REPL prompt to provide useful contextual information. * [Vault](Vault): Securely store and manage sensitive information such as API keys and credentials. -* [Shell Integrations](Shell-Integrations): Seamlessly integrate Loki with your shell environment for enhanced command-line assistance. -* [Function Calling](Tools#Tools): Leverage function calling capabilities to extend Loki's functionality with custom tools - * [Creating Custom Tools](Custom-Tools): You can create your own custom tools to enhance Loki's capabilities. +* [Shell Integrations](Shell-Integrations): Seamlessly integrate Coyote with your shell environment for enhanced command-line assistance. +* [Function Calling](Tools#Tools): Leverage function calling capabilities to extend Coyote's functionality with custom tools + * [Creating Custom Tools](Custom-Tools): You can create your own custom tools to enhance Coyote's capabilities. * [Create Custom Python Tools](Custom-Tools#custom-python-based-tools) * [Create Custom TypeScript Tools](Custom-Tools#custom-typescript-based-tools) * [Create Custom Bash Tools](Custom-Bash-Tools) * [Bash Prompt Utilities](Bash-Prompt-Helpers) * [First-Class MCP Server Support](MCP-Servers): Easily connect and interact with MCP servers for advanced functionality. -* [Macros](Macros): Automate repetitive tasks and workflows with Loki "scripts" (macros). +* [Macros](Macros): Automate repetitive tasks and workflows with Coyote "scripts" (macros). * [RAG](RAG): Retrieval-Augmented Generation for enhanced information retrieval and generation. * [Sessions](Sessions): Manage and persist conversational contexts and settings across multiple interactions. * [Roles](Roles): Customize model behavior for specific tasks or domains. * [Agents](Agents): Leverage AI agents to perform complex tasks and workflows, including sub-agent spawning, teammate messaging, and user interaction tools. * [Graph Agents](Graph-Agents): Define an agent as a declarative, YAML-driven workflow. A directed graph of typed nodes (LLM calls, scripts, approvals, user input, RAG retrieval, sub-agent spawns). * [Todo System](TODO-System): Built-in task tracking for improved agent reliability with smaller models. -* [Environment Variables](Environment-Variables): Override and customize your Loki configuration at runtime with environment variables. +* [Environment Variables](Environment-Variables): Override and customize your Coyote configuration at runtime with environment variables. * [Client Configurations](Clients): Configuration instructions for various LLM providers. * [Authentication (API Key & OAuth)](Clients#authentication): Authenticate with API keys or OAuth for subscription-based access. * [Patching API Requests](Patches): Learn how to patch API requests for advanced customization. -* [Custom Themes](Themes): Change the look and feel of Loki to your preferences with custom themes. -* [History](#history): A history of how Loki came to be. +* [Custom Themes](Themes): Change the look and feel of Coyote to your preferences with custom themes. +* [History](#history): A history of how Coyote came to be. --- # History -Loki began as a fork of [AIChat CLI](https://github.com/sigoden/aichat) and has since evolved into an independent project. +Coyote began as a fork of [AIChat CLI](https://github.com/sigoden/aichat) and has since evolved into an independent project. -See [CREDITS](https://github.com/Dark-Alex-17/loki/CREDITS.md) for full attribution and background. +See [CREDITS](https://github.com/Dark-Alex-17/coyote/CREDITS.md) for full attribution and background. --- diff --git a/Installation.md b/Installation.md index 95acae7..aa553f5 100644 --- a/Installation.md +++ b/Installation.md @@ -1,5 +1,5 @@ # Prerequisites -Loki requires the following tools to be installed on your system: +Coyote requires the following tools to be installed on your system: * [jq](https://github.com/jqlang/jq) * `brew install jq` * [usql](https://github.com/xo/usql) (For the `sql` agent) @@ -8,57 +8,57 @@ Loki requires the following tools to be installed on your system: * [uv](https://docs.astral.sh/uv/getting-started/installation/) * `curl -LsSf https://astral.sh/uv/install.sh | sh` -These tools are used to provide various functionalities within Loki, such as document processing, JSON manipulation, +These tools are used to provide various functionalities within Coyote, such as document processing, JSON manipulation, and they are used within agents and tools. # Install ## Cargo -If you have Cargo installed, then you can install `loki` from Crates.io: +If you have Cargo installed, then you can install `coyote` from Crates.io: ```shell -cargo install loki-ai # Binary name is `loki` +cargo install coyote-ai # Binary name is `coyote` # If you encounter issues installing, try installing with '--locked' -cargo install --locked loki-ai +cargo install --locked coyote-ai ``` ## Homebrew (Mac/Linux) -To install Loki from Homebrew, install the `loki` tap. Then you'll be able to install `loki`: +To install Coyote from Homebrew, install the `coyote` tap. Then you'll be able to install `coyote`: ```shell -brew tap Dark-Alex-17/loki -brew install loki +brew tap Dark-Alex-17/coyote +brew install coyote # If you need to be more specific, use: -brew install Dark-Alex-17/loki/loki +brew install Dark-Alex-17/coyote/coyote ``` -To upgrade `loki` using Homebrew: +To upgrade `coyote` using Homebrew: ```shell -brew upgrade loki +brew upgrade coyote ``` ## Scripts ### Linux/MacOS (`bash`) -You can use the following command to run a bash script that downloads and installs the latest version of `loki` for your +You can use the following command to run a bash script that downloads and installs the latest version of `coyote` for your OS (Linux/MacOS) and architecture (x86_64/arm64): ```shell -curl -fsSL https://raw.githubusercontent.com/Dark-Alex-17/loki/main/install_loki.sh | bash +curl -fsSL https://raw.githubusercontent.com/Dark-Alex-17/coyote/main/install_coyote.sh | bash ``` ### Windows/Linux/MacOS (`PowerShell`) -You can use the following command to run a PowerShell script that downloads and installs the latest version of `loki` +You can use the following command to run a PowerShell script that downloads and installs the latest version of `coyote` for your OS (Windows/Linux/MacOS) and architecture (x86_64/arm64): ```powershell -powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://raw.githubusercontent.com/Dark-Alex-17/loki/main/scripts/install_loki.ps1 | iex" +powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://raw.githubusercontent.com/Dark-Alex-17/coyote/main/scripts/install_coyote.ps1 | iex" ``` ## Manual -Binaries are available on the [releases](https://github.com/Dark-Alex-17/loki/releases) page for the following platforms: +Binaries are available on the [releases](https://github.com/Dark-Alex-17/coyote/releases) page for the following platforms: | Platform | Architecture(s) | |----------------|-----------------| @@ -69,47 +69,47 @@ Binaries are available on the [releases](https://github.com/Dark-Alex-17/loki/re ### Windows Instructions To use a binary from the releases page on Windows, do the following: -1. Download the latest [binary](https://github.com/Dark-Alex-17/loki/releases) for your OS. +1. Download the latest [binary](https://github.com/Dark-Alex-17/coyote/releases) for your OS. 2. Use 7-Zip or TarTool to unpack the Tar file. -3. Run the executable `loki.exe`! +3. Run the executable `coyote.exe`! ### Linux/MacOS Instructions To use a binary from the releases page on Linux/MacOS, do the following: -1. Download the latest [binary](https://github.com/Dark-Alex-17/loki/releases) for your OS. +1. Download the latest [binary](https://github.com/Dark-Alex-17/coyote/releases) for your OS. 2. `cd` to the directory where you downloaded the binary. -3. Extract the binary with `tar -C /usr/local/bin -xzf loki-.tar.gz` (Note: This may require `sudo`) -4. Now you can run `loki`! +3. Extract the binary with `tar -C /usr/local/bin -xzf coyote-.tar.gz` (Note: This may require `sudo`) +4. Now you can run `coyote`! -# Updating Loki +# Updating Coyote -Loki can update itself in place. Running: +Coyote can update itself in place. Running: ```shell -loki --update +coyote --update ``` downloads the latest release from GitHub for your operating system and -architecture, replaces the running `loki` binary, and reports the new version. -Restart Loki afterwards for the update to take effect. +architecture, replaces the running `coyote` binary, and reports the new version. +Restart Coyote afterwards for the update to take effect. To update to a specific release instead of the latest, pass a version. Either pass the bare version or the `v`-prefixed tag: ```shell -loki --update v0.4.0 +coyote --update v0.4.0 # or -loki --update 0.4.0 +coyote --update 0.4.0 ``` -If Loki is already on the requested version, it reports that and makes no +If Coyote is already on the requested version, it reports that and makes no changes. ## Package-manager installs -If Loki was installed with Homebrew or `cargo install`, replacing the binary in +If Coyote was installed with Homebrew or `cargo install`, replacing the binary in place would leave your package manager's records out of sync with the file on -disk. When `loki --update` detects one of these installs it prints a warning +disk. When `coyote --update` detects one of these installs it prints a warning and: * in an interactive terminal, asks for confirmation before continuing; @@ -117,56 +117,56 @@ and: passed. ```shell -loki --update --force +coyote --update --force ``` For Homebrew and Cargo installs the recommended way to update remains your package manager: ```shell -brew upgrade loki # Homebrew -cargo install --locked loki-ai # Cargo +brew upgrade coyote # Homebrew +cargo install --locked coyote-ai # Cargo ``` ## Permissions -`loki --update` replaces the binary at its current location. If that directory -is not writable by your user (for example a `loki` placed in `/usr/local/bin` +`coyote --update` replaces the binary at its current location. If that directory +is not writable by your user (for example a `coyote` placed in `/usr/local/bin` by `root`), the update stops before downloading anything and asks you to re-run with elevated permissions (e.g. with `sudo`) or to update through your package manager. -Loki can also be updated from within the REPL using the +Coyote can also be updated from within the REPL using the [`.update` command](REPL). # Tab-Completions -You can also enable tab completions to make using Loki easier. To do so, add the following to your shell profile: +You can also enable tab completions to make using Coyote easier. To do so, add the following to your shell profile: ```shell # Bash # (add to: `~/.bashrc`) -source <(COMPLETE=bash loki) +source <(COMPLETE=bash coyote) # Zsh # (add to: `~/.zshrc`) -source <(COMPLETE=zsh loki) +source <(COMPLETE=zsh coyote) # Fish # (add to: `~/.config/fish/config.fish`) -source <(COMPLETE=fish loki | psub) +source <(COMPLETE=fish coyote | psub) # Elvish # (add to: `~/.elvish/rc.elv`) -eval (E:COMPLETE=elvish loki | slurp) +eval (E:COMPLETE=elvish coyote | slurp) # PowerShell # (add to: `$PROFILE`) $env:COMPLETE = "powershell" -loki | Out-String | Invoke-Expression +coyote | Out-String | Invoke-Expression ``` # Shell Integration -You can integrate Loki's Shell Assistant into your shell for enhanced command-line assistance. Add the code in the -corresponding [shell integration script](https://github.com/Dark-Alex-17/loki/tree/main/scripts/shell-integration) to your shell. Then, you can invoke Loki to convert natural language to +You can integrate Coyote's Shell Assistant into your shell for enhanced command-line assistance. Add the code in the +corresponding [shell integration script](https://github.com/Dark-Alex-17/coyote/tree/main/scripts/shell-integration) to your shell. Then, you can invoke Coyote to convert natural language to shell commands by pressing `Alt-e`. For example: ```shell diff --git a/MCP-Servers.md b/MCP-Servers.md index 9796527..9b55703 100644 --- a/MCP-Servers.md +++ b/MCP-Servers.md @@ -4,9 +4,9 @@ tools for the model to access and extend its capabilities. So think of it like this: Instead of having to write all your own custom tools to interact with different services, those services can expose their functionality through an MCP server. -Loki has first-class support for MCP servers. +Coyote has first-class support for MCP servers. -As mentioned in the [Loki Vault documentation](Vault), Loki can inject sensitive +As mentioned in the [Coyote Vault documentation](Vault), Coyote can inject sensitive configuration data into your MCP configuration file to ensure that secrets are not hard-coded. --- @@ -17,28 +17,28 @@ number of configured MCP servers, enabling too many MCP servers may overwhelm th and quickly exceed token limits. # MCP Server Configuration -Loki stores the MCP server configuration file, `functions/mcp.json`, in the `functions` directory. You can find +Coyote stores the MCP server configuration file, `functions/mcp.json`, in the `functions` directory. You can find this directory using the following command: ```shell -loki --info | grep functions_dir | awk '{print $2}' +coyote --info | grep functions_dir | awk '{print $2}' ``` The syntax for the `functions/mcp.json` file matches [Claude Code's `.mcp.json` configuration format](https://docs.claude.com/en/docs/claude-code/mcp), -with one small difference: the `type` field is **always required** in Loki, even for stdio servers (Claude Code +with one small difference: the `type` field is **always required** in Coyote, even for stdio servers (Claude Code allows it to be omitted and infers `stdio` from the presence of a `command`). So any time you're looking to add a new server, look at its docs and find the Claude Code configuration example. You should be able to use the exact same configuration in your `functions/mcp.json` file. Just make sure every entry has an explicit `type`. -**Note:** Loki does not support Claude Code's `"streamable-http"` alias (use `"http"` instead), nor extras -like `oauth` or `envFile`. For secrets, use [Loki Vault](Vault) interpolation rather than Claude Code's `${VAR}` +**Note:** Coyote does not support Claude Code's `"streamable-http"` alias (use `"http"` instead), nor extras +like `oauth` or `envFile`. For secrets, use [Coyote Vault](Vault) interpolation rather than Claude Code's `${VAR}` shell-style expansion. Every server entry **must** include a `"type"` field set to one of: `"stdio"`, `"http"`, or `"sse"`. ## Transport Types -Loki supports three MCP transport types: +Coyote supports three MCP transport types: | Type | Use Case | |---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -48,7 +48,7 @@ Loki supports three MCP transport types: ## Stdio Servers -Stdio is the standard transport for locally-installed MCP servers. Loki spawns the process and communicates +Stdio is the standard transport for locally-installed MCP servers. Coyote spawns the process and communicates over stdin/stdout: ```json @@ -125,15 +125,15 @@ protocol with the server. The `type` field primarily serves as documentation of server speaks. Neither type supports `command`, `args`, or `cwd` fields. ## Secret Injection -As mentioned in the [Loki Vault documentation](Vault), you can use Loki Vault to inject secrets into your MCP configuration file. +As mentioned in the [Coyote Vault documentation](Vault), you can use Coyote Vault to inject secrets into your MCP configuration file. -In fact, this is why you need to set up your vault before using Loki at all: the built-in MCP configuration +In fact, this is why you need to set up your vault before using Coyote at all: the built-in MCP configuration requires you set up some secrets to use it. -For more information about how to set up your vault and inject secrets, please refer to the [Loki Vault documentation](Vault). +For more information about how to set up your vault and inject secrets, please refer to the [Coyote Vault documentation](Vault). # Default MCP Servers -Loki ships with a `functions/mcp.json` file that includes some useful MCP servers: +Coyote ships with a `functions/mcp.json` file that includes some useful MCP servers: * [atlassian](https://github.com/atlassian/atlassian-mcp-server) - Interact with and manage Atlassian tools like Confluence and Jira. * [github](https://github.com/github/github-mcp-server) - Interact with GitHub repositories, issues, pull requests, and more. @@ -143,11 +143,11 @@ Loki ships with a `functions/mcp.json` file that includes some useful MCP server The `mcp.json` file is created from a bundled template on first run and is never overwritten afterward. It is your own configuration to edit freely. To discard your changes and restore the bundled template (for example, to pick up new -default servers after a Loki update), run `loki --install mcp_config` (or `.install mcp_config` in the REPL). **This is +default servers after a Coyote update), run `coyote --install mcp_config` (or `.install mcp_config` in the REPL). **This is destructive:** it replaces your entire `mcp.json`, including your configured servers and any secret references in them, with the bundled template. -# Loki Configuration +# Coyote Configuration MCP servers, like tools, can be used in a handful of contexts: * Inside a session * Inside a role @@ -158,11 +158,11 @@ Each of these has a different configuration and interaction with the global conf ***Note:** The names of each MCP server referenced in the below configuration properties directly corresponds to the names given in the `functions/mcp.json` configuration file. So if you change the name of an MCP server -from `slack` to `lucem-slack`, then you need to also update your Loki configuration accordingly. +from `slack` to `lucem-slack`, then you need to also update your Coyote configuration accordingly. ## Global Configuration The global configuration is essentially what settings you want to have on by default when -you just invoke `loki`. (Don't worry about agents, roles, or sessions yet. We'll get to them in a bit). +you just invoke `coyote`. (Don't worry about agents, roles, or sessions yet. We'll get to them in a bit). The following settings are available in the global configuration for MCP servers: @@ -176,7 +176,7 @@ enabled_mcp_servers: null # Which MCP servers to enable by default (e.g. A special note about `enabled_mcp_servers`: a user can set this to `all` to enable all configured MCP servers in the `functions/mcp.json` configuration. -(See the [Configuration Example](https://github.com/Dark-Alex-17/loki/blob/main/config.example.yaml) file for an example global configuration with all options.) +(See the [Configuration Example](https://github.com/Dark-Alex-17/coyote/blob/main/config.example.yaml) file for an example global configuration with all options.) When running in REPL-mode, the `mcp_server_support` and `enabled_mcp_servers` settings can be overridden using the `.set` command: @@ -207,4 +207,4 @@ The values for `mapping_mcp_servers` are inherited from the [global configuratio For more information about agents, refer to the [Agents](Agents) documentation. -For a full example configuration for an agent, see the [Agent Configuration Example](https://github.com/Dark-Alex-17/loki/blob/main/config.agent.example.yaml) file. +For a full example configuration for an agent, see the [Agent Configuration Example](https://github.com/Dark-Alex-17/coyote/blob/main/config.agent.example.yaml) file. diff --git a/Macros.md b/Macros.md index 4f79994..5926b1c 100644 --- a/Macros.md +++ b/Macros.md @@ -1,4 +1,4 @@ -Macros are essentially Loki "scripts"; that is, a predefined sequence of REPL commands that automate repetitive tasks or +Macros are essentially Coyote "scripts"; that is, a predefined sequence of REPL commands that automate repetitive tasks or workflows. Macros run in isolated environments, ensuring that the macros don't inherit any pre-existing role, session, RAG, or agent state, and they will not affect your current context. @@ -6,17 +6,17 @@ This isolation ensures that your workspace remains clean and unaffected by macro ![Macro Example](./images/macros/macros-example.gif) -For more information on Loki's REPL, refer to the [REPL](REPL) documentation. +For more information on Coyote's REPL, refer to the [REPL](REPL) documentation. --- # Macro Definition -Macros are defined as YAML files in the `macros` subdirectory of your Loki configuration directory. The Loki configuration +Macros are defined as YAML files in the `macros` subdirectory of your Coyote configuration directory. The Coyote configuration directory can vary between systems, so to find the location of your macros config directory, you can use the following command: ```shell -loki --info | grep 'macros_dir' | awk '{print $2}' +coyote --info | grep 'macros_dir' | awk '{print $2}' ``` Macro definitions are broken into two parts: the `steps` of the macro, and an optional `variables` section that lets @@ -34,30 +34,30 @@ steps: ``` Usage: ```shell -$ loki --macro generate-commit-message +$ coyote --macro generate-commit-message >> .file `git diff` -- generate a git commit message Add documentation on macros ``` -For a full example configuration, refer to the [example macro configuration file](https://github.com/Dark-Alex-17/loki/blob/main/config.macro.example.yaml) in the root of this project. +For a full example configuration, refer to the [example macro configuration file](https://github.com/Dark-Alex-17/coyote/blob/main/config.macro.example.yaml) in the root of this project. ## Macro Variables Sometimes it's useful to be able to modify the behavior of a macro at runtime. This is achieved with the `variables` array of the macro definition. -To pass variables to a macro, since they are just Loki scripts, the syntax is the same as it is for any other scripting +To pass variables to a macro, since they are just Coyote scripts, the syntax is the same as it is for any other scripting language: You just pass them alongside your invocation. **Example:** ```shell -$ loki --macro example-variable-macro first_argument second_argument +$ coyote --macro example-variable-macro first_argument second_argument ``` Each variable in the `variables` array has the following properties: * `name` (Required): the name of the variable, which can be referenced in the actual steps of the macro using the `{{name}}` syntax. * `default` (Optional): A default value for the variable if no value is specified. If no default value is defined, and - no value is provided for the variable at runtime, Loki will error out. + no value is provided for the variable at runtime, Coyote will error out. * `rest` (Optional, Boolean): When set to `true`, this variable will collect all remaining arguments passed to the macro. This behavior is only applicable when the variable is the last variable in the list. By default, this is `false`. @@ -79,20 +79,20 @@ steps: ``` Usage: ```shell -$ loki --macro invoke-agent sql +$ coyote --macro invoke-agent sql # or -$ loki --macro invoke-agent sql What tables are available? +$ coyote --macro invoke-agent sql What tables are available? ``` -For a full example configuration, refer to the [example macro configuration file](https://github.com/Dark-Alex-17/loki/blob/main/config.macro.example.yaml) in the root of this project. +For a full example configuration, refer to the [example macro configuration file](https://github.com/Dark-Alex-17/coyote/blob/main/config.macro.example.yaml) in the root of this project. # Built-In Macros -Loki comes packaged with some useful built-in macros. These are also good examples if you're looking for more examples -on how to make your own macros, so be sure to check out the [built-in macro definitions](https://github.com/Dark-Alex-17/loki/blob/main/assets/macros) if you're +Coyote comes packaged with some useful built-in macros. These are also good examples if you're looking for more examples +on how to make your own macros, so be sure to check out the [built-in macro definitions](https://github.com/Dark-Alex-17/coyote/blob/main/assets/macros) if you're looking for more examples. * `generate-commit-message` - Generate a Git commit message based on the staged changes in the current directory Built-in macros are written to your macros directory on first run and never overwritten afterward, so your edits are -preserved across Loki updates. To discard local changes and reinstall the built-in macros from the current Loki build, -run `loki --install macros` (or `.install macros` in the REPL). Macros you created yourself are not affected. +preserved across Coyote updates. To discard local changes and reinstall the built-in macros from the current Coyote build, +run `coyote --install macros` (or `.install macros` in the REPL). Macros you created yourself are not affected. diff --git a/Patches.md b/Patches.md index 1c2989a..445643a 100644 --- a/Patches.md +++ b/Patches.md @@ -1,4 +1,4 @@ -Loki provides two mechanisms for modifying API requests sent to LLM providers: **Model-Specific Patches** and +Coyote provides two mechanisms for modifying API requests sent to LLM providers: **Model-Specific Patches** and **Client Configuration Patches**. These allow you to customize request parameters, headers, and URLs to work around provider quirks or add custom behavior. @@ -86,7 +86,7 @@ Add authentication or custom headers: ``` ## How It Works -1. When you use a model, Loki loads its configuration +1. When you use a model, Coyote loads its configuration 2. If the model has a `patch` field, it's **always applied** to every request 3. The patch modifies the request URL, body, or headers before sending to the API 4. Parameters set to `null` are **removed** from the request @@ -235,7 +235,7 @@ clients: ``` ## How It Works -1. When making a request, Loki checks if the client has a `patch` configuration +1. When making a request, Coyote checks if the client has a `patch` configuration 2. It looks at the appropriate API type (`chat_completions`, `embeddings`, or `rerank`) 3. For each pattern in that section, it checks if the regex matches the model name 4. If a match is found, that patch is applied to the request @@ -332,7 +332,7 @@ patch: You can also apply patches via environment variables for temporary overrides: ```bash -export LOKI_PATCH_OPENAI_CHAT_COMPLETIONS='{"gpt-4.*":{"body":{"temperature":0.5}}}' +export COYOTE_PATCH_OPENAI_CHAT_COMPLETIONS='{"gpt-4.*":{"body":{"temperature":0.5}}}' ``` This takes precedence over client configuration patches but not model-specific patches. @@ -351,8 +351,8 @@ This takes precedence over client configuration patches but not model-specific p To see what request is actually being sent, enable debug logging: ```bash -export RUST_LOG=loki=debug -loki "your prompt here" +export RUST_LOG=coyote=debug +coyote "your prompt here" ``` This will show the final request body after all patches are applied. diff --git a/RAG.md b/RAG.md index 811b953..54c89aa 100644 --- a/RAG.md +++ b/RAG.md @@ -2,19 +2,19 @@ Retrieval Augmented Generation (RAG) is a method of minimizing LLM hallucination without consuming a significant portion of the context length. It uses documents and other additional resources that you provide to give the model more context for all of your prompts. -Loki has a built-in vector database and full-text search engine to support RAG knowledge bases for your queries. +Coyote has a built-in vector database and full-text search engine to support RAG knowledge bases for your queries. -The generated knowledge bases are stored in the `rag` subdirectory of your Loki configuration directory. The location of +The generated knowledge bases are stored in the `rag` subdirectory of your Coyote configuration directory. The location of this directory varies by system, so you can use the following command to find your RAG directory: ```shell -loki --info | grep 'rags_dir' | awk '{print $2}' +coyote --info | grep 'rags_dir' | awk '{print $2}' ``` --- # Usage -There's two ways to use RAG in Loki: A persistent RAG that can be loaded on-demand for queries, and an ephemeral one for +There's two ways to use RAG in Coyote: A persistent RAG that can be loaded on-demand for queries, and an ephemeral one for adding RAG to a single specific query. ## Persistent RAG @@ -22,14 +22,14 @@ In the REPL, persistent RAG is initialized via the `.rag` command: ![Persistent RAG example](./images/rag/persistent-rag.gif) -The generated RAG is then saved to the `rag` subdirectory of the Loki configuration, and can then be loaded whenever you -want that knowledge base via either `.rag ` or `loki --rag `. +The generated RAG is then saved to the `rag` subdirectory of the Coyote configuration, and can then be loaded whenever you +want that knowledge base via either `.rag ` or `coyote --rag `. ## Ephemeral RAG Short-lived RAG that is only used for a single session or query is loaded using `.file`/`--file`. You can use it to either execute a prompt from a file, or for temporary RAG. The difference is the usage of the `--` -separator. If you only specify a filename and no `--` separator, Loki will know to read the file contents and pass them +separator. If you only specify a filename and no `--` separator, Coyote will know to read the file contents and pass them as a query to the model. Otherwise, the `--` separator is read to indicate that this is the end of the list of documents to load into the ephemeral RAG, and what follows is the query to pass to the model. @@ -54,7 +54,7 @@ This value references the content of the last reply. So you can use it like this The `--` indicates that this is the end of your documents and the beginning of your prompt. ### The `cmd` Document Type -Loki also lets you use command outputs for ephemeral RAG input. Simply enclose the command in backticks: +Coyote also lets you use command outputs for ephemeral RAG input. Simply enclose the command in backticks: ```shell .file `git diff` -- generate a commit message @@ -64,17 +64,17 @@ The `--` indicates that this is the end of your documents and the beginning of y # How It Works ### 1. Build -When you define RAG, Loki will first "build" the RAG. This means that Loki will consume the documents you specified and -generate [embeddings](https://huggingface.co/spaces/hesamation/primer-llm-embedding) for that text. This essentially just means that Loki translates the document into a language +When you define RAG, Coyote will first "build" the RAG. This means that Coyote will consume the documents you specified and +generate [embeddings](https://huggingface.co/spaces/hesamation/primer-llm-embedding) for that text. This essentially just means that Coyote translates the document into a language the LLM can understand. These embeddings are then stored in an in-memory vector database. ### 2. Lookup -Loki sits between you and the model. So when you submit a prompt to the model, before Loki ever sends it, it will first +Coyote sits between you and the model. So when you submit a prompt to the model, before Coyote ever sends it, it will first convert your prompt into embeddings (LLM language), and look for relevant snippets of text in the vector database. -Loki then passes the top `n`-snippets of text that it finds in the vector database as additional context to the model +Coyote then passes the top `n`-snippets of text that it finds in the vector database as additional context to the model before your prompt. ### 2a. Reranking (Optional) @@ -86,7 +86,7 @@ Reranking improves these initial results (say, the top 20-100 text snippets) and sophisticated model. The reranker model will rank documents by their actual usefulness for answering the query to ensure the most relevant context is passed to the model alongside your query. -This reranking model can be customized for each RAG you build in Loki. See the [Custom Reranker](#reranker) section +This reranking model can be customized for each RAG you build in Coyote. See the [Custom Reranker](#reranker) section below for more details on how to customize this. ### 3. Prompt @@ -94,32 +94,32 @@ Finally, the text snippets that were looked up in RAG are passed to the model as giving the model query-specific context to answer your question. # Supported Document Sources -Loki supports a number of document sources that can be used for RAG: +Coyote supports a number of document sources that can be used for RAG: | Source | Example | Comments | |--------------------------|-----------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------| | Files | `/tmp/dir1/file1;/tmp/dir1/file2` | | | Directory | `/tmp/dir` | Picks up all files in a directory and all its subdirectories | | Directory (extensions} | `/tmp/dir2/**/*.{md,txt}` | Finds all files in all subdirectories with the specified extensions | -| Recursive Filename | `/tmp/*/LOKI.md` | The following files will be picked up:
  • `/tmp/dir1/LOKI.md`
  • `/tmp/dir2/subdir1/LOKI.md`
  • `/tmp/dir2/subdir2/LOKI.md`
| +| Recursive Filename | `/tmp/*/COYOTE.md` | The following files will be picked up:
  • `/tmp/dir1/COYOTE.md`
  • `/tmp/dir2/subdir1/COYOTE.md`
  • `/tmp/dir2/subdir2/COYOTE.md`
| | URL | `https://www.ohdsi.org/data-standardization/` | Downloads and loads the specified webpage into the
knowledge base | | Recursive URL (Websites) | `https://github.com/OHDSI/Vocabulary-v5.0/wiki/**` | Crawls all pages under the given URL and loads them
into the knowledge base | | Document Loader (custom) | `jina:https://cloud.google.com/bigquery/docs/reference/standard-sql/` | Use a custom document loader to parse the given document | # Document Loaders -Loki only has built-in support for loading text files. But that functionality can be extended to read all kinds of files +Coyote only has built-in support for loading text files. But that functionality can be extended to read all kinds of files into your knowledge bases. These custom loaders are used by both RAG and for documents specified using the `.file`/`--file` flags. In the global configuration file, you can specify loaders for specific document types using the `document_loaders` -setting. Each loader is defined by specifying a name and then a command that Loki will execute to load the document. +setting. Each loader is defined by specifying a name and then a command that Coyote will execute to load the document. -The following variables are interpolated at runtime by Loki and can be used as placeholders in your command definitions: +The following variables are interpolated at runtime by Coyote and can be used as placeholders in your command definitions: * `$1` (Required) - The input file * `$2` (Optional) - The output file. If omitted, `stdout` is used as the output destination -**Note:** It is your responsibility to ensure that any tools used to parse documents into text that Loki can read are -installed on your system and are available on your `$PATH`. Loki does not have any built-in way of installing +**Note:** It is your responsibility to ensure that any tools used to parse documents into text that Coyote can read are +installed on your system and are available on your `$PATH`. Coyote does not have any built-in way of installing dependencies for document loaders for you. The following are some example loaders: @@ -130,13 +130,13 @@ document_loaders: docx: 'pandoc --to plain $1' # Use pandoc to convert a .docx file to text # (see https://pandoc.org for details on how to install pandoc) jina: 'curl -fsSL https://r.jina.ai/$1 -H "Authorization: Bearer {{JINA_API_KEY}}' # Use Jina to translate a website into text; - # Requires a Jina API key to be added to the Loki vault + # Requires a Jina API key to be added to the Coyote vault git: > # Use yek to load a git repository into the knowledgebase (https://github.com/bodo-run/yek) sh -c "yek $1 --json | jq 'map({ path: .filename, contents: .content })'" ``` ## Document Loader Usage -Once you have your loaders defined, you can specify when Loki should use them by prefixing any RAG file/directory/URI +Once you have your loaders defined, you can specify when Coyote should use them by prefixing any RAG file/directory/URI with the name of the loader. **Example: Load a git repo into RAG** @@ -144,26 +144,26 @@ with the name of the loader. **Example: Use pdf loader for ephemeral RAG** ```shell -$ loki --file pdf:some-file.pdf +$ coyote --file pdf:some-file.pdf ``` # Advanced Customizations -For those familiar with RAG, Loki exposes a handful of advanced global settings that can be used to tweak your default +For those familiar with RAG, Coyote exposes a handful of advanced global settings that can be used to tweak your default RAG configurations. ## Embedding Model -When Loki queries your RAG knowledge bases, it needs to first convert your query into embeddings. By default, Loki uses +When Coyote queries your RAG knowledge bases, it needs to first convert your query into embeddings. By default, Coyote uses the same embedding model that was used to create the knowledge base in the first place. This can be customized to any other embedding model available in your configured clients by setting the -`rag_embedding_model` setting in your global Loki configuration file: +`rag_embedding_model` setting in your global Coyote configuration file: ```yaml rag_embedding_model: null # Specifies the embedding model used for context retrieval ``` ## Reranker -By default, Loki uses [Reciprocal Rank Fusion (RRF)](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion) to merge vector and keyword search results. +By default, Coyote uses [Reciprocal Rank Fusion (RRF)](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion) to merge vector and keyword search results. You can change the default reranker model to any other reranking model in your configured clients. To change the default reranker model, simply change the value of the `rag_reranker_model` setting in your global configuration file: @@ -174,7 +174,7 @@ rag_reranker_model: null # By default, ## Chunk Size In the context of RAG, the chunk size is the maximum length of each text chunk (measured in characters) that is created -when splitting documents. In Loki, this defaults to `2000` characters. +when splitting documents. In Coyote, this defaults to `2000` characters. You can specify a different global default by setting the `rag_chunk_size` property in your global configuration file: @@ -209,8 +209,8 @@ like this: Often, this value is 10%-20% of the chunk size. -By default, in Loki, this value is 5% the chunk size. You can override this and specify the default chunk overlap (in -characters) that Loki should use as a global default by setting the `rag_chunk_overlap` property in the global Loki +By default, in Coyote, this value is 5% the chunk size. You can override this and specify the default chunk overlap (in +characters) that Coyote should use as a global default by setting the `rag_chunk_overlap` property in the global Coyote configuration file: ```yaml @@ -221,7 +221,7 @@ rag_chunk_overlap: null # Defines the overlap between chunks In RAG, `top_k` represents the top `k`-chunks to return from the vector database query. Think of it like if you search something on Google and only care about the top 10 results, that's what you'll use for your context. -In Loki, the default value for this is `5`. You can customize this global default by setting the `rag_top_k` property in +In Coyote, the default value for this is `5`. You can customize this global default by setting the `rag_top_k` property in your global configuration file: ```yaml @@ -236,9 +236,9 @@ When customizing this value, keep in mind the following trade-offs so you get th potential context window constraints ## RAG Template -When you use RAG in Loki, after Loki performs the lookup for relevant chunks of text to add as context to your query, it +When you use RAG in Coyote, after Coyote performs the lookup for relevant chunks of text to add as context to your query, it will add the retrieved text chunks as context to your query before sending it to the model. The format of this context -is determined by the `rag_template` setting in your global Loki configuration file. +is determined by the `rag_template` setting in your global Coyote configuration file. This template utilizes three placeholders: * `__INPUT__`: The user's actual query @@ -249,7 +249,7 @@ These placeholders are replaced with the corresponding values into the template the model at query-time. The `__SOURCES__` placeholder enables the model to cite which documents its answer is based on, which is especially useful when building knowledge-base assistants that need to provide verifiable references. -The default template that Loki uses is the following: +The default template that Coyote uses is the following: ```text Answer the query based on the context while respecting the rules. (user query, some textual context and rules, all inside xml tags) @@ -277,6 +277,6 @@ __INPUT__ ``` -You can customize this template by specifying the `rag_template` setting in your global Loki configuration file. Your +You can customize this template by specifying the `rag_template` setting in your global Coyote configuration file. Your template *must* include both the `__INPUT__` and `__CONTEXT__` placeholders in order for it to be valid. The `__SOURCES__` placeholder is optional. If it is omitted, source references will not be included in the prompt. diff --git a/REPL-Prompt.md b/REPL-Prompt.md index c8edbd8..47a0ff3 100644 --- a/REPL-Prompt.md +++ b/REPL-Prompt.md @@ -1,5 +1,5 @@ -The prompt you see when you start the Loki REPL can be customized to your liking. This is achieved via the `left_prompt` -and `right_prompt` settings in the global Loki configuration file: +The prompt you see when you start the Coyote REPL can be customized to your liking. This is achieved via the `left_prompt` +and `right_prompt` settings in the global Coyote configuration file: ```yaml left_prompt: '{color.red}{model}){color.green}{?session {?agent {agent}>}{session}{?role /}}{!session {?agent {agent}>}}{role}{?rag @{rag}}{color.cyan}{?session )}{!session >}{color.reset} ' @@ -10,7 +10,7 @@ The location of the global configuration file differs between systems, so you ca global configuration file's location: ```shell -loki --info | grep 'config_file' | awk '{print $2}' +coyote --info | grep 'config_file' | awk '{print $2}' ``` # Syntax diff --git a/REPL.md b/REPL.md index e43d9a5..40d4fd9 100644 --- a/REPL.md +++ b/REPL.md @@ -1,12 +1,12 @@ -In addition to being a CLI, Loki also has a built-in REPL (Read-Execute-Print-Loop). This enables users to quickly try +In addition to being a CLI, Coyote also has a built-in REPL (Read-Execute-Print-Loop). This enables users to quickly try out prompts, commands, configurations, and everything in between without having to modify the same command every time. -You can enter the REPL by simply typing `loki` without any follow-up flags or arguments. +You can enter the REPL by simply typing `coyote` without any follow-up flags or arguments. --- # Features -The REPL has features that are intended to make your Loki experience as easy and as enjoyable as possible! This includes +The REPL has features that are intended to make your Coyote experience as easy and as enjoyable as possible! This includes things like * **Tab Autocompletion:** Every command in the REPL (i.e. everything that starts with a `.`) has fuzzy search auto @@ -34,7 +34,7 @@ things like # REPL Commands All REPL commands begin with a `.` to indicate that they're not part of a prompt. The following list details the -commands available in Loki: +commands available in Coyote: ## `.model` - Change the current LLM When browsing models in the REPL, use the following legend to understand the purpose of each column in the model table: @@ -51,10 +51,10 @@ openai:gpt-4o 128000 / 4096 | 5 / 15 👁 ⚒ ``` ![model](./images/repl/model.gif) -For more information about how to add models to Loki, refer to the [clients documentation](Clients). +For more information about how to add models to Coyote, refer to the [clients documentation](Clients). ## `.role` - Role management -Loki offers the following commands to manage your roles: +Coyote offers the following commands to manage your roles: | Command | Description | |--------------|-------------------------------------------------------------------------| @@ -66,7 +66,7 @@ Loki offers the following commands to manage your roles: ![role](./images/roles/code.gif) -For more information about roles in Loki and how to build them, refer to the [roles documentation](Roles). +For more information about roles in Coyote and how to build them, refer to the [roles documentation](Roles). ## `.prompt` - Set a temporary role using a prompt If you need to create a temporary role that you want to discard after use, you use `.prompt`. `.prompt`-based roles @@ -75,7 +75,7 @@ cannot be persisted to a file and saved. ![prompt-role](./images/roles/prompt-role.gif) ## `.session` - Session management -Use the following commands to manage sessions in Loki: +Use the following commands to manage sessions in Coyote: | Command | Description | |---------------------|---------------------------------------------------------------------------------------------| @@ -89,11 +89,11 @@ Use the following commands to manage sessions in Loki: ![sessions](./images/sessions/sessions-example.gif) -For more information on sessions and how to use them in Loki, refer to the [sessions documentation](Sessions). +For more information on sessions and how to use them in Coyote, refer to the [sessions documentation](Sessions). ## `.agent` - Chat with an AI agent -Loki lets you build OpenAI GPT-style agents. The following commands let you interact with and manage your agents in -Loki: +Coyote lets you build OpenAI GPT-style agents. The following commands let you interact with and manage your agents in +Coyote: | Command | Description | |----------------------|-------------------------------------------------------------------| @@ -105,7 +105,7 @@ Loki: ![agent](./images/agents/sql.gif) -For more information on agents in Loki and how to create them, refer to the [agents documentation](Agents). +For more information on agents in Coyote and how to create them, refer to the [agents documentation](Agents). ## `.clear todo` - Clear the todo list Clears the todo list and stops auto-continuation. This command is available in any context (agents, sessions, @@ -133,19 +133,19 @@ complete tasks using the documents as additional context. ![rag](./images/rag/persistent-rag.gif) -For more information about RAG in Loki and how to utilize it, refer to the [rag documentation](RAG). +For more information about RAG in Coyote and how to utilize it, refer to the [rag documentation](RAG). ## `.macro` - Execute a macro -Macros in Loki are like "scripts" of commands that can be run in isolated environments; that means they do not use any +Macros in Coyote are like "scripts" of commands that can be run in isolated environments; that means they do not use any active settings and use the same settings they had when written. They are created/executed using the `.macro ` command. ![macro](./images/macros/macros-example.gif) -For more information on macros in Loki and how to create them, refer to the [macros documentation](Macros). +For more information on macros in Coyote and how to create them, refer to the [macros documentation](Macros). ## `.file` - Read files and use them as input -Loki lets you specify any number of documents that you can load and use as ephemeral RAG to chat with the LLM. To see +Coyote lets you specify any number of documents that you can load and use as ephemeral RAG to chat with the LLM. To see what files or values you can pass to it, simply run the command `.file` with no arguments: ```shell @@ -157,13 +157,13 @@ Usage: .file ... [-- ...] For more information about ephemeral RAG, refer to the [ephemeral RAG documentation](RAG#ephemeral-rag). -## `.vault` - Manage the Loki vault -The Loki vault lets users store sensitive secrets and credentials securely so that there's no plaintext secrets +## `.vault` - Manage the Coyote vault +The Coyote vault lets users store sensitive secrets and credentials securely so that there's no plaintext secrets anywhere in your configurations. ![vault](./images/vault/vault-demo.gif) -For more information about the Loki vault, refer to the [vault documentation](Vault). +For more information about the Coyote vault, refer to the [vault documentation](Vault). ## `.continue` - Continue the previous response When you have a response that exceeds the context length, you can use the `.continue` command to continue the generation @@ -185,7 +185,7 @@ last response to your system clipboard: ## `.set` - Adjust runtime settings You can use `.set` to adjust select settings at runtime. This is useful when you're experimenting with settings and want -to know how they'll affect Loki. To persist the changes you make, be sure to update them in the global configuration +to know how they'll affect Coyote. To persist the changes you make, be sure to update them in the global configuration file. The following settings can be adjusted at runtime: @@ -223,8 +223,8 @@ configuration in your preferred text editor. It lets you modify the following co * `.edit agent-config` - Modify the active agent's configuration * `.edit rag-docs` - Add or remove documents from the active RAG -## `.delete` - Delete configurations from Loki -The `.delete` command allows you to delete entities in Loki without having to directly run `rm -rf` on the configuration +## `.delete` - Delete configurations from Coyote +The `.delete` command allows you to delete entities in Coyote without having to directly run `rm -rf` on the configuration directory or file corresponding to the target entity. You can use it to delete the following entities: * `.delete role` - Delete select roles @@ -234,9 +234,9 @@ directory or file corresponding to the target entity. You can use it to delete t * `.delete agent-data` - Delete select agent's configurations and all tools ## `.install` - Reinstall bundled assets -Loki's built-in agents, macros, and tool functions (and an MCP config template) are written to your configuration -directory on first run and are **not** overwritten afterward, so your local edits survive Loki updates. The `.install` -command force-overwrites a category of bundled assets with the versions packaged in the current Loki build. This is useful +Coyote's built-in agents, macros, and tool functions (and an MCP config template) are written to your configuration +directory on first run and are **not** overwritten afterward, so your local edits survive Coyote updates. The `.install` +command force-overwrites a category of bundled assets with the versions packaged in the current Coyote build. This is useful when an update ships improved built-ins you want to adopt. | Command | Description | @@ -246,19 +246,19 @@ when an update ships improved built-ins you want to adopt. | `.install functions` | Reinstall the built-in tool functions (leaves your `mcp.json` alone) | | `.install mcp_config` | Replace `mcp.json` with the bundled template (see warning below) | -The same operation is available from the command line: `loki --install ` (e.g. `loki --install agents`). +The same operation is available from the command line: `coyote --install ` (e.g. `coyote --install agents`). `.install` prompts for confirmation before overwriting anything. Assets you created yourself are never touched. Only -Loki's own bundled assets are replaced. +Coyote's own bundled assets are replaced. **Warning:** `.install mcp_config` is destructive in a way the others are not. It replaces your entire `mcp.json` -(your configured MCP servers and any secret references in them) with Loki's bundled template. The other categories -only overwrite Loki's built-in assets and leave your custom ones alone. +(your configured MCP servers and any secret references in them) with Coyote's bundled template. The other categories +only overwrite Coyote's built-in assets and leave your custom ones alone. ## `.install remote` - Install assets from a git repository The `.install remote` command installs agents, roles, macros, tools, and MCP servers from any git repository whose -layout mirrors Loki's user config directory. This is the primary mechanism for sharing and reusing Loki configurations. +layout mirrors Coyote's user config directory. This is the primary mechanism for sharing and reusing Coyote configurations. | Command | Description | |--------------------------------------------------------------------|------------------------------------------------------------| @@ -267,14 +267,14 @@ layout mirrors Loki's user config directory. This is the primary mechanism for s | `.install remote --filter ` | Restrict to one of `agents`, `roles`, `macros`, `functions`, `mcp_config` | | `.install remote --force` | Skip all conflict prompts; overwrite local files unconditionally | -The CLI equivalent is `loki --install-from ` (with `--filter` and `--install-force` accepting the same values). +The CLI equivalent is `coyote --install-from ` (with `--filter` and `--install-force` accepting the same values). See [Sharing Configurations](Sharing-Configurations) for the expected repo layout, conflict resolution, secret handling, -and the [loki-config-template](https://github.com/Dark-Alex-17/loki-config-template) starter you can fork. +and the [coyote-config-template](https://github.com/Dark-Alex-17/coyote-config-template) starter you can fork. -## `.update` - Update Loki +## `.update` - Update Coyote -The `.update` command updates the Loki binary itself to the latest release, +The `.update` command updates the Coyote binary itself to the latest release, without leaving the REPL to run a separate installer. | Command | Description | @@ -283,22 +283,22 @@ without leaving the REPL to run a separate installer. | `.update latest` | Update to the latest release | | `.update ` | Update to a specific release (e.g. `.update v0.4.0`) | -A version may be given either bare (`0.4.0`) or `v`-prefixed (`v0.4.0`). If Loki +A version may be given either bare (`0.4.0`) or `v`-prefixed (`v0.4.0`). If Coyote is already on the requested version, it says so and makes no changes; otherwise it downloads the matching build, replaces the binary, and reports the new -version. **Restart Loki** for the update to take effect. +version. **Restart Coyote** for the update to take effect. -If Loki was installed via Homebrew or `cargo install`, `.update` prints a +If Coyote was installed via Homebrew or `cargo install`, `.update` prints a warning (updating in place desyncs your package manager) and asks for -confirmation before continuing; for those installs, prefer `brew upgrade loki` -or `cargo install --locked loki-ai`. +confirmation before continuing; for those installs, prefer `brew upgrade coyote` +or `cargo install --locked coyote-ai`. `.update` cannot be run from inside a macro. The same operation is available on -the command line as `loki --update`. For full CLI details, including the +the command line as `coyote --update`. For full CLI details, including the `--force` flag for non-interactive updates, see the [Installation documentation](Installation). ## `.info` - Display information about the current mode -The `.info` command provides useful information about different modes that Loki may be operating in. It's helpful if you +The `.info` command provides useful information about different modes that Coyote may be operating in. It's helpful if you want a quick understanding of the system info, a role's configuration, an agent's configuration, etc. The following entities are supported: @@ -314,10 +314,10 @@ The following entities are supported: ## `.authenticate` - Authenticate the current model client via OAuth The `.authenticate` command will start the OAuth flow for the current model client if * The client supports OAuth (See the [clients documentation](Clients#providers-that-support-oauth) for supported clients) -* The client is configured in your Loki configuration to use OAuth via the `auth: oauth` property +* The client is configured in your Coyote configuration to use OAuth via the `auth: oauth` property -## `.exit` - Exit an agent/role/session/rag or the Loki REPL itself -The `.exit` command is used to move between modes in the Loki REPL. +## `.exit` - Exit an agent/role/session/rag or the Coyote REPL itself +The `.exit` command is used to move between modes in the Coyote REPL. | Command | Description | |-----------------|-------------------------| @@ -325,7 +325,7 @@ The `.exit` command is used to move between modes in the Loki REPL. | `.exit session` | Exit the active session | | `.exit agent` | Exit the active agent | | `.exit rag` | Exit the active RAG | -| `.exit` | Exit the Loki REPL | +| `.exit` | Exit the Coyote REPL | ## `.help` - Show the help guide Just like with any shell or REPL, you sometimes need a little help and want to know what commands are available to you. diff --git a/Roles.md b/Roles.md index 8eea525..9f83925 100644 --- a/Roles.md +++ b/Roles.md @@ -11,12 +11,12 @@ grown up so we don't have to wait! --- # Role Definition -Roles in Loki are Markdown files that live in the `roles` directory of your Loki configuration. Loki configuration +Roles in Coyote are Markdown files that live in the `roles` directory of your Coyote configuration. Coyote configuration locations vary between systems, so you can use the following command to find the location of your roles configuration directory: ```shell -loki --info | grep 'roles_dir' | awk '{print $2}' +coyote --info | grep 'roles_dir' | awk '{print $2}' ``` All role configuration files have two parts: The metadata header, and the instructions. @@ -36,7 +36,7 @@ enabled_mcp_servers: github You are an expert resume builder. ``` -To see a full example configuration for a role, refer to the [example role configuration](https://github.com/Dark-Alex-17/loki/blob/main/config.role.example.md) +To see a full example configuration for a role, refer to the [example role configuration](https://github.com/Dark-Alex-17/coyote/blob/main/config.role.example.md) file in the root of the repo. ## Metadata Header @@ -45,7 +45,7 @@ for each role that make the model work the way you want for your role. This incl always use a specific model, set of tools, and tailoring the hyperparameters of the model for your role. The header consists of a YAML-formatted list of settings that let you customize the model behavior for your role. These -settings sit between `---` separators in your role configuration so Loki knows they're not part of the instructions you +settings sit between `---` separators in your role configuration so Coyote knows they're not part of the instructions you want to feed the model. The following table lists the available configuration settings and their default values (if undefined): @@ -66,14 +66,14 @@ The following table lists the available configuration settings and their default ## Instructions The instructions for a role is what you use to tell the model how you want it to behave. This typically consists of one -or two sentences, but can be more. To see some examples, look at the [built-in roles](https://github.com/Dark-Alex-17/loki/blob/main/assets/roles) to see how they are defined. +or two sentences, but can be more. To see some examples, look at the [built-in roles](https://github.com/Dark-Alex-17/coyote/blob/main/assets/roles) to see how they are defined. **Pro-Tip:** The struggle to create good instructions for a role (or any other kind of instructions for your model) is -so common, that Loki comes with a role to help you write instructions for roles! Simply invoke the role to start +so common, that Coyote comes with a role to help you write instructions for roles! Simply invoke the role to start creating a role with the `create-prompt` role: ```shell -loki -r create-prompt +coyote -r create-prompt ``` ## Special Case: Metadata Header Only @@ -101,12 +101,12 @@ enabled_mcp_servers: github For more examples of this special use case of roles, you can look at the role configuration files for the following built-in roles: -* [explain-shell](https://github.com/Dark-Alex-17/loki/blob/main/assets/roles/explain-shell.md) - Explains cryptic shell commands in natural language -* [functions](https://github.com/Dark-Alex-17/loki/blob/main/assets/roles/functions.md) - Enables all available functions (i.e. all globally `visible_functions`) -* [mcp-servers](https://github.com/Dark-Alex-17/loki/blob/main/assets/roles/mcp-servers.md) - Enables all available MCP servers +* [explain-shell](https://github.com/Dark-Alex-17/coyote/blob/main/assets/roles/explain-shell.md) - Explains cryptic shell commands in natural language +* [functions](https://github.com/Dark-Alex-17/coyote/blob/main/assets/roles/functions.md) - Enables all available functions (i.e. all globally `visible_functions`) +* [mcp-servers](https://github.com/Dark-Alex-17/coyote/blob/main/assets/roles/mcp-servers.md) - Enables all available MCP servers # Special Variables -Loki has a set of built-in special variables that it will inject into your role's instructions if it finds them in the +Coyote has a set of built-in special variables that it will inject into your role's instructions if it finds them in the `{{variable_name}}` syntax. The available special variables are listed below: | Name | Description | Example | @@ -120,14 +120,14 @@ Loki has a set of built-in special variables that it will inject into your role' | `__cwd__` | The current working directory | `/tmp` | # Prompt Types -In Loki, you can also create roles with pre-configured prompts so you can template prompts for your use cases. This is +In Coyote, you can also create roles with pre-configured prompts so you can template prompts for your use cases. This is the purpose of the `prompt` field in the role's metadata header. There's three types of prompts you can create: ## Embedded Prompts Embedded prompts let you create templated prompts for any input given to it. They are ideal for concise, input-driven -replies from the model. The input that users pass to Loki are injected into your prompt via a `__INPUT__` placeholder in +replies from the model. The input that users pass to Coyote are injected into your prompt via a `__INPUT__` placeholder in your prompt. **Example: Role to convert the given input to TOML** @@ -140,7 +140,7 @@ Convert the given input to TOML format. Exclude any markdown formatting or code ``` Usage: ```shell -$ loki -r json-to-toml '{"test":"hi me"}' +$ coyote -r json-to-toml '{"test":"hi me"}' test = "hi me" ``` @@ -169,7 +169,7 @@ Convert all given input words into emojis ``` Usage: ```shell -$ loki -r emoji music joy +$ coyote -r emoji music joy 🎵 😊 ``` @@ -185,7 +185,7 @@ messages for the model: ## Few-Shot Prompt [Few-Shot prompting](https://www.promptingguide.ai/techniques/fewshot) is a technique to enable in-context learning for LLMs by providing examples in the prompt to steer -the model to better performance. In Loki, this is done as an extension of System Prompts. +the model to better performance. In Coyote, this is done as an extension of System Prompts. **Example: Role to output code only** `roles/code-generator.md` @@ -206,7 +206,7 @@ Output code only in response to the user's request ~~~ Usage: ~~~shell -$ loki -r code-generator python add two numbers +$ coyote -r code-generator python add two numbers ```python # Function to add two numbers def add_numbers(num1, num2): @@ -234,12 +234,12 @@ messages for the model: ``` # Built-In Roles -Loki comes packaged with some useful built-in roles. These are also good examples if you're looking for more examples on -how to make your own roles, so be sure to check out the [built-in role definitions](https://github.com/Dark-Alex-17/loki/blob/main/assets/roles) if you're looking +Coyote comes packaged with some useful built-in roles. These are also good examples if you're looking for more examples on +how to make your own roles, so be sure to check out the [built-in role definitions](https://github.com/Dark-Alex-17/coyote/blob/main/assets/roles) if you're looking for more examples. * `atlassian`: Interact with Atlassian products (Jira, Confluence) using natural language -* `code`: Generates code (used by `loki -c`) +* `code`: Generates code (used by `coyote -c`) * `create-prompt`: Creates a prompt based on the user's input * `create-title`: Creates 3-6 word titles based on the user's input * `explain-shell`: Explains shell commands @@ -247,11 +247,11 @@ for more examples. * `github`: Interact with GitHub using natural language * `mcp-servers`: Enables all MCP servers * `repo-analyzer`: Ask questions about the code repository in the current working directory -* `shell`: Convert natural language into shell commands (used by `loki -e`) +* `shell`: Convert natural language into shell commands (used by `coyote -e`) * `slack`: Interact with Slack using natural language # Temporary Roles -Loki also enables you to create temporary roles that will be discarded once you're finished with them. This is done via +Coyote also enables you to create temporary roles that will be discarded once you're finished with them. This is done via the `.prompt/--prompt` command: ![prompt role](./images/roles/prompt-role.gif) diff --git a/Sessions.md b/Sessions.md index dfbee01..2999333 100644 --- a/Sessions.md +++ b/Sessions.md @@ -1,22 +1,22 @@ -By default, Loki does not send back all previous messages in a conversation to the model. This means that each time you -query a model, it's essentially a one-off. However, Loki does support chat-like conversations with LLMs via its +By default, Coyote does not send back all previous messages in a conversation to the model. This means that each time you +query a model, it's essentially a one-off. However, Coyote does support chat-like conversations with LLMs via its `sessions` mechanism. -Sessions in Loki enable the familiar conversational interactions with LLMs. This means you can reference previous +Sessions in Coyote enable the familiar conversational interactions with LLMs. This means you can reference previous answers and ask follow-up questions and the model will know what you're referring to. Sessions can be temporary, or can be saved so you can continue conversations at a later time. -Saved sessions are stored in the `sessions` subdirectory of the Loki configuration directory. The location of the +Saved sessions are stored in the `sessions` subdirectory of the Coyote configuration directory. The location of the `sessions` directory varies by system, so you can use the following command to find the `sessions` directory if you need it: ```shell -loki --info | grep 'sessions_dir' | awk '{print $2}' +coyote --info | grep 'sessions_dir' | awk '{print $2}' ``` # Usage -When you use a session in Loki, you can either persist it or discard it once you're done. Sessions you discard are then +When you use a session in Coyote, you can either persist it or discard it once you're done. Sessions you discard are then just considered 'temporary' sessions. ![Persistent Session Example](./images/sessions/sessions-example.gif) @@ -28,25 +28,25 @@ will be available again when you continue that session. # Auto-Saved Sessions When `save_session` is set to `true` and you don't provide an explicit session name (i.e., you're in a temporary -session), Loki will automatically save your session when you exit. These auto-saved sessions behave differently from +session), Coyote will automatically save your session when you exit. These auto-saved sessions behave differently from manually saved sessions in a few important ways. ## How Auto-Save Works -When you exit a temporary session with `save_session: true`, Loki: +When you exit a temporary session with `save_session: true`, Coyote: 1. Saves the session to a `_/` subdirectory inside the sessions directory (e.g., - `~/.config/loki/sessions/_/`). + `~/.config/coyote/sessions/_/`). 2. Generates a timestamped filename in the format `YYYYMMDDTHHmmSS` (e.g., `20260508T120838`). 3. If an auto-generated name is available (see [Auto-Naming](#auto-naming) below), it is appended to the timestamp (e.g., `20260508T120838-discuss-rust-error-handling.yaml`). For agent sessions, auto-saved sessions are stored in the agent's own session directory under `_/` (e.g., -`~/.config/loki/agents//sessions/_/`). +`~/.config/coyote/agents//sessions/_/`). ## Auto-Naming -When `save_session: true` is set and you send your first message in a temporary session, Loki will use the LLM to +When `save_session: true` is set and you send your first message in a temporary session, Coyote will use the LLM to automatically generate a short descriptive name for the session based on the initial exchange. This name is appended to the timestamp in the filename, making it easier to identify sessions later. @@ -62,7 +62,7 @@ session list: To access auto-saved sessions, prefix your query with `_/`: -- **`.session _/` + Tab (REPL)**: **Will** show auto-saved sessions in completions, since Loki looks in the +- **`.session _/` + Tab (REPL)**: **Will** show auto-saved sessions in completions, since Coyote looks in the `_/` subdirectory when it sees this prefix. - **`.session _/` (REPL)**: Loads a specific auto-saved session. For example: `.session _/20260508T120838-discuss-rust-error-handling`. @@ -77,7 +77,7 @@ You can force a single session to be saved regardless of the global `save_sessio CLI flag: ```shell -loki --session --save-session "What is Rust?" +coyote --session --save-session "What is Rust?" ``` This overrides the configured `save_session` value for that one invocation only, and the session will auto-save to the @@ -97,19 +97,19 @@ session type: | `null` | Any | CLI | Does not save | # Configuration -Session behavior can be configured from the global Loki configuration file. The location of this file varies between +Session behavior can be configured from the global Coyote configuration file. The location of this file varies between systems so you can use the following command to locate it on your system: ```shell -loki --info | grep 'config_file' | awk '{print $2}' +coyote --info | grep 'config_file' | awk '{print $2}' ``` The following settings are available to customize the default behavior of sessions globally: | Setting | Description | |--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `save_session` | Controls the persistence of the session.
  • If `true`, then any time you're in a session, changes will auto-save unless explicitly defined otherwise.
  • If `false`, then any time you're in a session, changes will not auto-save unless explicitly specified otherwise.
  • If `null`, Loki will always prompt the user for what to do.
| -| `compression_threshold` | Defines the token count threshold at which Loki will compress the session to save on the context length | +| `save_session` | Controls the persistence of the session.
  • If `true`, then any time you're in a session, changes will auto-save unless explicitly defined otherwise.
  • If `false`, then any time you're in a session, changes will not auto-save unless explicitly specified otherwise.
  • If `null`, Coyote will always prompt the user for what to do.
| +| `compression_threshold` | Defines the token count threshold at which Coyote will compress the session to save on the context length | | `summarization_prompt` | This is the prompt that is used to compress the session up to a given point when compression is triggered | | `summary_context_prompt` | This is the prompt that's used to add the summarized conversation generated by the `summarization_prompt` as context to the model | diff --git a/Sharing-Configurations.md b/Sharing-Configurations.md index 9064e79..126eefe 100644 --- a/Sharing-Configurations.md +++ b/Sharing-Configurations.md @@ -1,21 +1,21 @@ -Loki ships with a built-in mechanism for installing and sharing configurations (i.e. agents, roles, macros, tools, and MCP +Coyote ships with a built-in mechanism for installing and sharing configurations (i.e. agents, roles, macros, tools, and MCP servers) directly from any git repository. This makes it easy to: -- Sync your Loki setup across multiple machines. +- Sync your Coyote setup across multiple machines. - Share your work with teammates or the community. - Bootstrap a new install with a curated set of assets. - Pin to specific versions for reproducibility. The relevant commands: -- CLI: `loki --install-from ` +- CLI: `coyote --install-from ` - REPL: `.install remote ` This page covers the expected repository layout, command-line flags, conflict resolution, secrets handling, and how to publish your own shareable bundle. To see a template repository with all recognized categories, see the -[loki-config-template](https://github.com/Dark-Alex-17/loki-config-template) repository. +[coyote-config-template](https://github.com/Dark-Alex-17/coyote-config-template) repository. --- @@ -24,23 +24,23 @@ To see a template repository with all recognized categories, see the Install everything from a remote repo: ```sh -loki --install-from https://github.com/Dark-Alex-17/loki-config-template +coyote --install-from https://github.com/Dark-Alex-17/coyote-config-template ``` -or from inside the Loki REPL: +or from inside the Coyote REPL: ``` -.install remote https://github.com/Dark-Alex-17/loki-config-template +.install remote https://github.com/Dark-Alex-17/coyote-config-template ``` -That's it. Loki clones the repo to a temp directory, scans for recognized asset categories, and installs each into the +That's it. Coyote clones the repo to a temp directory, scans for recognized asset categories, and installs each into the matching subdirectory of your user config. The temp clone is removed on completion. --- ## Expected repository layout -Loki recognizes these top-level directories. Anything outside them is ignored. +Coyote recognizes these top-level directories. Anything outside them is ignored. ``` / @@ -68,7 +68,7 @@ A few things to note: - **`.git/` is excluded** from the scan automatically. - **Symlinks are rejected** by the install walker as a defense-in-depth measure. - **`functions/bin/` and `functions/utils/` are not recognized** (compiled at runtime / not in scope for sharing). -- **The whole `config.yaml`** (global Loki config) is **not** shared (see [What is not shared](#what-is-not-shared)). +- **The whole `config.yaml`** (global Coyote config) is **not** shared (see [What is not shared](#what-is-not-shared)). --- @@ -77,12 +77,12 @@ A few things to note: Pin the install to a specific tag, branch, or commit by appending `#` to the URL. ```sh -loki --install-from https://github.com//#v1.2.3 -loki --install-from https://github.com//#main -loki --install-from https://github.com//#abc1234 +coyote --install-from https://github.com//#v1.2.3 +coyote --install-from https://github.com//#main +coyote --install-from https://github.com//#abc1234 ``` -How Loki resolves the ref: +How Coyote resolves the ref: - **Branch or tag names** are passed as `--branch ` to a shallow `git clone --depth 1`. - **Commit SHAs** (4-40 hex characters) trigger a full clone followed by `git checkout `. @@ -106,8 +106,8 @@ Restrict the install to a single asset category with `--filter`: | `mcp_config` | `functions/mcp.json` only (merged) | ```sh -loki --install-from --filter agents -loki --install-from --filter mcp_config +coyote --install-from --filter agents +coyote --install-from --filter mcp_config ``` REPL form: @@ -127,7 +127,7 @@ When an install file would overwrite an existing local file with different conte ### Plain files (agents, roles, macros, tools) -In a terminal (TTY), Loki prompts per conflicting file: +In a terminal (TTY), Coyote prompts per conflicting file: | Option | Effect | |----------------|------------------------------------------------------------------------------| @@ -143,7 +143,7 @@ non-interactively, you must pass `--install-force`. ### Identical content is not a conflict -If a remote file's bytes match your local copy exactly, Loki silently treats it as `identical` and skips it. Re-running +If a remote file's bytes match your local copy exactly, Coyote silently treats it as `identical` and skips it. Re-running the same install is idempotent. ### File-mode (`+x`) handling @@ -156,7 +156,7 @@ Scripts written into `functions/tools/` are automatically marked executable base ## MCP configuration merge `functions/mcp.json` is the exception to the per-file conflict model. Instead of replacing your local file outright, -Loki **merges** the remote `mcp.json` into your existing one. +Coyote **merges** the remote `mcp.json` into your existing one. ### Merge behavior @@ -168,7 +168,7 @@ Loki **merges** the remote `mcp.json` into your existing one. |-------------------------------------|---------------------------------------------------------------------| | `keep local` | Leave your existing entry alone. | | `take remote` | Overwrite with the remote entry. | -| `rename remote as "-remote"` | Insert the remote entry under a suffixed key. If the suffixed key is also taken, Loki appends `-2`, `-3`, etc. | +| `rename remote as "-remote"` | Insert the remote entry under a suffixed key. If the suffixed key is also taken, Coyote appends `-2`, `-3`, etc. | | `abort merge` | Stop the merge with an error. No partial write. | With `--install-force`, every conflict is resolved by taking the remote entry. In non-TTY mode without @@ -178,7 +178,7 @@ With `--install-force`, every conflict is resolved by taking the remote entry. I Each added, replaced, or renamed entry is validated against the MCP server schema (e.g., `stdio` servers must have a `command`; `http`/`sse` servers must have a `url`) before the merged file is written. A validation failure aborts the -install. Loki will **never** write a partially-validated `mcp.json`. +install. Coyote will **never** write a partially-validated `mcp.json`. ### Atomic write @@ -190,12 +190,12 @@ that a crash or interrupt mid-write will not corrupt your existing `mcp.json`. ## Secrets handling MCP server entries (and other config files) can reference vault secrets with `{{SECRET_NAME}}` placeholders. After the -install completes, Loki scans the resulting `mcp.json` for placeholders that are not yet in your vault and either: +install completes, Coyote scans the resulting `mcp.json` for placeholders that are not yet in your vault and either: -- **In a TTY:** prompts you, one secret at a time, whether to add it to the vault now. On the first "Yes", Loki +- **In a TTY:** prompts you, one secret at a time, whether to add it to the vault now. On the first "Yes", Coyote initializes the vault password file (if needed). On "No", the secret is deferred and reported at the end. - **In a non-TTY environment:** skips prompts entirely; lists every missing secret in a final reminder block, with the - commands you can run later (`loki --add-secret ` or `.vault add `). + commands you can run later (`coyote --add-secret ` or `.vault add `). Both modes always print a final summary distinguishing secrets added from those deferred. See [Vault](Vault) for the full secrets workflow. @@ -204,7 +204,7 @@ full secrets workflow. ## Git authentication -Loki shells out to your local `git` binary to clone the remote repository. This means it inherits **your existing git +Coyote shells out to your local `git` binary to clone the remote repository. This means it inherits **your existing git authentication setup** with no additional configuration: - **SSH URLs** (`git@github.com:owner/repo.git`) use your `ssh-agent`, `~/.ssh/config`, and SSH keys. @@ -218,11 +218,11 @@ If `git` is not on your `PATH`, you'll get a clear error message on the first in ## Publishing your own bundle -To share your Loki configuration, structure a git repo like the template above and push it to GitHub, GitLab, your +To share your Coyote configuration, structure a git repo like the template above and push it to GitHub, GitLab, your self-hosted Forgejo instance, etc. The easiest way to start is to **fork the official template repo**: -[`loki-config-template`](https://github.com/Dark-Alex-17/loki-config-template). It includes a working sample of each +[`coyote-config-template`](https://github.com/Dark-Alex-17/coyote-config-template). It includes a working sample of each asset type plus a `README` describing the customization workflow. ### Best practices @@ -231,12 +231,12 @@ asset type plus a `README` describing the customization workflow. 2. **Keep per-agent logic in `agents//`**. Only put global tools in `functions/tools/`. 3. **Use `{{SECRET}}` placeholders** for any sensitive value in `mcp.json`. Never commit a real API key. 4. **Document expected secrets** in your repo's `README` so users know which vault entries to add. -5. **Avoid name collisions** with Loki's bundled assets (`agents/code-reviewer`, `agents/sql`, etc.) unless you +5. **Avoid name collisions** with Coyote's bundled assets (`agents/code-reviewer`, `agents/sql`, etc.) unless you specifically want to replace them. Pick distinctive names for your shared assets. -6. **Test installs against a clean `LOKI_CONFIG_DIR`** before publishing. You can use: +6. **Test installs against a clean `COYOTE_CONFIG_DIR`** before publishing. You can use: ```sh - LOKI_CONFIG_DIR=$(mktemp -d) loki --install-from file:///path/to/your/clone --install-force + COYOTE_CONFIG_DIR=$(mktemp -d) coyote --install-from file:///path/to/your/clone --install-force ``` --- @@ -245,16 +245,16 @@ asset type plus a `README` describing the customization workflow. The following are **intentionally** outside the install-remote feature's scope: -- **`config.yaml`** (the global Loki config). It holds user-specific things like editor preference, vault password file +- **`config.yaml`** (the global Coyote config). It holds user-specific things like editor preference, vault password file path, client API keys, OAuth tokens, and similar. Merging a shared `config.yaml` would risk breaking auth or routing traffic somewhere unexpected. Settings that genuinely benefit from sharing (like default models) already belong inside individual agents' or roles' configs. -- **Sessions, RAGs, agent runtime data.** These accumulate as you use Loki and aren't shareable in a meaningful way. +- **Sessions, RAGs, agent runtime data.** These accumulate as you use Coyote and aren't shareable in a meaningful way. - **`functions/bin/`:** Agent script binaries built at runtime, not part of the source layout. - **`functions/utils/`:** Utility scripts intentionally not part of the share contract. If a team really needs synced global settings, the recommended approach is dotfiles-style symlinks or a sync tool. -Those are designed for that problem and not for `loki --install-from`. +Those are designed for that problem and not for `coyote --install-from`. --- @@ -263,45 +263,45 @@ Those are designed for that problem and not for `loki --install-from`. ### Install everything from a public repo ```sh -loki --install-from https://github.com/Dark-Alex-17/loki-config-template +coyote --install-from https://github.com/Dark-Alex-17/coyote-config-template ``` ### Pin to a release tag ```sh -loki --install-from https://github.com/your-org/loki-config#v2.4.0 +coyote --install-from https://github.com/your-org/coyote-config#v2.4.0 ``` ### Install only the agents from a fork ```sh -loki --install-from https://github.com/your-org/loki-config --filter agents +coyote --install-from https://github.com/your-org/coyote-config --filter agents ``` ### Install only the MCP servers, force-replace conflicts ```sh -loki --install-from https://github.com/your-org/loki-config --filter mcp_config --install-force +coyote --install-from https://github.com/your-org/coyote-config --filter mcp_config --install-force ``` ### From the REPL ``` -.install remote https://github.com/your-org/loki-config -.install remote https://github.com/your-org/loki-config#main --filter agents -.install remote https://github.com/your-org/loki-config --force +.install remote https://github.com/your-org/coyote-config +.install remote https://github.com/your-org/coyote-config#main --filter agents +.install remote https://github.com/your-org/coyote-config --force ``` ### From a private SSH URL ```sh -loki --install-from git@github.com:your-org/private-loki-config.git#v1.0.0 +coyote --install-from git@github.com:your-org/private-coyote-config.git#v1.0.0 ``` ### From a local file:// URL (testing your own template) ```sh -loki --install-from file:///home/you/code/my-loki-config +coyote --install-from file:///home/you/code/my-coyote-config ``` --- @@ -310,10 +310,10 @@ loki --install-from file:///home/you/code/my-loki-config ### "git failed: ..." -The remote clone failed. Loki passes git's stderr through verbatim. The most common causes: +The remote clone failed. Coyote passes git's stderr through verbatim. The most common causes: - **Authentication required**: `fatal: could not read username/password` or `Permission denied (publickey)`. Verify - your git credentials work for the same URL outside Loki by running `git clone ` manually. + your git credentials work for the same URL outside Coyote by running `git clone ` manually. - **Network failure**: `Could not resolve host` or similar. Check connectivity. - **Invalid ref**: `couldn't find remote ref `. Verify the tag/branch/commit exists in the remote. @@ -334,8 +334,8 @@ Same pattern as the above, but for the MCP merge. Use `--install-force` to take ### Missing secrets after install -Add them via `loki --add-secret ` (CLI) or `.vault add ` (REPL). See [Vault](Vault) for details. +Add them via `coyote --add-secret ` (CLI) or `.vault add ` (REPL). See [Vault](Vault) for details. ### `git` binary not found -Loki shells out to the system `git` binary. Install git for your platform and ensure it's on your `PATH`. +Coyote shells out to the system `git` binary. Install git for your platform and ensure it's on your `PATH`. diff --git a/Shell-Integrations.md b/Shell-Integrations.md index 2102fea..4a4942c 100644 --- a/Shell-Integrations.md +++ b/Shell-Integrations.md @@ -1,32 +1,32 @@ -Loki supports the following integrations with a handful of shell environments to enhance user experience and streamline workflows. +Coyote supports the following integrations with a handful of shell environments to enhance user experience and streamline workflows. # Tab Completions ## Dynamic -Dynamic tab completions are supported by Loki to assist users in quickly completing commands, options, and arguments. +Dynamic tab completions are supported by Coyote to assist users in quickly completing commands, options, and arguments. You can enable it by using the corresponding command for your shell. To enable dynamic tab completions for every shell session (i.e. persistently), add the corresponding command to your shell's configuration file as indicated: ```shell # Bash # (add to: `~/.bashrc`) -source <(COMPLETE=bash loki) +source <(COMPLETE=bash coyote) # Zsh # (add to: `~/.zshrc`) -source <(COMPLETE=zsh loki) +source <(COMPLETE=zsh coyote) # Fish # (add to: `~/.config/fish/config.fish`) -source <(COMPLETE=fish loki | psub) +source <(COMPLETE=fish coyote | psub) # Elvish # (add to: `~/.elvish/rc.elv`) -eval (E:COMPLETE=elvish loki | slurp) +eval (E:COMPLETE=elvish coyote | slurp) # PowerShell # (add to: `$PROFILE`) $env:COMPLETE = "powershell" -loki | Out-String | Invoke-Expression +coyote | Out-String | Invoke-Expression ``` At the time of writing, `nushell` is not yet fully supported for dynamic tab completions due to limitations @@ -42,34 +42,34 @@ will enable them for every shell session (i.e. persistently): ```shell # Bash -echo 'source <(loki --completions bash)' >> ~/.bashrc +echo 'source <(coyote --completions bash)' >> ~/.bashrc # Zsh -echo 'source <(loki --completions zsh)' >> ~/.zshrc +echo 'source <(coyote --completions zsh)' >> ~/.zshrc # Fish -echo 'loki --completions fish | source' >> ~/.config/fish/config.fish +echo 'coyote --completions fish | source' >> ~/.config/fish/config.fish # Elvish -echo 'eval (loki --completions elvish | slurp)' >> ~/.elvish/rc.elv +echo 'eval (coyote --completions elvish | slurp)' >> ~/.elvish/rc.elv # Nushell [[ -d ~/.config/nushell/completions ]] || mkdir -p ~/.config/nushell/completions -loki --completions nushell | save -f ~/.config/nushell/completions/loki.nu +coyote --completions nushell | save -f ~/.config/nushell/completions/coyote.nu echo 'use ~/.config/nushell/completions/cli.nu *' >> ~/.config/nushell/config.nu # PowerShell -Add-content $PROFILE "loki --completions powershell | Out-String | Invoke-Expression" +Add-content $PROFILE "coyote --completions powershell | Out-String | Invoke-Expression" ``` # Shell Assistant -Loki has an `-e,--execute` flag that allows users to run natural language commands directly from the CLI. It accepts +Coyote has an `-e,--execute` flag that allows users to run natural language commands directly from the CLI. It accepts natural language input and translates it into executable shell commands. ![Shell Assistant Demo](./images/shell_integrations/assistant.gif) # Intelligent Command Completions -Loki also provides shell scripts that bind `Alt-e` to `loki -e ""`, allowing users to generate +Coyote also provides shell scripts that bind `Alt-e` to `coyote -e ""`, allowing users to generate commands from natural text directly without invoking the CLI. For example: @@ -81,16 +81,16 @@ $ find . -name '*.ts' -type f -exec awk 'NR>100{exit 1}' {} \; -print ``` To use the CLI helper, add the content of the appropriate integration script for your shell to your shell configuration file: -* [Bash Integration](https://github.com/Dark-Alex-17/loki/blob/main/scripts/shell-integration/integration.bash) (add to: `~/.bashrc`) -* [Zsh Integration](https://github.com/Dark-Alex-17/loki/blob/main/scripts/shell-integration/integration.zsh) (add to: `~/.zshrc`) -* [Elvish Integration](https://github.com/Dark-Alex-17/loki/blob/main/scripts/shell-integration/integration.elv) (add to: `~/.elvish/rc.elv`) -* [Fish Integration](https://github.com/Dark-Alex-17/loki/blob/main/scripts/shell-integration/integration.fish) (add to: `~/.config/fish/config.fish`) -* [Nushell Integration](https://github.com/Dark-Alex-17/loki/blob/main/scripts/shell-integration/integration.nu) (add to: `~/.config/nushell/config.nu`) -* [PowerShell Integration](https://github.com/Dark-Alex-17/loki/blob/main/scripts/shell-integration/integration.ps1) (add to: `$PROFILE`) +* [Bash Integration](https://github.com/Dark-Alex-17/coyote/blob/main/scripts/shell-integration/integration.bash) (add to: `~/.bashrc`) +* [Zsh Integration](https://github.com/Dark-Alex-17/coyote/blob/main/scripts/shell-integration/integration.zsh) (add to: `~/.zshrc`) +* [Elvish Integration](https://github.com/Dark-Alex-17/coyote/blob/main/scripts/shell-integration/integration.elv) (add to: `~/.elvish/rc.elv`) +* [Fish Integration](https://github.com/Dark-Alex-17/coyote/blob/main/scripts/shell-integration/integration.fish) (add to: `~/.config/fish/config.fish`) +* [Nushell Integration](https://github.com/Dark-Alex-17/coyote/blob/main/scripts/shell-integration/integration.nu) (add to: `~/.config/nushell/config.nu`) +* [PowerShell Integration](https://github.com/Dark-Alex-17/coyote/blob/main/scripts/shell-integration/integration.ps1) (add to: `$PROFILE`) # Explain Commands -In addition to the Shell Assistant, Loki has a built-in role that explains shell commands to you to decipher their -language. So if Loki generates a command that you're unsure of what it does, simply pass it to the `explain-shell` role: +In addition to the Shell Assistant, Coyote has a built-in role that explains shell commands to you to decipher their +language. So if Coyote generates a command that you're unsure of what it does, simply pass it to the `explain-shell` role: ![Explain Shell Role](./images/shell_integrations/explain-shell.png) diff --git a/TODO-System.md b/TODO-System.md index e3b28e4..edb23b5 100644 --- a/TODO-System.md +++ b/TODO-System.md @@ -1,4 +1,4 @@ -Loki's Todo System is a built-in task tracking feature designed to improve the reliability and effectiveness of LLM +Coyote's Todo System is a built-in task tracking feature designed to improve the reliability and effectiveness of LLM interactions, especially with smaller models. It provides structured task management that helps models: - Break complex tasks into manageable steps @@ -14,7 +14,7 @@ Smaller language models often struggle with: - **Incomplete execution**: Stopping before all work is done - **Lack of structure**: Jumping between tasks without clear organization -The Loki Todo System addresses these issues by giving the model explicit tools to plan, track, and verify task completion. +The Coyote Todo System addresses these issues by giving the model explicit tools to plan, track, and verify task completion. The system automatically prompts the model to continue when incomplete tasks remain, ensuring work gets finished. # How It Works @@ -95,7 +95,7 @@ continuation_prompt: null You can also change these at runtime using `.set` (see [Runtime Settings](#runtime-settings) below). ## Agent Configuration -Agents have the richest configuration, with all four settings available in `/agents//config.yaml`: +Agents have the richest configuration, with all four settings available in `/agents//config.yaml`: ```yaml # agents/my-agent/config.yaml @@ -202,7 +202,7 @@ This command is available in all contexts (agents, sessions, roles, or bare mode is enabled. If auto-continuation isn't enabled, the command will display an error message. # Auto-Continuation -When `auto_continue` is enabled, Loki automatically sends a continuation prompt if: +When `auto_continue` is enabled, Coyote automatically sends a continuation prompt if: 1. The model's response completes (model stops generating) 2. There are incomplete tasks in the todo list @@ -326,4 +326,4 @@ automatically. If you're seeing loops: - [Agents](Agents) - Full agent configuration guide - [Roles](Roles) - Role configuration with auto_continue support - [Sessions](Sessions) - Session configuration with auto_continue support -- [Function Calling](Tools) - How tools work in Loki +- [Function Calling](Tools) - How tools work in Coyote diff --git a/Themes.md b/Themes.md index 2841ec8..891ec69 100644 --- a/Themes.md +++ b/Themes.md @@ -1,12 +1,12 @@ -Loki supports customizing the theme via a `.tmTheme` file. +Coyote supports customizing the theme via a `.tmTheme` file. # Setup -To install a custom theme, download the `.tmTheme` file to the Loki configuration directory and name it `dark.tmTheme` -or `light.tmTheme`. The location of the Loki configuration directory varies between systems, so you can use the +To install a custom theme, download the `.tmTheme` file to the Coyote configuration directory and name it `dark.tmTheme` +or `light.tmTheme`. The location of the Coyote configuration directory varies between systems, so you can use the following command to locate it on your system: ```shell -loki --info | grep 'config_dir' | awk '{print $2}' +coyote --info | grep 'config_dir' | awk '{print $2}' ``` # Themes diff --git a/Tools.md b/Tools.md index 11ddf88..99aa395 100644 --- a/Tools.md +++ b/Tools.md @@ -1,56 +1,56 @@ -Loki supports function calling with various tools built-in to enhance LLM capabilities. All built-in tools for Loki -are located in the [`functions/tools`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools) directory. These tools are also stored in your Loki `functions` +Coyote supports function calling with various tools built-in to enhance LLM capabilities. All built-in tools for Coyote +are located in the [`functions/tools`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools) directory. These tools are also stored in your Coyote `functions` directory, which is also where you'd go to add more tools. -**Pro Tip:** The Loki functions directory can be found by running the following command: +**Pro Tip:** The Coyote functions directory can be found by running the following command: ```bash -loki --info | grep functions_dir | awk '{print $2}' +coyote --info | grep functions_dir | awk '{print $2}' ``` --- # Built-In Tools -The following tools are built-in to Loki by default, and their default enabled/disabled status is indicated. More about how tools can +The following tools are built-in to Coyote by default, and their default enabled/disabled status is indicated. More about how tools can be enabled/disabled can be found in the [Configuration](#configuration) section below. | Tool | Description | Enabled/Disabled | |-------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------| -| [`demo_py.py`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/demo_py.py) | Demonstrates how to create a tool using Python and how to use comments. | 🔴 | -| [`demo_sh.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/demo_sh.sh) | Demonstrate how to create a tool using Bash and how to use comment tags. | 🔴 | -| [`demo_ts.ts`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/demo_ts.ts) | Demonstrates how to create a tool using TypeScript and how to use JSDoc comments. | 🔴 | -| [`execute_command.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/execute_command.sh) | Execute the shell command. | 🟢 | -| [`execute_py_code.py`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/execute_py_code.py) | Execute the given Python code. | 🔴 | -| [`execute_sql_code.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/execute_sql_code.sh) | Execute SQL code. | 🔴 | -| [`fetch_url_via_curl.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fetch_url_via_curl.sh) | Extract the content from a given URL using cURL. | 🔴 | -| [`fetch_url_via_jina.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fetch_url_via_jina.sh) | Extract the content from a given URL using Jina. | 🔴 | -| [`fs_cat.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_cat.sh) | Read the contents of a file at the specified path. | 🟢 | -| [`fs_read.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_read.sh) | Controlled reading of the contents of a file at the specified path with line numbers, offset, and limit to read specific sections. | 🟢 | -| [`fs_glob.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_glob.sh) | Find files by glob pattern. Returns matching file paths sorted by modification time. | 🟢 | -| [`fs_grep.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_grep.sh) | Search file contents using regular expressions. Returns matching file paths and lines. | 🟢 | -| [`fs_ls.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_ls.sh) | List all files and directories at the specified path. | 🟢 | -| [`fs_mkdir.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_mkdir.sh) | Create a new directory at the specified path. | 🔴 | -| [`fs_patch.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_patch.sh) | Apply a patch to a file at the specified path.
This can be used to edit a file without having to rewrite the whole file. | 🔴 | -| [`fs_rm.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_rm.sh) | Remove a file or directory at the specified path. | 🔴 | -| [`fs_write.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/fs_write.sh) | Write the full file contents to a file at the specified path. | 🟢 | -| [`get_current_time.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/get_current_time.sh) | Get the current time. | 🟢 | -| [`get_current_weather.py`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/get_current_weather.py) | Get the current weather in a given location (Python implementation) | 🔴 | -| [`get_current_weather.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/get_current_weather.sh) | Get the current weather in a given location. | 🟢 | -| [`get_current_weather.ts`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/get_current_weather.ts) | Get the current weather in a given location (TypeScript implementation) | 🔴 | -| [`search_arxiv.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/search_arxiv.sh) | Search arXiv using the given search query and return the top papers. | 🔴 | -| [`search_wikipedia.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/search_wikipedia.sh) | Search Wikipedia using the given search query.
Use it to get detailed information about a public figure, interpretation of a
complex scientific concept or in-depth connectivity of a significant historical
event, etc. | 🔴 | -| [`search_wolframalpha.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/search_wolframalpha.sh) | Get an answer to a question using Wolfram Alpha. The input query should be
in English. Use it to answer user questions that require computation, detailed
facts, data analysis, or complex queries. | 🔴 | -| [`send_mail.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/send_mail.sh) | Send an email. | 🔴 | -| [`send_twilio.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/send_twilio.sh) | Send SMS or Twilio Messaging Channels messages using the Twilio API. | 🔴 | -| [`web_search_loki.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/web_search_loki.sh) | Perform a web search to get up-to-date information or additional context.
Use this when you need current information or feel a search could provide
a better answer. | 🔴 | -| [`web_search_perplexity.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/web_search_perplexity.sh) | Perform a web search using the Perplexity API to get up-to-date
information or additional context. Use this when you need current
information or feel a search could provide a better answer. | 🔴 | -| [`web_search_tavily.sh`](https://github.com/Dark-Alex-17/loki/blob/main/assets/functions/tools/web_search_tavily.sh) | Perform a web search using the Tavily API to get up-to-date
information or additional context. Use this when you need current
information or feel a search could provide a better answer. | 🔴 | +| [`demo_py.py`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/demo_py.py) | Demonstrates how to create a tool using Python and how to use comments. | 🔴 | +| [`demo_sh.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/demo_sh.sh) | Demonstrate how to create a tool using Bash and how to use comment tags. | 🔴 | +| [`demo_ts.ts`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/demo_ts.ts) | Demonstrates how to create a tool using TypeScript and how to use JSDoc comments. | 🔴 | +| [`execute_command.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/execute_command.sh) | Execute the shell command. | 🟢 | +| [`execute_py_code.py`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/execute_py_code.py) | Execute the given Python code. | 🔴 | +| [`execute_sql_code.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/execute_sql_code.sh) | Execute SQL code. | 🔴 | +| [`fetch_url_via_curl.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fetch_url_via_curl.sh) | Extract the content from a given URL using cURL. | 🔴 | +| [`fetch_url_via_jina.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fetch_url_via_jina.sh) | Extract the content from a given URL using Jina. | 🔴 | +| [`fs_cat.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_cat.sh) | Read the contents of a file at the specified path. | 🟢 | +| [`fs_read.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_read.sh) | Controlled reading of the contents of a file at the specified path with line numbers, offset, and limit to read specific sections. | 🟢 | +| [`fs_glob.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_glob.sh) | Find files by glob pattern. Returns matching file paths sorted by modification time. | 🟢 | +| [`fs_grep.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_grep.sh) | Search file contents using regular expressions. Returns matching file paths and lines. | 🟢 | +| [`fs_ls.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_ls.sh) | List all files and directories at the specified path. | 🟢 | +| [`fs_mkdir.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_mkdir.sh) | Create a new directory at the specified path. | 🔴 | +| [`fs_patch.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_patch.sh) | Apply a patch to a file at the specified path.
This can be used to edit a file without having to rewrite the whole file. | 🔴 | +| [`fs_rm.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_rm.sh) | Remove a file or directory at the specified path. | 🔴 | +| [`fs_write.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/fs_write.sh) | Write the full file contents to a file at the specified path. | 🟢 | +| [`get_current_time.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/get_current_time.sh) | Get the current time. | 🟢 | +| [`get_current_weather.py`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/get_current_weather.py) | Get the current weather in a given location (Python implementation) | 🔴 | +| [`get_current_weather.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/get_current_weather.sh) | Get the current weather in a given location. | 🟢 | +| [`get_current_weather.ts`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/get_current_weather.ts) | Get the current weather in a given location (TypeScript implementation) | 🔴 | +| [`search_arxiv.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/search_arxiv.sh) | Search arXiv using the given search query and return the top papers. | 🔴 | +| [`search_wikipedia.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/search_wikipedia.sh) | Search Wikipedia using the given search query.
Use it to get detailed information about a public figure, interpretation of a
complex scientific concept or in-depth connectivity of a significant historical
event, etc. | 🔴 | +| [`search_wolframalpha.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/search_wolframalpha.sh) | Get an answer to a question using Wolfram Alpha. The input query should be
in English. Use it to answer user questions that require computation, detailed
facts, data analysis, or complex queries. | 🔴 | +| [`send_mail.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/send_mail.sh) | Send an email. | 🔴 | +| [`send_twilio.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/send_twilio.sh) | Send SMS or Twilio Messaging Channels messages using the Twilio API. | 🔴 | +| [`web_search_coyote.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/web_search_coyote.sh) | Perform a web search to get up-to-date information or additional context.
Use this when you need current information or feel a search could provide
a better answer. | 🔴 | +| [`web_search_perplexity.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/web_search_perplexity.sh) | Perform a web search using the Perplexity API to get up-to-date
information or additional context. Use this when you need current
information or feel a search could provide a better answer. | 🔴 | +| [`web_search_tavily.sh`](https://github.com/Dark-Alex-17/coyote/blob/main/assets/functions/tools/web_search_tavily.sh) | Perform a web search using the Tavily API to get up-to-date
information or additional context. Use this when you need current
information or feel a search could provide a better answer. | 🔴 | Details on what configuration, if any, is necessary for each tool can be found inside the tool file definition itself. Built-in tools are written to your functions directory on first run and never overwritten afterward, so your edits are -preserved across Loki updates. To discard local changes and reinstall the built-in tools from the current Loki build, -run `loki --install functions` (or `.install functions` in the REPL). Tools you created yourself are not affected, and -your `mcp.json` is left untouched. Use `loki --install mcp_config` to reset that separately. +preserved across Coyote updates. To discard local changes and reinstall the built-in tools from the current Coyote build, +run `coyote --install functions` (or `.install functions` in the REPL). Tools you created yourself are not affected, and +your `mcp.json` is left untouched. Use `coyote --install mcp_config` to reset that separately. # Configuration Tools can be used in a handful of contexts: @@ -62,11 +62,11 @@ Tools can be used in a handful of contexts: Each of these has a different configuration and interaction with the global configuration. **Note:** For each configuration property listed below, the functions that are mentioned *only* -correspond to the tool scripts located in your Loki `functions/tools` directory. +correspond to the tool scripts located in your Coyote `functions/tools` directory. ## Global Configuration The global configuration is essentially what settings you want to have on by default when -you just invoke `loki`. (Don't worry about agents, roles, or sessions yet. We'll get to them in a bit). +you just invoke `coyote`. (Don't worry about agents, roles, or sessions yet. We'll get to them in a bit). The following settings are available in the global configuration for tools: @@ -74,18 +74,18 @@ The following settings are available in the global configuration for tools: function_calling_support: true # Enables or disables function calling in any context mapping_tools: # Alias for a tool or toolset fs: 'fs_cat,fs_ls,fs_mkdir,fs_rm,fs_write' -enabled_tools: null # Which tools to use by default. (e.g. 'fs,web_search_loki') +enabled_tools: null # Which tools to use by default. (e.g. 'fs,web_search_coyote') visible_tools: # Which tools are visible to be compiled (and are thus able to be defined in 'enabled_tools') # - demo_py.py - execute_command.sh ``` A special not about `enabled_tools`: a user can set this to `all` to enable all available tools listed in the -`visible_tools` section of your Loki `config.yaml` file. +`visible_tools` section of your Coyote `config.yaml` file. See the [Enabling/Disabling Global Tools](#enablingdisabling-global-tools) section below for more information on how tools are globally enabled/disabled globally. -(See the [Configuration Example](https://github.com/Dark-Alex-17/loki/blob/main/config.example.yaml) file for an example global configuration with all options.) +(See the [Configuration Example](https://github.com/Dark-Alex-17/coyote/blob/main/config.example.yaml) file for an example global configuration with all options.) When running in REPL-mode, the `function_calling_support` and `enabled_tools` settings can be overridden using the `.set` command: @@ -96,11 +96,11 @@ You'll notice that mentioned above, some tools are disabled while others are ena ## Enabling/Disabling Global Tools The configured tools are enabled/disabled by looking at the values in the `visible_tools` array in your `config.yaml` -file. This file is located in the root of the Loki `config` directory. The location of the Loki config varies by system, +file. This file is located in the root of the Coyote `config` directory. The location of the Coyote config varies by system, so your config file can be found using the following command: ```bash -loki --info | grep 'config_file' | awk '{print $2}' +coyote --info | grep 'config_file' | awk '{print $2}' ``` Each line in the `visible_tools` array lists a tool. @@ -134,12 +134,12 @@ The values for `mapping_tools` are inherited from the [global configuration](#gl For more information about agents, refer to the [Agents](Agents) documentation. -For a full example configuration for an agent, see the [Agent Configuration Example](https://github.com/Dark-Alex-17/loki/blob/main/config.agent.example.yaml) file. +For a full example configuration for an agent, see the [Agent Configuration Example](https://github.com/Dark-Alex-17/coyote/blob/main/config.agent.example.yaml) file. --- # Tool Error Handling -When tools fail, Loki captures error information and passes it back to the model so it can diagnose issues and +When tools fail, Coyote captures error information and passes it back to the model so it can diagnose issues and potentially retry or adjust its approach. ## Native/Shell Tool Errors diff --git a/Vault.md b/Vault.md index bd9ca24..b26e17d 100644 --- a/Vault.md +++ b/Vault.md @@ -1,4 +1,4 @@ -The Loki vault lets users store sensitive secrets and credentials securely so that there's no plaintext secrets +The Coyote vault lets users store sensitive secrets and credentials securely so that there's no plaintext secrets anywhere in your configurations. It's based on the [G-Man library](https://github.com/Dark-Alex-17/gman) (which also comes in a binary format) which @@ -9,59 +9,59 @@ functions as a universal secret management tool. --- # Usage -The Loki vault can be used in one of two ways: via the CLI or via the REPL for interactive usage. +The Coyote vault can be used in one of two ways: via the CLI or via the REPL for interactive usage. ## CLI Usage The vault is utilized from the CLI with the following flags: ```bash ---add-secret Add a secret to the Loki vault ---get-secret Decrypt a secret from the Loki vault and print the plaintext ---update-secret Update an existing secret in the Loki vault ---delete-secret Delete a secret from the Loki vault ---list-secrets List all secrets stored in the Loki vault +--add-secret Add a secret to the Coyote vault +--get-secret Decrypt a secret from the Coyote vault and print the plaintext +--update-secret Update an existing secret in the Coyote vault +--delete-secret Delete a secret from the Coyote vault +--list-secrets List all secrets stored in the Coyote vault ``` -(The above is also documented in `loki --help`) +(The above is also documented in `coyote --help`) -Loki will guide you through manipulating your secrets to make usage easier. +Coyote will guide you through manipulating your secrets to make usage easier. ## REPL Usage -The vault can be access from within the Loki REPL using the `.vault` commands: +The vault can be access from within the Coyote REPL using the `.vault` commands: -![Loki Vault REPL](./images/vault/vault-repl.png) -![Loki Vault REPL Commands](./images/vault/vault-repl-commands.png) +![Coyote Vault REPL](./images/vault/vault-repl.png) +![Coyote Vault REPL Commands](./images/vault/vault-repl-commands.png) The manipulation of your vault is guided in the same way as the CLI usage, ensuring ease of use. # Motivation -Loki is intended to be highly configurable and adaptable to many different use cases. This means that users of Loki +Coyote is intended to be highly configurable and adaptable to many different use cases. This means that users of Coyote should be able to share configurations for agents, tools, roles, etc. with other users or even entire teams. My objective is to encourage this, and to make it so that users can easily version their configurations using version control. Good VCS hygiene dictates that one *never* commits secrets or sensitive information to a repository. -Since a number of files and configurations in Loki may contain sensitive information, the vault exists to solve this problem. +Since a number of files and configurations in Coyote may contain sensitive information, the vault exists to solve this problem. Users can either share the vault password with a team, making it so a single configuration can be pulled from VCS and used by said team. Alternatively, each user can maintain their own vault password and expect other users to replace secret values with their user-specific secrets. # How it works -When you first start Loki, if you don't already have a vault password file, it will prompt you to create one. This file -houses the password that is used to encrypt and decrypt secrets within Loki. This file exists so that you are not prompted -for a password every time Loki attempts to decrypt a secret. +When you first start Coyote, if you don't already have a vault password file, it will prompt you to create one. This file +houses the password that is used to encrypt and decrypt secrets within Coyote. This file exists so that you are not prompted +for a password every time Coyote attempts to decrypt a secret. -When you encrypt a secret, it uses the local provider for `gman` to securely store those secrets in the Loki vault file. -This file is typically located at your Loki configuration directory under `vault.yml`. If you open this file, you'll see a +When you encrypt a secret, it uses the local provider for `gman` to securely store those secrets in the Coyote vault file. +This file is typically located at your Coyote configuration directory under `vault.yml`. If you open this file, you'll see a bunch of gibberish. This is because all secrets are encrypted using the password you provided, meaning only you can decrypt them. -Secrets are specified in Loki configurations using the same variable templating as the [Jinja templating engine](https://jinja.palletsprojects.com/en/stable/): +Secrets are specified in Coyote configurations using the same variable templating as the [Jinja templating engine](https://jinja.palletsprojects.com/en/stable/): ``` {{some_variable}} ``` -So whenever you want Loki to use a secret from the vault, you simply specify the secret name in this format in the applicable +So whenever you want Coyote to use a secret from the vault, you simply specify the secret name in this format in the applicable file. **Example:** @@ -93,30 +93,30 @@ the expected value in my `mcp.json` with the templated secret: } ``` -At runtime, Loki will detect the templated secret and replace it with the decrypted value from the vault before executing. +At runtime, Coyote will detect the templated secret and replace it with the decrypted value from the vault before executing. # Supported Files -At the time of writing, the following files support Loki secret injection: +At the time of writing, the following files support Coyote secret injection: | File Type | Description | Limitations | |-------------------------|-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------| -| `config.yaml` | The main Loki configuration file | Cannot use secret injection on the `vault_password_file` field | +| `config.yaml` | The main Coyote configuration file | Cannot use secret injection on the `vault_password_file` field | | `functions/mcp.json` | The MCP server configuration file | | | `/tools.` | Tool files for agents | Specific configuration and only supported for Agents, not all global tools ([see below](#environment-variable-secret-injection-in-agents)) | -Note that all paths are relative to the Loki configuration directory. The directory varies by system, so you can find yours by +Note that all paths are relative to the Coyote configuration directory. The directory varies by system, so you can find yours by running ```shell -loki --info | grep config_dir | awk '{print $2}' +coyote --info | grep config_dir | awk '{print $2}' ``` # Environment Variable Secret Injection in Agents -Secrets from the Loki vault can be injected into agent `tools.sh/tools.py` as environment variables. This is done as +Secrets from the Coyote vault can be injected into agent `tools.sh/tools.py` as environment variables. This is done as follows: -1. Ensure a secret named `MY_USERNAME` is in your Loki vault. +1. Ensure a secret named `MY_USERNAME` is in your Coyote vault. 2. Set the name of the secret as the default value for a variable `/config.yaml` ```yaml diff --git a/_Sidebar.md b/_Sidebar.md index 1426414..98d984c 100644 --- a/_Sidebar.md +++ b/_Sidebar.md @@ -5,7 +5,7 @@ - [Sharing Configurations](Sharing-Configurations) - [AIChat Migration](AIChat-Migration) -## Using Loki +## Using Coyote - [REPL](REPL) - [REPL Prompt](REPL-Prompt) - [Shell Integrations](Shell-Integrations) diff --git a/git_config.bak b/git_config.bak index 1be6425..14b69c2 100644 --- a/git_config.bak +++ b/git_config.bak @@ -4,16 +4,16 @@ bare = false logallrefupdates = true [remote "origin"] - url = git@github.com:Dark-Alex-17/loki.wiki.git + url = git@github.com:Dark-Alex-17/coyote.wiki.git fetch = +refs/heads/*:refs/remotes/origin/* - pushurl = git@github.com:Dark-Alex-17/loki.wiki.git - pushurl = git@git.alexjclarke.com:Dark-Alex-17/loki.wiki.git + pushurl = git@github.com:Dark-Alex-17/coyote.wiki.git + pushurl = git@git.alexjclarke.com:Dark-Alex-17/coyote.wiki.git push = refs/heads/master:refs/heads/master push = refs/heads/master:refs/heads/main [branch "master"] remote = origin merge = refs/heads/master [remote "gitea"] - url = git@git.alexjclarke.com:Dark-Alex-17/loki.wiki.git + url = git@git.alexjclarke.com:Dark-Alex-17/coyote.wiki.git fetch = +refs/heads/*:refs/remotes/gitea/* push = refs/heads/master:refs/heads/main diff --git a/images/loki_rag.png b/images/coyote_rag.png similarity index 100% rename from images/loki_rag.png rename to images/coyote_rag.png