Introduction

What Kaeonix is

Kaeonix is a single binary that puts a coding agent in your terminal. It reads and edits files, runs commands, searches the web, and drives long multi-step work — inside whatever repository you launch it from. The command is kaeonix, and kx is installed alongside it as an alias for the same binary.

Avatar is the model behind it. You reach Avatar through a Feyncode account, and the same subscription covers the CLI and the browser chat; API keys are metered separately. Kaeonix will also talk to a model provider of your own if you would rather bring your own key.

• OS-level sandboxing — bwrap on Linux, Seatbelt on macOS, Docker anywhere, with network denied by default.
• Plan mode that hard-blocks mutating tools while the agent researches, rather than politely asking it not to edit.
• Subagents, hooks, skills, and MCP — including auto-import of existing Claude Code and OpenCode MCP config.
• 130+ model providers via the models.dev catalogue, for teams that need to run against their own endpoint.

How a turn runs

Understanding the turn loop explains most of Kaeonix's behaviour. Every message you send walks the same path:

1. The UserPromptSubmit hook fires and can rewrite or block the prompt.
2. If the session has exceeded 75% of the model's context window, it is compacted into a structured summary first.
3. The tool registry is composed: core tools, plus MCP-contributed and plugin tools.
4. The system prompt is assembled from your project memory, skills, and effort level.
5. The model streams. Every tool call passes through the permission gate before it runs.
6. The Stop hook fires when the turn finishes.

The permission gate in step 5 is the part worth internalising — it is what stands between a confident model and your filesystem. See Permissions.

Start here

If you have never run Kaeonix, the fastest path is four commands: