Documentation Index
Fetch the complete documentation index at: https://docs.ixo.world/llms.txt
Use this file to discover all available pages before exploring further.
The three tiers
| Visibility | Tools bound at boot? | Listed in Tier-1 prompt? | Discoverable via list_capabilities / load_capability? |
|---|---|---|---|
always | Yes | Yes | Yes |
on-demand | No — until load_capability(name) | No | Yes |
silent | Yes (but invisible to the LLM as tools) | No | No |
on-demand. A plugin without an explicit visibility is treated as on-demand.
What each tier is for
| Tier | Use for | Token cost per turn |
|---|---|---|
always | Plugins the agent needs on nearly every turn (e.g. memory, skills, user-preferences) | ~80 tokens for the Tier-1 entry + tool schemas (~100–300 per tool) on every turn |
on-demand | Plugins useful in narrow situations (e.g. portal, firecrawl, composio) | Zero until loaded; same as always after |
silent | Plugins that act through middleware or HTTP only (e.g. credits, slack) | Zero in the prompt; middleware still runs |
Picking a tier
Promoting toalways is a deliberate budget choice. Demoting to silent is a deliberate architectural choice. Most plugins should stay on the default — on-demand.
Loading and unloading
on-demand plugins live in a per-thread loadedPlugins state field. The set is monotonic — it only grows. Loading a plugin makes its tools available for the rest of that thread; a new thread starts with an empty loadedPlugins.
There is no “unload” operation. If a thread accumulates too many loaded plugins, starting a new thread is the reset.
Per-tool override
A plugin can override visibility per tool by settingvisibility on the PluginTool itself. This lets one plugin ship a mix — e.g. one always tool and several on-demand tools — without splitting into two plugins.
Read next
Set visibility (recipe)
How to declare each tier in plugin code.
Meta-tools
How
list_capabilities and load_capability work.PluginManifest.