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.