Token Usage HIGH

[shahriyardx]

I’ve been using the Claude Code CLI with a DeepSeek API key, and the token usage there was surprisingly low compared to DeepSeek TUI. DeepSeek TUI is costing me almost 3× more for similar workflows, probably because I was using the Caveman Skill setup in Claude Code.

Is there any equivalent mechanism or optimization in DeepSeek TUI that can reduce token usage while maintaining similar performance?

[ashargall]

What's preventing you from adding the caveman skill directly to deepseek-tui?

[richardchen874-sys]

This is a good point. The 3× difference may not come only from the DeepSeek API itself, but from how the workflow manages context, prompts, and repeated tool outputs.

If Claude Code with the Caveman Skill is cheaper, I’d compare:

• system prompt size
• how much file/context is sent each turn
• whether previous tool outputs are repeated
• compression or summarization between steps
• max tokens and reasoning settings
• whether DeepSeek TUI keeps too much history in the loop

Adding a Caveman-like skill or a context-budget mode to DeepSeek TUI could be useful.

For coding workflows, cost optimization is not just about cheaper tokens — it’s also about reducing unnecessary context and routing tasks to the right model/settings.

[shahriyardx]

I have tried using caveman skill in the Deepseek TUI, Still it costs me more than Claude Code CLI.

[richardchen874-sys]

Good point — adding a Caveman-like skill directly to DeepSeek TUI is probably the right first experiment.

The main thing I’d want to compare is whether the token savings come from the skill itself, or from Claude Code’s surrounding workflow.

For DeepSeek TUI, I’d probably start with:

• a smaller system prompt / instruction profile
• stricter context budgeting
• avoiding repeated tool outputs in history
• summarizing older steps instead of replaying everything
• separate modes for quick edits vs deeper reasoning
• logging tokens per step so the expensive parts are visible

If the 3× difference is mostly from prompt/context management, then a built-in “low-token coding mode” could help a lot without changing the underlying DeepSeek API.

That would also make it easier to compare model cost fairly, because right now the workflow design may be affecting token usage more than the model/provider itself.

[adambhun]

Tried making caveman work with v0.9.0. The root cause isn't the skill itself — it's that user-level communication preferences don't propagate to sub-agents. Tested five approaches:

• constitution.json working_style — too weak (advisory-only, bottom of hierarchy)
• Project AGENTS.md — sub-agents don't pick it up
• Custom Fleet profile — not auto-discovered by profile parameter
• fork_context: true — works but leaks parent conversation (unusable)
• Direct prompt injection — works but manual, impractical

The hierarchy gap: system prompt (role + SUMMARY/EVIDENCE format) sits at top, unchangeable. User preferences sit at bottom. Caveman or any style directive can't cross that gap.

Any of these platform features would fix it: (1) constitution entries at equal rank to role prompt, (2) auto-discovery for custom Fleet profiles with a default profile config, (3) skill propagation from parent to sub-agents.

I'll see what comes out of Issue #4195 before I make more noise about this though.

[richardchen874-sys]

Tried making caveman work with v0.9.0. The root cause isn't the skill itself — it's that user-level communication preferences don't propagate to sub-agents. Tested five approaches:

• constitution.json working_style — too weak (advisory-only, bottom of hierarchy)
• Project AGENTS.md — sub-agents don't pick it up
• Custom Fleet profile — not auto-discovered by profile parameter
• fork_context: true — works but leaks parent conversation (unusable)
• Direct prompt injection — works but manual, impractical

The hierarchy gap: system prompt (role + SUMMARY/EVIDENCE format) sits at top, unchangeable. User preferences sit at bottom. Caveman or any style directive can't cross that gap.

Any of these platform features would fix it: (1) constitution entries at equal rank to role prompt, (2) auto-discovery for custom Fleet profiles with a default profile config, (3) skill propagation from parent to sub-agents.

I'll see what comes out of Issue #4195 before I make more noise about this though.

Thanks for clarifying, and no offense taken. The distinction between the production ESPHome firmware and the optional standalone AI path makes sense, especially for a project maintained in limited free time. I will keep any future provider-compatibility suggestions scoped to the optional AI path and avoid implying a delivery commitment.