Ship with optimized RTK defaults to reduce token consumption

[arkham-district]

Paperclip can become very expensive in long-running or high-frequency environments.

Right now, many users may not realize how much token usage comes from:

• large context retention
• overly permissive RTK settings
• excessive memory extraction
• frequent summarization cycles
• broad retrieval scopes

This can lead to unexpectedly high API costs, particularly for:

• autonomous agents
• cron-based workflows
• trading bots
• continuous background execution
• multi-agent systems

Proposal

Ship the project with safer and more cost-efficient RTK defaults out of the box.

For example:

• smaller default retrieval limits
• stricter relevance thresholds
• capped memory extraction
• configurable summarization frequency
• lower default context windows
• aggressive deduplication
• optional "low-cost mode"

Potential preset profiles:

• balanced
• low-cost
• high-recall
• agentic

Why this matters

Many users optimize prompts but forget retrieval/token amplification effects.

In practice, RTK configuration often has a much bigger impact on total token consumption than the prompt itself.

Better defaults would:

• reduce surprise costs
• improve adoption
• make autonomous deployments safer
• help smaller/self-hosted users
• reduce waste without hurting quality significantly

Possible extras

• token usage estimator
• live token breakdown per retrieval stage
• warnings for expensive configurations
• "estimated monthly cost" preview
• telemetry/debug mode for retrieval decisions

Curious to hear how others are configuring RTK today and whether you've seen similar cost amplification from Paperclip.

[why459097630]

I’ve seen a similar pattern in AI coding workflows.

A lot of token waste comes from repeated context discovery: the model keeps re-reading files, rediscovering project structure, and regenerating large outputs.

One workflow I’ve been testing is to separate reasoning from file modification:

• use an LLM web app instead of an API-based agent
• pack only the relevant files with a short project brief
• ask the LLM for one exact PATCH block
• apply locally only after exact-match checking, diff preview, and backup
• run the build locally and feed back only the error output if needed

It’s less autonomous than a full agent, but the efficiency is not far behind, while avoiding separate API billing and keeping changes easier to control.