deepx-code: a DeepSeek-native terminal coding agent built around prompt-cache hits

The bill that deepx-code is trying to shrink

Coding agents resend context on every turn. A long session carries the same file contents, tool results and reasoning traces forward, and the provider charges for that repeated input unless a prefix cache absorbs it. The README states that DeepSeek bills cached input at a fraction of the miss price, and deepx-code is built around that pricing structure rather than treating it as an afterthought. The project quotes one real session where 41,472 of 41,591 tokens hit the cache, roughly 99 percent, and frames the whole tool around that number. Treat it as a single example from the maintainers, not a benchmark you can assume for your workload. The shape of your prompts, how often you edit early context, and how your provider orders prefixes all move that ratio. The audience is narrow and identifiable: developers already holding a DeepSeek or compatible API key who run agents in a terminal for hours and watch the token counter. If you use a subscription-billed agent, cache economics do not apply to you at all.

What actually runs when you type deepx

The binary is written in Go and ships as a single executable with no Node or Python runtime behind it. The install script places it at ~/.local/bin/deepx, and deepx upgrade is the documented update path. Configuration lives in two files under ~/.deepx: model.yaml holds per-role settings (flash and pro) for base_url, model, api_key, max_tokens and context_window, while provider.yaml archives each provider's configuration under a name such as deepseek, mimo, kimi, qwen or custom. The /provider command rewrites model.yaml from that archive, so switching vendors does not require re-entering keys. The README notes that flash and pro can point at different providers, which is unusual and worth knowing: routing decisions are made locally and instantly, according to the project, rather than by spending a call to classify the task. Sessions persist in a gob-encoded format that the README says preserves tool_calls, tool results and reasoning_content intact, so a restart resumes rather than reconstructs. When a session exceeds the context window, the tool applies layered compression instead of truncating the oldest turns.

Getting it installed and pointed at a model

On macOS or Linux the documented install is a piped shell script: curl -fsSL https://raw.githubusercontent.com/itmisx/deepx-code/main/scripts/install.sh | bash && exec $SHELL. Windows uses the PowerShell equivalent, irm https://raw.githubusercontent.com/itmisx/deepx-code/main/scripts/install.ps1 | iex. For users in mainland China the README offers a Gitee mirror, either by prefixing the install with SOURCE=gitee on the shell line or by setting $env:SOURCE='gitee' before the PowerShell command; after that, deepx upgrade is said to follow the Gitee source automatically. Then cd into a project and run deepx to enter the TUI. First launch opens a wizard where you pick a provider with the arrow keys and paste an API key; the README lists DeepSeek and Xiaomi MiMo as the built-in choices, with preconfigured flash and pro model names and a stated 1M context window. Everything the wizard writes can be overridden by editing ~/.deepx/model.yaml directly. MCP servers are added inside the TUI with /mcp-add and listed with /mcp-list. Skills go in <workspace>/.deepx/skills/ or in an existing directory such as ~/.claude/skills/, which the project says it reads for compatibility.

The codegraph is precise for Go and thinner elsewhere

The built-in codegraph answers symbol-level questions: jump to definition, find callers, locate interface implementations, assess the blast radius of a change. According to the README, Go files are parsed with go/types, which gives the tool real type information rather than textual matching. That is the strongest claim in the feature list and also the most bounded one. The README names Go as the precise path and does not describe equivalent type-aware analysis for other languages, so a Python or TypeScript repository should expect a code graph that is closer to indexed search than to a compiler. The comparison table in the README positions this against Claude Code, which it says relies on grep and search. That is a fair description of the mechanism difference, but it is not a claim about answer quality in languages where deepx-code has no type resolver. If your repository is polyglot, the codegraph will be at its best in the Go packages and more ordinary everywhere else.

OCR, workflows and the parts that are harder to verify

Image handling is local: the README says PaddleOCR runs offline so a screenshot can be read without a multimodal API call. For teams that paste error dialogs or design mockups into a session, that removes a cloud dependency, though the README does not state which languages or scripts the OCR model covers, so accuracy outside Latin text is unverified from this material. Workflow scripts are JavaScript files that compose agents through agent(), parallel() and pipeline() primitives, invoked with /workflow <name>, with /ultracode <description> asking the model to generate and save one. The README says the scripts align with Claude Code's workflow conventions and can be used interchangeably, that runs are genuinely concurrent, that a run can be interrupted and resumed, that all stages are listed before execution with live timings, and that structured output is enforced through tool schemas. Those are specific and testable claims, but they come from the project's own description. The working mode setting is more interesting than it first looks: karpathy, openspec and superpowers are mutually exclusive, choosing one disables the other two, and the selection is stored in the session and injected each turn without being written into conversation history. That last detail matters for caching, since a mode that rewrote prior turns would invalidate the prefix the whole design depends on.

Sandboxing, approvals and the exec escape hatch

File writes and shell commands require human confirmation by default, per the README. Isolation has three settings: native, docker and off. Native uses OS mechanisms, which the README identifies as Seatbelt on macOS and bubblewrap on Linux, restricting writes to the workspace and isolating processes; on platforms without such a mechanism the project says it falls back to a softer policy. Docker gives container isolation. This is a real distinction from agents that assume a container is present, but the fallback path is the part to check on your own machine, because the README does not name which platforms lose the OS-level guarantee. The non-interactive mode is the one most likely to be adopted first by teams: deepx exec "<task>" runs once, prints only the result to stdout and exits, accepting piped input such as cat error.log | deepx exec "分析这段报错". The README states an API key must already be configured through the interactive TUI before exec will work, which makes the first-run flow a prerequisite for CI use rather than something a script can bootstrap.

Where deepx-code is the wrong tool

The cache argument only pays off under specific conditions. If your sessions are short, if you frequently rewrite the beginning of the conversation, or if your provider does not implement prefix caching the way DeepSeek documents, the advantage narrows to ordinary token accounting. The README's own comparison table concedes it does not compare model quality, and that concession is the honest framing: deepx-code is a cost, distribution and tooling play, not a claim that DeepSeek models outperform anything in particular. A second limitation is the provider set. The wizard is described as offering DeepSeek and Xiaomi MiMo, with Kimi and Qwen appearing in the provider archive naming and custom OpenAI-compatible endpoints supported, so an Anthropic-only shop gets nothing here. Third, the codegraph advantage is concentrated in Go. Fourth, the release cadence visible in the metadata is fast, with v0.2.109, v0.2.108 and v0.2.107 landing within about two weeks of each other, which means interfaces and config keys can move; the README already shows a manual model.yaml editing path that a schema change would break. As an alternative, Claude Code takes the opposite approach on several axes at once: it is distributed through npm rather than as a static binary, it is closed source, it targets Anthropic models, and it handles images by sending them to a cloud multimodal endpoint instead of running OCR locally. If you want a subscription-priced agent with no key management, that difference in approach is the deciding one, and no amount of local caching changes it.

Licence, upgrade path and what to confirm first

deepx-code is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it is the main structural difference from the closed-source tool it compares itself to. It is not legal advice; if you vendor the binary into a product, read the LICENSE file in the repository rather than this paragraph. Maintenance cost is mostly the update cadence: deepx upgrade is the documented mechanism, and given releases roughly every one to two weeks, pinning a version for a team is a decision the tool does not appear to support directly. Verify before adopting: run the install script and confirm the binary lands at ~/.local/bin/deepx and that deepx upgrade reports a version; complete the wizard and read ~/.deepx/model.yaml to confirm the flash and pro roles hold the model names you expect; then run one long session of your own and compare the cache-hit ratio your provider reports against the README's 41,472-of-41,591 example. If your ratio is far lower, the entire premise of choosing this tool over a grep-based agent weakens, and that is the number to check before anything else.

Editorial conclusion

Adopt deepx-code if you already pay for DeepSeek or another OpenAI-compatible endpoint, work in long terminal sessions where repeated context dominates the bill, and want a single Go binary with no Node or Python runtime. Do not adopt it if you need Anthropic models, if your codebase is not Go and you expect the codegraph to give you compiler-grade precision, or if you want a GUI. Before committing, verify three things yourself: that the install script lands a working binary at ~/.local/bin/deepx on your platform, that your provider's flash and pro model names actually resolve through the wizard into ~/.deepx/model.yaml, and that the cache-hit figure holds for your own session shape rather than the README's single quoted example.

Official sources

1. itmisx/deepx-code on GitHub
2. License: MIT
3. Project website
4. README
5. Releases