dexter-kabu-jp: The Japanese Stock Analyst That Checks Its Own Work
A terminal-native AI research desk for JPX data, valuation models, and a separate evaluator loop that helps keep finance answers grounded.
- dexter-kabu-jp is interesting because it separates generation from judgment, which is the right instinct for finance work where confident mistakes are expensive.
- Its skill system turns valuation methods into modular workflows, so the agent behaves more like a research desk than a single-purpose chatbot.
- Temporal decay memory gives recent market context more weight than stale notes, which mirrors how real analysts actually work.
- The project’s real edge is architectural: it tries to make an AI analyst that can explain itself, critique itself, and stay useful inside a terminal.
The Agent That Grades Its Own Research
Most finance copilots optimize for speed. This one optimizes for a second opinion. In dexter-kabu-jp, the agent does the work first, then a separate evaluator scores the result in a different LLM context with no tools attached.
That separation matters. Tool access can make an agent look smarter than it is. A critic without tools has to inspect the answer itself, which is the closest thing this repo has to a built-in compliance check.
実はClaude公式プラグインである finance Agentsの中にある/dcf-modelは ラジ株ナビがOSSしたDexter-kabu-jpにもあるんだよ😍 ClaudeのDCFは構造がむちゃくちゃ優秀✨️ だけどね WACC設定の現実性はDexter-kabu-jpが優秀‼️ （セクター調整済み）。 これは検証結果📝 https://t.co/uNOcn57jCj https://t.co/1i1J85qNc1
Why Japanese Equity Research Needs a Different Stack
A generic market agent can fetch prices. It usually cannot speak the local language of Japanese equity work: JPX data, disclosure docs, short selling data, margin trading, and the provider mix around JQuants and Radikabu Navi.
That changes the product shape. The repo is not just a data access layer. It is a workflow that assumes the user wants to move from raw market signals to valuation, critique, and follow-up without leaving the terminal.
| Dimension | Generic finance tool | dexter-kabu-jp |
|---|---|---|
| Data focus | Broad market coverage | Japan-first market sources and JPX workflows |
| Workflow | Fetch data, answer once | Gather data, reason, critique, refine |
| Verification | Usually implicit | Explicit evaluator pass with no tools |
| Memory | Often ephemeral | Temporal decay memory for recent context |
| Extensibility | APIs and scripts | Skills registry with override precedence |
| Interface | Web app or notebook | Terminal-native research desk |
How the Skills Registry Turns Models Into Modules
The cleanest way to read the codebase is to stop thinking about tools and start thinking about skills. DCF, Monte Carlo, and Altman Z'' are packaged as discoverable workflows, not loose helper functions.
That matters because it lets the project override behavior at the project level. The registry prefers project skills over built-ins, which means a team can tune its own valuation logic without rewriting the engine.
// Conceptual precedence in the skill registry
const loadedSkill = projectSkills[name] ?? builtinSkills[name];
if (!loadedSkill) {
throw new Error(`Unknown skill: ${name}`);
}
return loadedSkill;Memory That Fades on Purpose
The memory system is not trying to preserve everything. It tries to preserve the right things. Recent market conditions and fresh user intent matter more than stale context, so the agent’s attention decays the way an analyst’s notebook does during a live session.
That is a subtle but important design choice. The system is not pretending all context is equal. It is encoding analyst behavior into the retrieval layer.
The Terminal Is Not a Frontend Here. It Is the Product
The TUI is not a compromise. It is how the system stays legible while the agent is thinking, calling tools, and emitting intermediate events. The async generator pattern matters because it turns a black box into a live research stream.
For this kind of workflow, that is better than a polished dashboard. A terminal session can show the sequence of thought, the tool calls, and the evaluation step in one place, which is exactly what a finance user needs when trust is the bottleneck.
What It Competes With, and What It Refuses to Be
The easiest comparison is with libraries like yfinance and pandas-datareader. Those are excellent for data extraction, but they are not trying to run a research workflow with critique, memory, and domain-specific skills.
That is the key distinction. dexter-kabu-jp is not just a better scraper. It is a more opinionated way to do analysis.
| Tool | Strength | Gap relative to dexter-kabu-jp |
|---|---|---|
| yfinance | Quick access to broad market data | No embedded evaluation loop or research workflow |
| pandas-datareader | Convenient DataFrame ingestion | Not tuned for JP-specific analyst tasks |
| Generic chat agent | Natural language interaction | Weak on verification and repeatable finance structure |
| JPX utility scripts | Niche data handling | Usually lack orchestration and critique |
A Personal Research Desk, Not a Prompt Wrapper
The architectural through line is clear. Actor, critic, skills, memory, and terminal UI all point toward the same goal: make finance AI behave less like autocomplete and more like a disciplined junior analyst.
That is why the project feels promising even in an early state. It does not just answer questions about Japanese stocks. It tries to make those answers more trustworthy, more reusable, and more grounded in the actual workflow of research.