Dark-Alex-17/coyote
1
0
Fork 0
Code Issues Pull Requests Actions 9 Packages Projects Releases Wiki Activity

Update Loki to Coyote

Alex Clarke
2026-05-27 12:54:06 -06:00
parent 1b8dcdbace
commit cea15233ac
28 changed files with 612 additions and 612 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AIChat-Migration.md
+23 -23
@@ -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 (`<loki-config-dir>/agents`):
Agents are now all handled in one place: the `agents` directory (`<coyote-config-dir>/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 `<aichat-config-dir>/functions/agents` directory into `<loki-config-dir/agents`
* Copy the contents of your `<aichat-config-dir>/functions/agents` directory into `<coyote-config-dir/agents`
* Merge `index.yaml` into `config.yaml`
* If you never created a custom `config.yaml` file, then simply rename `index.yaml` to `config.yaml`
* If you've defined an `agent_prelude`, rename that field to `agent_session`
@@ -128,12 +128,12 @@ So now for all of your agents, copy all the contents of those directories to the
When you're done with this migration, you should have the following:
* No more `functions/agents` directory
* No `functions/agents.txt` file (Loki assumes that if the agent directory exists, it is loadable)
* No `<loki-config-dir>/agents/<agent-name>/tools.txt`
* No `<loki-config-dir>/agents/<agent-name>/index.yaml`
* No `functions/agents.txt` file (Coyote assumes that if the agent directory exists, it is loadable)
* No `<coyote-config-dir>/agents/<agent-name>/tools.txt`
* No `<coyote-config-dir>/agents/<agent-name>/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 `<aichat-config-dir>/functions` directory into your Loki config directory
* Delete the following files and directories from your `<loki-config-dir>/functions` directory:
* Copy your AIChat `<aichat-config-dir>/functions` directory into your Coyote config directory
* Delete the following files and directories from your `<coyote-config-dir>/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 `<loki-config-dir>/config.yaml`
becomes the following in your `<coyote-config-dir>/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`.
Agents.md
+37 -37
@@ -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:
```
<loki-config-dir>/agents
<coyote-config-dir>/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> # 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 `<loki-config-dir>/functions/mcp.json` file
- github # Corresponds to the name of an MCP server in the `<coyote-config-dir>/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 '<loki-config-dir>/agents/my-agent/OMOPCDM_ddl.sql')
- OMOPCDM_ddl.sql # Relative path to agent (i.e. file lives at '<coyote-config-dir>/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 `<loki-config-dir>/agents/my-agent/tools.sh`, a Python-based
`<loki-config-dir>/agents/my-agent/tools.py`, or a TypeScript-based `<loki-config-dir>/agents/my-agent/tools.ts`.
You can only utilize one of: a bash-based `<coyote-config-dir>/agents/my-agent/tools.sh`, a Python-based
`<coyote-config-dir>/agents/my-agent/tools.py`, or a TypeScript-based `<coyote-config-dir>/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 `<loki-config-dir>/agents/` directory can be spawned as a child. Child agents:
Any agent defined in your `<coyote-config-dir>/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.
Bash-Prompt-Helpers.md
+5 -5
@@ -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.
Clients.md
+26 -26
@@ -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 <br>of the model so it can query it. For example: If you have `name: gpt-alias`, then you must <br>also define `real_name: gpt-oss:latest` |
| `type` | * | `all` | The type of model. Loki supports only 3 types of models: <ul><li>`chat`</li><li>`embedding`</li><li>`reranker`</li></ul> |
| `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 <br>of the model so it can query it. For example: If you have `name: gpt-alias`, then you must <br>also define `real_name: gpt-oss:latest` |
| `type` | * | `all` | The type of model. Coyote supports only 3 types of models: <ul><li>`chat`</li><li>`embedding`</li><li>`reranker`</li></ul> |
| `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 |
|-------------------|-------------------------------------------------------|
Custom-Bash-Tools.md
+25 -25
@@ -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 <value> 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 <value1,value2>` 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).
Custom-Tools.md
+17 -17
@@ -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. <br>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 <br>(i.e. `dirname $(loki --info \| grep config_file \| awk '{print $2}')`) |
| `LLM_ROOT_DIR` | The root `config_dir` directory for Coyote <br>(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:**
Environment-Variables.md
+46 -46
@@ -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 <br>using the [vault](Vault). The variables are named after the client to which they apply; <br>e.g. `OPENAI_API_KEY`, `GEMINI_API_KEY`, etc. |
| `LOKI_PLATFORM` | Combine with `{client}_API_KEY` to run Loki without a configuration file. <br>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, <br>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. <br>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, <br>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. | `<user-config-dir>/loki` |
| `LOKI_ENV_FILE` | Customize the location of the `.env` file to load at startup. | `<loki-config-dir>/.env` |
| `LOKI_CONFIG_FILE` | Customize the location of the global `config.yaml` configuration file. | `<loki-config-dir>/config.yaml` |
| `LOKI_ROLES_DIR` | Customize the location of the `roles` directory. | `<loki-config-dir>/roles` |
| `LOKI_SESSIONS_DIR` | Customize the location of the `sessions` directory. | `<loki-config-dir>/sessions` |
| `LOKI_RAGS_DIR` | Customize the location of the `rags` directory. | `<loki-config-dir>/rags` |
| `LOKI_FUNCTIONS_DIR` | Customize the location of the `functions` directory. | `<loki-config-dir>/functions` |
| `COYOTE_CONFIG_DIR` | Customize the location of the Coyote configuration directory. | `<user-config-dir>/coyote` |
| `COYOTE_ENV_FILE` | Customize the location of the `.env` file to load at startup. | `<coyote-config-dir>/.env` |
| `COYOTE_CONFIG_FILE` | Customize the location of the global `config.yaml` configuration file. | `<coyote-config-dir>/config.yaml` |
| `COYOTE_ROLES_DIR` | Customize the location of the `roles` directory. | `<coyote-config-dir>/roles` |
| `COYOTE_SESSIONS_DIR` | Customize the location of the `sessions` directory. | `<coyote-config-dir>/sessions` |
| `COYOTE_RAGS_DIR` | Customize the location of the `rags` directory. | `<coyote-config-dir>/rags` |
| `COYOTE_FUNCTIONS_DIR` | Customize the location of the `functions` directory. | `<coyote-config-dir>/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
| `<AGENT_NAME>_VARIABLES` | Customize the `variables` used for the agent (in JSON format of `[{"key1": "value1", "key2": "value2"}]`); <br>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 | `<user-cache-dir>/loki/loki.log` |
| `COYOTE_LOG_LEVEL` | Customize the log level of Coyote | `INFO` |
| `COYOTE_LOG_FILE` | Customize the location of the Coyote log file | `<user-cache-dir>/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. <br>Tool scripts (`run-tool.sh`, `run-agent.sh`, etc.) read from this file instead of command-line args <br>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. <br>Tool scripts (`run-tool.sh`, `run-agent.sh`, etc.) read from this file instead of command-line args <br>to avoid JSON escaping issues when data passes through `cmd.exe` → bash. **Not intended to be set by users.** | |
Getting-Started.md
+15 -15
@@ -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); <br>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`); <br>Defaults to `$EDITOR` |
| `editor` | `null` | What text editor Coyote should use to edit the input buffer or session (e.g. `vim`, `emacs`, `nano`, `hx`); <br>Defaults to `$EDITOR` |
| `wrap` | `no` | Controls whether text is wrapped (can be `no`, `auto`, or some `<max_width>` |
| `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. <br>Values can be <ul><li>`role:<name>` to define a role</li><li>`session:<name>` to define a session</li><li>`<session>:<role>` to define both a session and a role to use</li></ul> |
| `cmd_prelude` | This setting lets you specify a default `session` or `role` to use when running one-off queries in Loki via the CLI. <br>Values can be <ul><li>`role:<name>` to define a role</li><li>`session:<name>` to define a session</li><li>`<session>:<role>` to define both a session and a role to use</li></ul> |
| `repl_prelude` | This setting lets you specify a default `session` or `role` to use when starting Coyote in [REPL](REPL) mode. <br>Values can be <ul><li>`role:<name>` to define a role</li><li>`session:<name>` to define a session</li><li>`<session>:<role>` to define both a session and a role to use</li></ul> |
| `cmd_prelude` | This setting lets you specify a default `session` or `role` to use when running one-off queries in Coyote via the CLI. <br>Values can be <ul><li>`role:<name>` to define a role</li><li>`session:<name>` to define a session</li><li>`<session>:<role>` to define both a session and a role to use</li></ul> |
| `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 |
Graph-Agents.md
+35 -35
@@ -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:
```
<loki-config-dir>/agents
<coyote-config-dir>/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
```
`<rag-node-id>.yaml` files are generated by Loki at agent load time - one
`<rag-node-id>.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_<UPPER_NAME>`, exactly like bash tools called by normal
agents. Values may be overridden at runtime via
`loki -a <agent> --agent-variable <name> <value> "..."`. For LLM nodes to
`coyote -a <agent> --agent-variable <name> <value> "..."`. 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
`<loki-config-dir>/agents/`.
`<coyote-config-dir>/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_<NAME>` | 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 <agent> ...`), not the agent directory. This matches
The script's **working directory** is the coyote invocation directory (where
the user ran `coyote -a <agent> ...`), 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:<server>` 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` /
Home.md
+18 -18
@@ -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.
---
Installation.md
+45 -45
@@ -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-<arch>.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-<arch>.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
MCP-Servers.md
+19 -19
@@ -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.
Macros.md
+16 -16
@@ -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.
Patches.md
+6 -6
@@ -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.
RAG.md
+35 -35
@@ -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 <name>` or `loki --rag <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 <name>` or `coyote --rag <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: <br><ul><li>`/tmp/dir1/LOKI.md`</li><li>`/tmp/dir2/subdir1/LOKI.md`</li><li>`/tmp/dir2/subdir2/LOKI.md`</li></ul> |
| Recursive Filename | `/tmp/*/COYOTE.md` | The following files will be picked up: <br><ul><li>`/tmp/dir1/COYOTE.md`</li><li>`/tmp/dir2/subdir1/COYOTE.md`</li><li>`/tmp/dir2/subdir2/COYOTE.md`</li></ul> |
| URL | `https://www.ohdsi.org/data-standardization/` | Downloads and loads the specified webpage into the <br>knowledge base |
| Recursive URL (Websites) | `https://github.com/OHDSI/Vocabulary-v5.0/wiki/**` | Crawls all pages under the given URL and loads them <br>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__
</user_query>
```
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.
REPL-Prompt.md
+3 -3
@@ -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
REPL.md
+45 -45
@@ -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 <name>`
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 <file|dir|url|%%|cmd>... [-- <text>...]
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 <category>` (e.g. `loki --install agents`).
The same operation is available from the command line: `coyote --install <category>` (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 <git-url> --filter <category>` | Restrict to one of `agents`, `roles`, `macros`, `functions`, `mcp_config` |
| `.install remote <git-url> --force` | Skip all conflict prompts; overwrite local files unconditionally |
The CLI equivalent is `loki --install-from <git-url>` (with `--filter` and `--install-force` accepting the same values).
The CLI equivalent is `coyote --install-from <git-url>` (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 <version>` | 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.
Roles.md
+22 -22
@@ -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)
Sessions.md
+17 -17
@@ -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/<agent-name>/sessions/_/`).
`~/.config/coyote/agents/<agent-name>/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 _/` + <kbd>Tab</kbd> (REPL)**: **Will** show auto-saved sessions in completions, since Loki looks in the
- **`.session _/` + <kbd>Tab</kbd> (REPL)**: **Will** show auto-saved sessions in completions, since Coyote looks in the
`_/` subdirectory when it sees this prefix.
- **`.session _/<name>` (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. <br><ul><li>If `true`, then any time you're in a session, changes will auto-save unless explicitly defined otherwise.</li> <li>If `false`, then any time you're in a session, changes will not auto-save unless explicitly specified otherwise.</li><li>If `null`, Loki will always prompt the user for what to do.</li></ul> |
| `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. <br><ul><li>If `true`, then any time you're in a session, changes will auto-save unless explicitly defined otherwise.</li> <li>If `false`, then any time you're in a session, changes will not auto-save unless explicitly specified otherwise.</li><li>If `null`, Coyote will always prompt the user for what to do.</li></ul> |
| `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 |
Sharing-Configurations.md
+46 -46
@@ -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 <git-url>`
- CLI: `coyote --install-from <git-url>`
- REPL: `.install remote <git-url>`
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.
```
<repo>/
@@ -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 `#<ref>` to the URL.
```sh
loki --install-from https://github.com/<owner>/<repo>#v1.2.3
loki --install-from https://github.com/<owner>/<repo>#main
loki --install-from https://github.com/<owner>/<repo>#abc1234
coyote --install-from https://github.com/<owner>/<repo>#v1.2.3
coyote --install-from https://github.com/<owner>/<repo>#main
coyote --install-from https://github.com/<owner>/<repo>#abc1234
```
How Loki resolves the ref:
How Coyote resolves the ref:
- **Branch or tag names** are passed as `--branch <ref>` to a shallow `git clone --depth 1`.
- **Commit SHAs** (4-40 hex characters) trigger a full clone followed by `git checkout <ref>`.
@@ -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 <git-url> --filter agents
loki --install-from <git-url> --filter mcp_config
coyote --install-from <git-url> --filter agents
coyote --install-from <git-url> --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 "<name>-remote"` | Insert the remote entry under a suffixed key. If the suffixed key is also taken, Loki appends `-2`, `-3`, etc. |
| `rename remote as "<name>-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 <NAME>` or `.vault add <NAME>`).
commands you can run later (`coyote --add-secret <NAME>` or `.vault add <NAME>`).
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/<name>/`**. 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 <url>` manually.
your git credentials work for the same URL outside Coyote by running `git clone <url>` manually.
- **Network failure**: `Could not resolve host` or similar. Check connectivity.
- **Invalid ref**: `couldn't find remote ref <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 <NAME>` (CLI) or `.vault add <NAME>` (REPL). See [Vault](Vault) for details.
Add them via `coyote --add-secret <NAME>` (CLI) or `.vault add <NAME>` (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`.
Shell-Integrations.md
+23 -23
@@ -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 "<current command line>"`, allowing users to generate
Coyote also provides shell scripts that bind `Alt-e` to `coyote -e "<current command line>"`, 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)
TODO-System.md
+5 -5
@@ -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 `<loki-config-dir>/agents/<agent-name>/config.yaml`:
Agents have the richest configuration, with all four settings available in `<coyote-config-dir>/agents/<agent-name>/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
Themes.md
+4 -4
@@ -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
Tools.md
+46 -46
@@ -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. <br>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. <br>Use it to get detailed information about a public figure, interpretation of a <br>complex scientific concept or in-depth connectivity of a significant historical <br>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 <br>in English. Use it to answer user questions that require computation, detailed <br>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. <br>Use this when you need current information or feel a search could provide <br>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 <br>information or additional context. Use this when you need current <br>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 <br>information or additional context. Use this when you need current <br>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. <br>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. <br>Use it to get detailed information about a public figure, interpretation of a <br>complex scientific concept or in-depth connectivity of a significant historical <br>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 <br>in English. Use it to answer user questions that require computation, detailed <br>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. <br>Use this when you need current information or feel a search could provide <br>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 <br>information or additional context. Use this when you need current <br>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 <br>information or additional context. Use this when you need current <br>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
Vault.md
+28 -28
@@ -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 <SECRET_NAME> Add a secret to the Loki vault
--get-secret <SECRET_NAME> Decrypt a secret from the Loki vault and print the plaintext
--update-secret <SECRET_NAME> Update an existing secret in the Loki vault
--delete-secret <SECRET_NAME> Delete a secret from the Loki vault
--list-secrets List all secrets stored in the Loki vault
--add-secret <SECRET_NAME> Add a secret to the Coyote vault
--get-secret <SECRET_NAME> Decrypt a secret from the Coyote vault and print the plaintext
--update-secret <SECRET_NAME> Update an existing secret in the Coyote vault
--delete-secret <SECRET_NAME> 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 | |
| `<agent>/tools.<py/sh>` | 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
`<agent>/config.yaml`
```yaml
_Sidebar.md
+1 -1
@@ -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)
git_config.bak
+4 -4
@@ -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
images/loki_rag.png → images/coyote_rag.png
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 75 KiB

After

Width:  |  Height:  |  Size: 75 KiB