Cost optimization
Turn on input compression and custom system prompt injection on a self-hosted instance — both live in the console, not in config.yaml.
Both features are off by default, configured globally on the console's Cost Optimization page, and overridable per API key.
They are not in config.yaml — the switches live in the database, take effect immediately, and need no restart.
Turning them on globally
Open your instance's console (http://localhost:8080 by default) and go to Cost Optimization in the sidebar:
- Input compression — compresses bulky, highly redundant tool output (
go testresults, git diffs, grep results, build logs) before it reaches the upstream - Custom system prompt — appends house rules to every request's system prompt without touching client code
The page also reports what each one actually saved, in tokens and in cost.
Overriding per API key
Editing a key under Tokens lets you set:
| Option | Behaviour |
|---|---|
| Inherit global | Follows the Cost Optimization page's global switch |
| Force on | This key always compresses, regardless of the global switch |
| Force off | Requests on this key are never compressed, even when the global switch is on |
What input compression recognises
| Detected content | What is removed |
|---|---|
go test / build logs | Boilerplate lines for passing cases (=== RUN, --- PASS, === CONT) — failures, skips, panics, stack traces and summary lines are all kept |
| git diffs | index abc..def blob hash headers and ANSI escapes — hunks are never truncated |
| grep / ripgrep output | Consecutive duplicate matches collapse into one line with a count; every distinct path:line:match is kept |
| Plain logs | ANSI escapes, consecutive duplicate lines, consecutive blank lines |
Compression never touches the active edit region at the tail of the conversation, and only replaces a block when the compressed form is actually shorter. Request logs show which blocks were compressed and why the others were not.
Why it does not break prompt caching
System prompt injection is deterministic: repeated requests produce byte-identical system content, so upstream prompt caches still hit. Input compression only touches the latest round of tool results — earlier turns stay byte-for-byte identical, so prefix cache hit rates are unaffected.
Cache-read and cache-write tokens are metered and priced separately throughout the dashboard.