longbridge-terminal: a Rust CLI and TUI wrapping every Longbridge OpenAPI endpoint

A CLI first, with a TUI included

The README leads with a command and its output, which is the right way to introduce a market-data tool:

$ longbridge static TSLA.US NVDA.US
| Symbol  | Last    | Prev Close | Open    | High    | Low     | Volume    | Turnover        | Status |
|---------|---------|------------|---------|---------|---------|-----------|-----------------|--------|
| TSLA.US | 395.560 | 391.200    | 396.220 | 403.730 | 394.420 | 58068343  | 23138752546.000 | Normal |

Table output for reading, and the same call with `--format json` when something else has to read it. That dual-mode design is the spine of the project, because the README says all commands support `--format json` for machine-readable output, and the reason given for a specific compatibility decision is explicit: commands taking `--count` also accept `--limit` as an alias, and the README attributes this to AI agent compatibility.

On top of that sits a full-screen terminal interface built with ratatui and crossterm, recorded in the README as an asciinema cast. The topic list carries `tui`, `ratatui` and `ai-native`, and the `Cargo.toml` shows the chart library is a local path dependency rather than a published crate. The TUI and the CLI share one token, so login happens once.

Coverage is broad enough to be worth stating plainly, because it determines whether you need a second tool. The README claims every Longbridge OpenAPI endpoint, broken into market data (quotes, depth, K-lines, options, warrants), portfolio (balances, stock and fund positions) and trading (submission, modification, cancellation, execution history).

Authentication went OAuth-only in version 0.28.5

The current release, v0.28.7 published 2026-09-16, is a one-line fix. An option `theta` is no longer divided by 252, because the API now returns a per-day value with the server dividing the raw annualised figure by 365, and the CLI stopped applying its own `/252` and displays what it is given. That is a good example of the kind of correctness work this project does: the number you see is the number the API intends.

The more consequential change is two releases earlier. v0.28.5 makes CLI authentication OAuth-only. The CLI authenticates through `longbridge auth login` and no longer reads `LONGBRIDGE_APP_KEY`, `LONGBRIDGE_APP_SECRET` or `LONGBRIDGE_ACCESS_TOKEN` from the environment. The stated reason is a real bug: a stray credential in the environment, including under the legacy `LONGPORT_` prefix or in a `.env` file, silently switched the auth mode and made the login prompt loop. The fix is labelled breaking, with instructions to run `longbridge auth login` once if you ran the CLI headless, after which the token is persisted and refreshed automatically.

The `.env.example` corroborates this. Its first lines state that OAuth2.1 is now the default method, that no environment variables are required, and that access tokens are stored in the system keychain. What remains optional is a log level, custom API endpoints via `LONGBRIDGE_HTTP_URL` and `LONGBRIDGE_QUOTE_WS_URL`, and a staging environment through `LONGBRIDGE_ENV`.

So there is no headless-by-environment path any more. For CI, the sequence is an interactive login once to a persisted token, which is a step you have to plan for rather than something that falls out of configuration.

Endpoint routing that distrusts the geo probe

The CLI has to decide whether to talk to the China Mainland endpoints or the global ones, and the way it does this is the most interesting engineering in the repository.

The first approach is a location probe: the CLI asks `geotest.lbkrs.com` which country it is in and caches the answer for six hours, so at most one command per session waits on it. China Mainland uses the `.cn` endpoints and everything else uses the global ones. You can skip the probe entirely by pinning `LONGBRIDGE_REGION=global`.

The README then explains why that is not enough. `longbridge check` never trusts the cache. It re-detects, measures the latency to both endpoints, and repins to whichever is decisively better, because location only approximates the answer and a split-tunnel proxy can send the geo probe and the API traffic over entirely different paths. The result is persisted, so later commands follow the same choice.

That is a well-reasoned answer to a problem that quietly breaks CLI tools for a lot of people with corporate VPNs. The diagnostic output showing both latencies also means you can tell which endpoint you are on without reading a config file.

The command set reflects how much of the API surface this covers. `quote`, `depth`, `trades`, `intraday`, `kline`, `kline history`, `static`, `calc-index`, `capital`, `market-temp`, `constituent`, `trading session`, `trading days`, `security-list`, `participants` and `subscriptions` are all documented in the diagnostics and quotes sections. The `subscriptions` entry, which lists active real-time WebSocket subscriptions for the session, is a nice touch for understanding what the tool is connected to.

Release notes that read like a changelog of real bugs

Reading three consecutive releases tells you more about how the project is maintained than any feature list would.

v0.28.6 has three entries and all three are about not lying to the user. `statement export` now exports legacy pre-migration statements instead of silently skipping them, and any per-file download failure is surfaced rather than swallowed. `order executions` JSON output now carries the full execution record including `order_id`, `trade_id`, `symbol`, `side`, `price`, `quantity` and `trade_done_at`, and `--history` paginates the v3 `execution/all` endpoint to completion rather than capping at 1,000 records. The third entry is cosmetic: help text now says AP accounts or US accounts consistently.

That pattern matters for a trading tool. Silent skips on a statement export and a silent 1,000-record cap on fills are both the kind of defect that makes someone believe they have the full picture when they do not.

v0.28.5 also fixed a broken-pipe error when output is truncated by `head`, which is exactly what happens when you pipe this CLI into another command, and a Shift+Tab reverse-cycling bug on K-line sampling periods. Both are small, both are the kind of thing you only find from real daily use.

The cadence is roughly weekly, each release names its pull requests, and version 0.28.7 matches the version in `Cargo.toml` exactly. The project is pre-1.0, which given the OAuth break in 0.28.5 is a fair signal to pin your version rather than track `main`.

Installing on four platforms, and what Cargo.toml reveals

Installation covers macOS, Linux and Windows through four documented routes. Homebrew uses a cask, Scoop has a manifest in `.scoop/`, PowerShell can fetch `install.ps1`, and there is a plain shell installer for macOS and Linux:

curl -sSL https://github.com/longbridge/longbridge-terminal/raw/main/install | sh

The binary lands in `/usr/local/bin` on macOS and Linux, or `%LOCALAPPDATA%\Programs\longbridge` on Windows. Note that the install script is piped straight into a shell, which is normal for this class of installer and worth a moment's thought before running it on a machine with trading credentials.

Shell completion is generated by the binary itself and needs one line in your rc file:

source <(longbridge completion bash)

Zsh and Fish equivalents are in the README, and after reloading the shell, tab completion covers subcommands, flags and values.

The `Cargo.toml` is where the honest engineering detail lives. The release profile sets `opt-level = 'z'`, LTO on, `panic = "abort"`, and strips symbols in the final binary while keeping packed debug info for `.pdb` or `.dSYM`, so crash reports work without shipping a large unstripped binary. TUI work uses ratatui, crossterm with an event-stream feature, tabled for tables and tui-markdown for rendering.

Two dependency lines deserve attention before you build from source. The SDK is pulled from git rather than crates.io: `longbridge` from the `openapi` repository and `longbridge-ai-acp` from `longbridge-ai-acp`, both tracking the `main` branch. That means your build is not fully pinned by `Cargo.lock`, and an upstream change can alter behaviour without any release of this CLI. For a tool with trading commands attached, that is the single most important thing to know before wiring it into anything automated.

Signals, strategies and the boundaries of the tool

Beyond raw data, the CLI exposes a signals surface: `longbridge signals` returns strategy signals covering headline, outlook, target prices and triggering catalyst, and filters accept `--symbol`, `--strategy-id`, `--strategy`, `--catalyst`, `--catalyst-type`, `--start`, `--end` and `--offset`. This is the part of the command set that goes beyond a data API, and it is worth being clear-eyed about what that means: those fields describe analysis generated elsewhere, and the CLI is a delivery mechanism for them rather than a source of the underlying reasoning.

The same applies to `market-temp`, which returns a 0 to 100 sentiment index where higher means more bullish. It is a number the platform computes, and treating it as a signal rather than an indicator is a decision you make, not one the CLI makes for you.

Some commands show unusual ambition and are worth trying first. `constituent` can pull full holdings for a US ETF from SEC N-PORT filings, using `--limit 0` for all of them, and falls back to platform asset allocation when the SEC data is unavailable, which is the case for something like SPY. Index symbols for US markets need a leading dot, so `.SPX.US` or `.DJI.US`. `brokers` gives the broker queue at each price level in the Hong Kong market, and `calc-index` returns computed fundamentals like PE, PB and EPS with a `--fields` filter.

What this tool is not is a strategy engine, a backtester or a portfolio manager. It is a fast, scriptable, well-documented way to get data out of Longbridge and place orders, and the reliability work in the recent releases is concentrated on making sure it never quietly shows you less than it has.

Editorial conclusion

The case for longbridge-terminal is speed at the edges rather than feature count. A quote, a portfolio check and an order review become shell commands that pipe into `jq`, and the same commands work as agent tool calls, which is why the project bothers with `--limit` as an alias for `--count` and why every release note is written around making JSON output correct. The costs are honest ones: the project is pre-1.0 at 0.28.7, v0.28.5 made OAuth the only authentication method and broke headless credential environments on purpose, and the SDK is consumed as a git dependency tracking the `main` branch, so a build is not fully reproducible from `Cargo.lock` alone. Install it, run `longbridge check` to see which endpoint it picked, and start with read-only commands before you trust it with an order.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. longbridge/longbridge-terminal on GitHub
3. Project website
4. README
5. Releases