+
+
+ 
+
+
+
+
+[](https://docs.embabel.com/embabel-agent/guide/1.5.0-SNAPSHOT/)
+[](https://central.sonatype.com/artifact/com.embabel.agent/embabel-agent-api)
+
+[](https://www.yourkit.com/)
+[](https://www.ej-technologies.com/products/jprofiler/overview.html)
+[](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent)
+[](https://discord.gg/t6bjkyj93q)
+
+[//]: # ([](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent))
+
+[//]: # ([](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[](https://www.apache.org/licenses/LICENSE-2.0)
+[](https://github.com/embabel/embabel-agent/pulse)
+
+
+
+Embabel (Em-BAY-bel) is a framework for authoring agentic flows on the JVM that seamlessly mix LLM-prompted interactions
+with code and domain models. Supports
+intelligent path finding towards goals. Written in Kotlin
+but offers a natural usage
+model from Java.
+From the creator of Spring.
+
+
+
+## Talk to the Docs
+
+Have questions? [Talk to the docs via the Embabel-powered hub](https://hub.embabel.com) — an
+Embabel agent that answers your questions about the framework in natural language.
+
+## Key Concepts
+
+Models agentic flows in terms of:
+
+- **Actions**: Steps an agent takes
+- **Goals**: What an agent is trying to achieve
+- **Conditions**: Conditions to assess before executing an action or determining that a goal has been achieved.
+ Conditions are reassessed after each action is executed.
+- **Domain model**: Objects underpinning the flow and informing Actions, Goals and Conditions.
+- **Plan**: A sequence of actions to achieve a goal. Plans are dynamically formulated by the system, not the programmer.
+ The
+ system replans after the completion of each action, allowing it to adapt to new information as well as observe the
+ effects of the previous action.
+ This is effectively an [OODA loop](https://en.wikipedia.org/wiki/OODA_loop).
+
+> Application developers don't usually have to deal with these concepts directly,
+> as most conditions result from data flow defined in code, allowing the system to infer
+> pre and post conditions.
+
+These concepts underpin these differentiators versus other agent frameworks:
+
+- **Sophisticated planning.** Goes beyond a finite state machine or sequential execution
+ with nesting by introducing a true planning step, using a
+ non-LLM AI algorithm. This enables the system to perform tasks it wasn’t programmed to do by combining known
+ steps in
+ a novel order, as well as make decisions about parallelization and other runtime behavior.
+- **Superior extensibility and reuse**: Because of dynamic planning, adding more domain objects, actions, goals and
+ conditions
+ can extend the capability of the system, _without editing FSM definitions_ or existing code.
+- **Strong typing and the benefits of object orientation**: Actions, goals and conditions are informed by a domain
+ model, which can
+ include behavior. Everything is strongly typed and prompts and
+ manually authored code interact cleanly. No more magic maps. Enjoy full refactoring support.
+
+Other benefits:
+
+- **Platform abstraction**: Clean separation between programming model and platform internals allows running locally
+ while
+ potentially offering higher QoS in production without changing application code.
+- **Designed for LLM mixing**: It is easy to build applications that mix LLMs, ensuring the most cost-effective yet
+ capable solution.
+ This enables the system to leverage the strengths of different models for different tasks. In particular, it
+ facilitates
+ the use of local models for point tasks. This can be important for cost and privacy.
+- **Built on Spring and the JVM,** making it easy to access existing enterprise functionality and capabilities.
+ For example:
+ - Spring can inject and manage agents, including using Spring AOP to decorate functions.
+ - Robust persistence and transaction management solutions are available.
+- **Designed for testability** from the ground up. Both unit testing and agent end to end testing are easy.
+
+Flows can be authored in one of two ways:
+
+- An annotation-based model similar to Spring MVC, with types annotated with the Spring stereotype `@Agent`, using
+ `@Goal`, `@Condition` and
+ `@Action` methods.
+- Idiomatic Kotlin DSL with `agent {` and `action {` blocks.
+
+Either way, flows are backed by a domain model of objects that can have rich behavior.
+
+> We are working toward allowing natural language actions and goals to be deployed.
+
+The planning step is pluggable.
+
+The default planning approach is
+[Goal Oriented Action Planning](https://medium.com/@vedantchaudhari/goal-oriented-action-planning-34035ed40d0b).
+GOAP is a popular AI planning algorithm used in gaming. It allows for dynamic decision-making and action selection based
+on the current state of the world and the goals of the agent.
+
+Goals, actions and plans are independent of GOAP. Embabel also
+supports [Utility AI](https://en.wikipedia.org/wiki/Utility_system) out of the box, which can run the same actions but
+chooses actions
+based on (potentially dynamic) utility scores rather than strict preconditions and postconditions. This is valuable for
+exploration and
+open-ended tasks, when we do not need to achieve a specific goal but want to maximize overall utility.
+
+The framework executes via an `AgentPlatform` implementation.
+
+An agent platform supports the following modes of execution:
+
+- **Focused**, where user code requests particular functionality: User code calls a method to run a particular agent,
+ passing in input. This is ideal for code-driven flows such as a flow invoked in response to an incoming event.
+- **Closed**, where user intent (or another incoming event) is classified to choose an agent. The platform tries to
+ find a
+ suitable agent among all the agents it knows about.
+ Agent choice is dynamic, but only actions defined within the particular agent
+ will run.
+- **Open**, where the user's intent is assessed and the platform uses _all_ its resources to try to achieve it. The
+ platform tries to find a
+ suitable goal among all the goals it knows about and builds a custom agent to achieve it from the start state,
+ including relevant actions and conditions. The platform will not proceed if it is unconvinced as to the applicability
+ of any goal. The `GoalChoiceApprover` interface provides developers a way to limit goal choice further.
+
+Open mode is the most powerful, but least deterministic.
+> In open mode, the platform is capable of finding novel paths that were not envisioned by developers, and even
+> combining functionality from multiple providers.
+
+Even in open mode, the platform will only perform individual steps
+that have been specified. (Of course, steps may themselves be LLM
+transforms, in which case the prompts are controlled by user code but the
+results are still non-deterministic.)
+
+Possible future modes:
+
+- **Evolving** mode: Where the platform can work with multiple goals in the same process and modify a running process to
+ add further goals and agents.
+ For example, an action can realize that it has become important to achieve additional goals.
+
+Embabel agent systems will also support federation, both with other Embabel systems (allowing planning to incorporate
+remote actions and goals) and third party agent frameworks.
+
+## Quick Start
+
+Get an agent running in under 5 minutes.
+
+Create your own agent repo from our [Java](https://github.com/embabel/java-agent-template)
+or [Kotlin](https://github.com/embabel/kotlin-agent-template) GitHub template by clicking the "Use this template"
+button.
+
+You'll have an agent running in under a minute
+if you already have an `OPENAI_API_KEY` and have Maven installed.
+
+**📚 For examples and tutorials**, see
+the [Embabel Agent Examples Repository](https://github.com/embabel/embabel-agent-examples)
+
+**🚗 For a sophisticated, realistic example application**, see
+the [Tripper travel planner agent](https://github.com/embabel/tripper)
+
+
+
+*AI-generated travel itinerary with detailed recommendations*
+
+
+
+*Map link included in output*
+
+## Why Is Embabel Needed?
+
+TL;DR Because the evolution of agent frameworks is early and there's a lot of room for improvement; because an agent
+framework on the JVM will deliver great business value.
+
+- _Why do we need an agent framework at all_? We can write code without higher level abstractions, directly invoking
+ LLMs and controlling flow directly in code. However, a higher level agent framework offers compelling benefits. For
+ example:
+ - Breaking up LLM interactions, making them simpler and more focused. This maximizes reuse and minimizes cost and
+ errors. It often allows us to use cheaper models for point interactions.
+ - Facilitating both unit and integration testing, which remain as important with agentic systems as with any other
+ software systems.
+ - Increasing composability where subflows and individual actions can be reused
+ - Making applications more manageable and robust, enabling a workflow manager to control their execution and retry
+ operations while maintaining previous state
+ - Enhancing safety through the ability to apply guardrails in many places
+- _Why do we need an agent framework for the JVM when solutions exist in Python?_: While agent frameworks initially
+ appeared predominantly Python, it's early and there's plenty of room for novel and
+ superior
+ approaches. The key adjacency is not the LLM--which is a simple HTTP call away--but existing code and
+ infrastructure
+ assets that are more valuable on the JVM than in Python.
+- _Why not use just Spring AI?_ Spring AI is great. We build on it, and embrace the Spring component model. However, we
+ believe that most applications should work with higher
+ level APIs. An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC.
+ Complex requirements are much easier to express and test in Embabel than with direct use of Spring AI.
+- _Why not attempt to contribute this project to Spring?_ This project requires different governance
+ from Spring, where most projects exist in stable environments and dependability and stability outweighs rapid
+ innovation. Second, the
+ concepts are not JVM-specific. We hope that Embabel will become the leading agent framework across platforms. While
+ the Spring brand is valuable in Java, it is not in TypeScript or Python.
+
+## Show Me The Code
+
+In Java or Kotlin, agent implementation code is intuitive and easy to test.
+
+
+
+### What gets traced automatically
+
+- Agent lifecycle (creation, execution, completion, failures)
+- Every action as a child span
+- LLM calls with token usage (via Spring AI)
+- Tool invocations with input/output
+- Planning and replanning iterations
+- State transitions and lifecycle states
+
+### Track custom operations with `@Tracked`
+
+Use the `@Tracked` annotation to add observability spans to your own methods — inputs, outputs, duration, and errors are captured automatically:
+
+```java
+@Tracked("enrichCustomer")
+public Customer enrich(Customer input) {
+ // Your logic here
+}
+```
+
+You can specify a type and description for richer traces:
+
+```java
+@Tracked(value = "callPaymentApi", type = TrackType.EXTERNAL_CALL, description = "Payment gateway call")
+public PaymentResult processPayment(Order order) {
+ // ...
+}
+```
+
+When called within an agent execution, `@Tracked` spans are automatically nested under the current action:
+
+```
+Agent: CustomerServiceAgent
+├── Action: ProcessOrder
+│ ├── @Tracked: enrichCustomer (PROCESSING)
+│ ├── ChatModel: gpt-4
+│ └── @Tracked: callPaymentApi (EXTERNAL_CALL)
+└── status: completed
+```
+
+For the full configuration reference, MDC log correlation, and advanced options, see the [Observability Module Documentation](embabel-agent-observability/README.md).
+
+---
+
+## Contributing
+
+We welcome contributions to the Embabel Agent Framework.
+
+Look at the [coding style guide](embabel-agent-api/.embabel/coding-style.md) for style guidelines.
+This file also informs coding agent behavior.
+
+## Miscellaneous
+
+- _Why the name Embabel?_
+ The "babel" part is ultimately inspired by the story of the Tower of Babel, perhaps via Douglas
+ Adams' [babelfish](https://www.youtube.com/watch?v=iuumnjJWFO4&ab_channel=BBCStudios).
+ Per @lasuac:
+ _While Adams' fish in the ear enabled universal translation between species, Embabel aims at translating human intent
+ to JVM code, AI models, and enterprise systems._
+ "embabel" also sounds like "enable."
+- Milestone names are Australian animals. Mythical animals such as "bunyip" and "yowie" are used for futures that may or
+ not be implemented.
+- README badges come from [here](https://github.com/Ileriayo/markdown-badges)
+ and [here](https://home.aveek.io/GitHub-Profile-Badges/).
+- Don't forget to join [Discord](https://discord.gg/t6bjkyj93q) to collaborate with the Embabel community. It is a good
+ place to receive support, showcase your work, discuss ideas and connect with like-minded people.
+
+## Star History
+
+
+
+
+[](https://docs.embabel.com/embabel-agent/guide/1.5.0-SNAPSHOT/)
+[](https://central.sonatype.com/artifact/com.embabel.agent/embabel-agent-api)
+
+[](https://www.yourkit.com/)
+[](https://www.ej-technologies.com/products/jprofiler/overview.html)
+[](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent)
+[](https://discord.gg/t6bjkyj93q)
+
+[//]: # ([](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent))
+
+[//]: # ([](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[](https://www.apache.org/licenses/LICENSE-2.0)
+[](https://github.com/embabel/embabel-agent/pulse)
+
+
+
+Embabel (Em-BAY-bel) is a framework for authoring agentic flows on the JVM that seamlessly mix LLM-prompted interactions
+with code and domain models. Supports
+intelligent path finding towards goals. Written in Kotlin
+but offers a natural usage
+model from Java.
+From the creator of Spring.
+
+
+
+## Talk to the Docs
+
+Have questions? [Talk to the docs via the Embabel-powered hub](https://hub.embabel.com) — an
+Embabel agent that answers your questions about the framework in natural language.
+
+## Key Concepts
+
+Models agentic flows in terms of:
+
+- **Actions**: Steps an agent takes
+- **Goals**: What an agent is trying to achieve
+- **Conditions**: Conditions to assess before executing an action or determining that a goal has been achieved.
+ Conditions are reassessed after each action is executed.
+- **Domain model**: Objects underpinning the flow and informing Actions, Goals and Conditions.
+- **Plan**: A sequence of actions to achieve a goal. Plans are dynamically formulated by the system, not the programmer.
+ The
+ system replans after the completion of each action, allowing it to adapt to new information as well as observe the
+ effects of the previous action.
+ This is effectively an [OODA loop](https://en.wikipedia.org/wiki/OODA_loop).
+
+> Application developers don't usually have to deal with these concepts directly,
+> as most conditions result from data flow defined in code, allowing the system to infer
+> pre and post conditions.
+
+These concepts underpin these differentiators versus other agent frameworks:
+
+- **Sophisticated planning.** Goes beyond a finite state machine or sequential execution
+ with nesting by introducing a true planning step, using a
+ non-LLM AI algorithm. This enables the system to perform tasks it wasn’t programmed to do by combining known
+ steps in
+ a novel order, as well as make decisions about parallelization and other runtime behavior.
+- **Superior extensibility and reuse**: Because of dynamic planning, adding more domain objects, actions, goals and
+ conditions
+ can extend the capability of the system, _without editing FSM definitions_ or existing code.
+- **Strong typing and the benefits of object orientation**: Actions, goals and conditions are informed by a domain
+ model, which can
+ include behavior. Everything is strongly typed and prompts and
+ manually authored code interact cleanly. No more magic maps. Enjoy full refactoring support.
+
+Other benefits:
+
+- **Platform abstraction**: Clean separation between programming model and platform internals allows running locally
+ while
+ potentially offering higher QoS in production without changing application code.
+- **Designed for LLM mixing**: It is easy to build applications that mix LLMs, ensuring the most cost-effective yet
+ capable solution.
+ This enables the system to leverage the strengths of different models for different tasks. In particular, it
+ facilitates
+ the use of local models for point tasks. This can be important for cost and privacy.
+- **Built on Spring and the JVM,** making it easy to access existing enterprise functionality and capabilities.
+ For example:
+ - Spring can inject and manage agents, including using Spring AOP to decorate functions.
+ - Robust persistence and transaction management solutions are available.
+- **Designed for testability** from the ground up. Both unit testing and agent end to end testing are easy.
+
+Flows can be authored in one of two ways:
+
+- An annotation-based model similar to Spring MVC, with types annotated with the Spring stereotype `@Agent`, using
+ `@Goal`, `@Condition` and
+ `@Action` methods.
+- Idiomatic Kotlin DSL with `agent {` and `action {` blocks.
+
+Either way, flows are backed by a domain model of objects that can have rich behavior.
+
+> We are working toward allowing natural language actions and goals to be deployed.
+
+The planning step is pluggable.
+
+The default planning approach is
+[Goal Oriented Action Planning](https://medium.com/@vedantchaudhari/goal-oriented-action-planning-34035ed40d0b).
+GOAP is a popular AI planning algorithm used in gaming. It allows for dynamic decision-making and action selection based
+on the current state of the world and the goals of the agent.
+
+Goals, actions and plans are independent of GOAP. Embabel also
+supports [Utility AI](https://en.wikipedia.org/wiki/Utility_system) out of the box, which can run the same actions but
+chooses actions
+based on (potentially dynamic) utility scores rather than strict preconditions and postconditions. This is valuable for
+exploration and
+open-ended tasks, when we do not need to achieve a specific goal but want to maximize overall utility.
+
+The framework executes via an `AgentPlatform` implementation.
+
+An agent platform supports the following modes of execution:
+
+- **Focused**, where user code requests particular functionality: User code calls a method to run a particular agent,
+ passing in input. This is ideal for code-driven flows such as a flow invoked in response to an incoming event.
+- **Closed**, where user intent (or another incoming event) is classified to choose an agent. The platform tries to
+ find a
+ suitable agent among all the agents it knows about.
+ Agent choice is dynamic, but only actions defined within the particular agent
+ will run.
+- **Open**, where the user's intent is assessed and the platform uses _all_ its resources to try to achieve it. The
+ platform tries to find a
+ suitable goal among all the goals it knows about and builds a custom agent to achieve it from the start state,
+ including relevant actions and conditions. The platform will not proceed if it is unconvinced as to the applicability
+ of any goal. The `GoalChoiceApprover` interface provides developers a way to limit goal choice further.
+
+Open mode is the most powerful, but least deterministic.
+> In open mode, the platform is capable of finding novel paths that were not envisioned by developers, and even
+> combining functionality from multiple providers.
+
+Even in open mode, the platform will only perform individual steps
+that have been specified. (Of course, steps may themselves be LLM
+transforms, in which case the prompts are controlled by user code but the
+results are still non-deterministic.)
+
+Possible future modes:
+
+- **Evolving** mode: Where the platform can work with multiple goals in the same process and modify a running process to
+ add further goals and agents.
+ For example, an action can realize that it has become important to achieve additional goals.
+
+Embabel agent systems will also support federation, both with other Embabel systems (allowing planning to incorporate
+remote actions and goals) and third party agent frameworks.
+
+## Quick Start
+
+Get an agent running in under 5 minutes.
+
+Create your own agent repo from our [Java](https://github.com/embabel/java-agent-template)
+or [Kotlin](https://github.com/embabel/kotlin-agent-template) GitHub template by clicking the "Use this template"
+button.
+
+You'll have an agent running in under a minute
+if you already have an `OPENAI_API_KEY` and have Maven installed.
+
+**📚 For examples and tutorials**, see
+the [Embabel Agent Examples Repository](https://github.com/embabel/embabel-agent-examples)
+
+**🚗 For a sophisticated, realistic example application**, see
+the [Tripper travel planner agent](https://github.com/embabel/tripper)
+
+
+
+*AI-generated travel itinerary with detailed recommendations*
+
+
+
+*Map link included in output*
+
+## Why Is Embabel Needed?
+
+TL;DR Because the evolution of agent frameworks is early and there's a lot of room for improvement; because an agent
+framework on the JVM will deliver great business value.
+
+- _Why do we need an agent framework at all_? We can write code without higher level abstractions, directly invoking
+ LLMs and controlling flow directly in code. However, a higher level agent framework offers compelling benefits. For
+ example:
+ - Breaking up LLM interactions, making them simpler and more focused. This maximizes reuse and minimizes cost and
+ errors. It often allows us to use cheaper models for point interactions.
+ - Facilitating both unit and integration testing, which remain as important with agentic systems as with any other
+ software systems.
+ - Increasing composability where subflows and individual actions can be reused
+ - Making applications more manageable and robust, enabling a workflow manager to control their execution and retry
+ operations while maintaining previous state
+ - Enhancing safety through the ability to apply guardrails in many places
+- _Why do we need an agent framework for the JVM when solutions exist in Python?_: While agent frameworks initially
+ appeared predominantly Python, it's early and there's plenty of room for novel and
+ superior
+ approaches. The key adjacency is not the LLM--which is a simple HTTP call away--but existing code and
+ infrastructure
+ assets that are more valuable on the JVM than in Python.
+- _Why not use just Spring AI?_ Spring AI is great. We build on it, and embrace the Spring component model. However, we
+ believe that most applications should work with higher
+ level APIs. An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC.
+ Complex requirements are much easier to express and test in Embabel than with direct use of Spring AI.
+- _Why not attempt to contribute this project to Spring?_ This project requires different governance
+ from Spring, where most projects exist in stable environments and dependability and stability outweighs rapid
+ innovation. Second, the
+ concepts are not JVM-specific. We hope that Embabel will become the leading agent framework across platforms. While
+ the Spring brand is valuable in Java, it is not in TypeScript or Python.
+
+## Show Me The Code
+
+In Java or Kotlin, agent implementation code is intuitive and easy to test.
+
+
+
+### What gets traced automatically
+
+- Agent lifecycle (creation, execution, completion, failures)
+- Every action as a child span
+- LLM calls with token usage (via Spring AI)
+- Tool invocations with input/output
+- Planning and replanning iterations
+- State transitions and lifecycle states
+
+### Track custom operations with `@Tracked`
+
+Use the `@Tracked` annotation to add observability spans to your own methods — inputs, outputs, duration, and errors are captured automatically:
+
+```java
+@Tracked("enrichCustomer")
+public Customer enrich(Customer input) {
+ // Your logic here
+}
+```
+
+You can specify a type and description for richer traces:
+
+```java
+@Tracked(value = "callPaymentApi", type = TrackType.EXTERNAL_CALL, description = "Payment gateway call")
+public PaymentResult processPayment(Order order) {
+ // ...
+}
+```
+
+When called within an agent execution, `@Tracked` spans are automatically nested under the current action:
+
+```
+Agent: CustomerServiceAgent
+├── Action: ProcessOrder
+│ ├── @Tracked: enrichCustomer (PROCESSING)
+│ ├── ChatModel: gpt-4
+│ └── @Tracked: callPaymentApi (EXTERNAL_CALL)
+└── status: completed
+```
+
+For the full configuration reference, MDC log correlation, and advanced options, see the [Observability Module Documentation](embabel-agent-observability/README.md).
+
+---
+
+## Contributing
+
+We welcome contributions to the Embabel Agent Framework.
+
+Look at the [coding style guide](embabel-agent-api/.embabel/coding-style.md) for style guidelines.
+This file also informs coding agent behavior.
+
+## Miscellaneous
+
+- _Why the name Embabel?_
+ The "babel" part is ultimately inspired by the story of the Tower of Babel, perhaps via Douglas
+ Adams' [babelfish](https://www.youtube.com/watch?v=iuumnjJWFO4&ab_channel=BBCStudios).
+ Per @lasuac:
+ _While Adams' fish in the ear enabled universal translation between species, Embabel aims at translating human intent
+ to JVM code, AI models, and enterprise systems._
+ "embabel" also sounds like "enable."
+- Milestone names are Australian animals. Mythical animals such as "bunyip" and "yowie" are used for futures that may or
+ not be implemented.
+- README badges come from [here](https://github.com/Ileriayo/markdown-badges)
+ and [here](https://home.aveek.io/GitHub-Profile-Badges/).
+- Don't forget to join [Discord](https://discord.gg/t6bjkyj93q) to collaborate with the Embabel community. It is a good
+ place to receive support, showcase your work, discuss ideas and connect with like-minded people.
+
+## Star History
+
+
+
+ 
+ High-performance CLI proxy that cuts up to 90% of the bash output your agent reads +
+ +
+ 
+ 
+ 
+ Website • + Install • + Troubleshooting • + Architecture • + Discord +
+ ++ English • + Francais • + 中文 • + 日本語 • + 한국어 • + Espanol • + Português +
+ +--- + +rtk filters and compresses command outputs before they reach your LLM context. Single Rust binary, 100+ supported commands, <10ms overhead. + +## What RTK Does + +RTK intercepts shell commands and compresses their output before your agent reads it. + +| Operation | What RTK does to the output | +|-----------|-----------------------------| +| `ls` / `tree` | Tree format with file counts instead of one line per entry | +| `cat` / `read` | Smart file reading: signatures and structure over full bodies | +| `grep` / `rg` | Truncates long lines, groups matches by file | +| `git status` | Compact stat format, grouped by state | +| `git diff` | Reduced context, headers stripped | +| `git log` | Hash, author and subject only | +| `git add/commit/push` | Confirmation line instead of full progress output | +| `cargo test` / `npm test` | Failures only, passing tests collapsed to a count | +| `ruff check` | Grouped by rule and file | +| `pytest` | Failures only, traceback trimmed | +| `go test` | NDJSON parsed, failures only | +| `docker ps` | Essential fields only | + +## How Savings Work + +RTK cuts **up to 90% of the bash output** your agent reads. That is what RTK measures, and it is not the same as cutting your bill by 90%. + +Bash output is **one contributor to input tokens**, alongside your prompt, the system prompt and conversation history. Input tokens are in turn **only part of the bill**, which also counts output tokens. The reduction dilutes at every step. + +The token counts RTK reports are estimated as `bytes / 4` — RTK ships no tokenizer, so the **percentages are reliable but the absolute token numbers are approximate**. + +> Full explanation: [How RTK Savings Work](docs/guide/resources/savings-explained.md) + +## Installation + +### Homebrew (recommended) + +```bash +brew install rtk +``` + +### Quick Install (Linux/macOS) + +```bash +curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh +``` + +> Installs to `~/.local/bin`. Add to PATH if needed: +> ```bash +> echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc # or ~/.zshrc +> ``` + +### Cargo + +```bash +cargo install --git https://github.com/rtk-ai/rtk +``` + +### Pre-built Binaries + +Download from [releases](https://github.com/rtk-ai/rtk/releases): +- macOS: `rtk-x86_64-apple-darwin.tar.gz` / `rtk-aarch64-apple-darwin.tar.gz` +- Linux: `rtk-x86_64-unknown-linux-musl.tar.gz` / `rtk-aarch64-unknown-linux-gnu.tar.gz` +- Windows: `rtk-x86_64-pc-windows-msvc.zip` + +> **Windows users**: Extract the zip and place `rtk.exe` somewhere in your PATH (e.g. `C:\Users\cada día
++ El radar diario de repos, herramientas y papers de IA agéntica: cada hallazgo + con su ficha, por qué importa y qué hacer con él. Todo lo publicado se cruza + además en un grafo de conocimiento navegable. +
+ +hands-on