Download the PHP package papi-ai/rtk without Composer
On this page you can find all versions of the php package papi-ai/rtk. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package rtk
Short Description RTK token-optimisation proxy adapter for PapiAI
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package rtk
papi-ai/rtk
RTK token-optimisation proxy adapter for PapiAI.
Wraps the RTK CLI (a proxy that compresses verbose developer
output before it reaches an LLM) behind PapiAI's LLMTokenOptimisationProxyInterface, so agents
and tools can shrink command output, often by 60-90%, before it enters the context window.
Install
Requires papi-ai/papi-core ^0.11 and the rtk binary on
your PATH (brew install rtk, or see the RTK install docs).
Usage
Use it inside a tool so a command's output is compressed before it re-enters the agent's context:
What to send through it (and what never to)
Optimisation is lossy by design. RTK rewrites the text, and its named filters drop detail they
consider incidental (the find filter, for example, discards file names).
Only compress text the model needs to read. Command output, logs, test runs, diffs: that is where the savings are, and losing formatting costs nothing.
Never compress text the model must reproduce verbatim. Source files it is about to edit,
whole-file payloads, anything round-tripped back to disk. Measured on a 15.7KB PHP file: an
unfiltered rtk pipe returned it byte-identical (safe, but zero saving), while the named filters
that do save tokens mangled it. There is nothing to win and a file to lose.
Text that is already summarised at the source has nothing left to squeeze either. If your tool already returns a structured report rather than raw runner output, you solved the same problem upstream.
API
RtkProxy implements LLMTokenOptimisationProxyInterface (which extends TokenEstimatorInterface):
| Method | Purpose |
|---|---|
optimise(string $content, array $options = []) |
Pipe text through rtk pipe (filter, ultraCompact options) |
optimiseCommand(string $command, array $options = []) |
Run a read-only command through RTK (measure, ultraCompact options) |
estimateTokens(string $content) |
Cheap byte-based estimate, delegated to an injectable estimator |
Both optimise methods return an OptimisationResult (optimised, tokensBefore, tokensAfter,
isMeasured(), tokensSaved(), savingsPercent(), strategy). Token counts are estimates, not a
real tokenizer: by default PapiAI\Core\HeuristicTokenEstimator (bytes divided by 4, so multibyte
text estimates high). Inject any TokenEstimatorInterface to change that:
optimiseCommand()executes the command (raw, then via RTK) to measure the saving, so pass only side-effect-free commands (git status, grep, ls, test runners).['measure' => false]runs it once, through RTK only.
Where it fits
Nothing in PapiAI wires an optimiser in for you, by design. Agent middleware only sees the request prompt (tool results are resolved inside the run loop), so a middleware could never reach the text RTK is good at. The integration point is your own tool handler, as in the example above: run the command, compress its output, return the compressed text.
License
MIT © Marcello Duarte
