You write a Solana app and the questions that come up while you're writing it almost never live in the same place as the code. You want a fee sample for an address that touches Raydium so you can decide whether your priority-fee bid is going to land or sit. You want to know what your account balance is before you spin up a heavier plan. You want to scaffold a copy-trader because you've thought of a strategy and you'd rather see it move on chain before you talk yourself out of it. You want your editor's AI to stop hallucinating gRPC field names that haven't existed since the Yellowstone proto last changed.
Every one of those is a context switch. Tab over to the dashboard, click through. Open a new terminal, dig out the right curl. Re-explain to the agent that no, this is Jetstream's proto, not Yellowstone's, and the field is account_include, not account_filter. Each one is small. They add up.
The three things below close those gaps where they actually live: in your terminal, in your agent's context window, and in the chat surface where you're already typing.
The CLI
orbitflare is a single binary that puts every piece of the OrbitFlare surface area one command away from your shell. RPC queries, two flavors of gRPC streaming, WebSocket subscriptions, project scaffolding from a small library of templates, login and key management, plan browsing, on-chain top-ups in USDC, and a TUI dashboard for watching the whole account move in real time. Every command supports --json, so you can pipe any output into the next thing in the chain.
cargo install orbitflare
orbitflare auth login --x-orbit-key ORBIT-...
That's the install and the one-time login. Credentials land in the OS keychain, the RPC license key gets pulled in for you so you don't have to thread it through every command, and orbitflare auth status is there when you need to confirm which profile you're talking to.
rpc handles one-shot reads:
orbitflare rpc slot
orbitflare rpc balance <ADDRESS>
orbitflare rpc tokens <WALLET>
orbitflare rpc tx <SIGNATURE>
orbitflare rpc history <WALLET> --limit 50
ws mirrors Solana's four pubsub subscription types. Each takes a --commitment to override the default and a --json flag for one-line-per-update output:
orbitflare ws slot
orbitflare ws account EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
orbitflare ws logs --mentions 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
orbitflare ws signature <sig>
--ws-url is global and auto-derived from your RPC URL when you don't pass one, which is most of the time.
jet and grpc are the firehoses. Both take a YAML config that describes which transactions, accounts, or slots you want to see, expand ${ENV_VAR} references inline, and stream the matching events as they happen:
orbitflare jet --config stream.yml
orbitflare grpc --config grpc-stream.yml
template --list shows what's available and template --install <name> clones the chosen example into your working directory, which is the fastest way to see how an OrbitFlare-shaped project is wired end to end:
orbitflare template --install solana-copy-trader
plan list, plan compare --all, pay check-balance, and pay topup <AMOUNT> cover the account side, the same things you'd otherwise be clicking through the dashboard to reach. dashboard opens the TUI when you want all of it in one panel.
Streaming and RPC inside the CLI run on top of the published orbitflare-sdk crate, which means multi-endpoint failover, exponential retry with jitter, active ping/pong liveness checks, automatic reconnection on disconnect, and URL sanitization that keeps your api key out of error messages and tracing spans all come along for free.
Skills
If you've spent any time in Claude Code, Cursor, or Codex, you've already noticed the model is confident about Solana in general and confidently wrong about Solana specifics maybe a third of the time. It writes you a getProgramAccounts call without the dataSlice you almost certainly need. It assumes Jetstream's proto looks like Yellowstone's because Yellowstone is what's in its training set and Jetstream isn't. It invents CLI flags that don't exist because flag shapes are the kind of thing models are happy to extrapolate.
@orbitflare/skills fixes the OrbitFlare half of that. One npx command drops the skill into your agent's skills directory:
npx @orbitflare/skills@latest # ~/.claude/skills/orbitflare
npx @orbitflare/skills@latest --project # ./.claude/skills/orbitflare
npx @orbitflare/skills@latest --cursor # ~/.cursor/skills-cursor/orbitflare
npx @orbitflare/skills@latest --codex # ~/.codex/skills/orbitflare
A SKILL.md and a references/ folder land on disk, all pulled straight from the official documentation. The contents cover the things a generic Solana training set tends to miss. Which transport fits which question. The two-key model: ?api_key= on the URL for chain reads, X-ORBIT-KEY in a header for the Customer API. What getTransactionsForAddress does in one call that stock getSignaturesForAddress plus a getTransaction fan-out can't match. The exact YAML shape orbitflare grpc and orbitflare jet expect.
Restart the agent and try something you'd otherwise have to spell out the long way:
Stream Pump.fun trades using OrbitFlare Jetstream.
The agent reaches into the skill, writes a jetstream.yml with the right account_include, and hands you back the orbitflare jet --config jetstream.yml to run. Ask for the same thing in Rust and it pulls in orbitflare-sdk with the jetstream feature and writes out the JetstreamClientBuilder chain. The model could have guessed something plausible on its own. With the skill, the first guess is the right one.
The MCP server
@orbitflare/mcp is an MCP server that exposes 53 OrbitFlare capabilities as discrete tools, one per capability, so any MCP host (Claude Desktop, Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, VS Code) can call them directly from the chat window.
Most hosts share the same JSON block, pointed at npx:
{
"mcpServers": {
"orbitflare": {
"command": "npx",
"args": ["@orbitflare/mcp@latest"],
"env": {
"ORBITFLARE_API_KEY": "your-license-key",
"ORBITFLARE_NETWORK": "mainnet"
}
}
}
}
The file path varies by host (Claude Desktop's claude_desktop_config.json, Cursor's ~/.cursor/mcp.json, Codex CLI's TOML at ~/.codex/config.toml), but the shape is the same. If you'd rather not put the key in the host config, drop the env block and call setApiKey from the chat once.
MCP works best when the question maps cleanly to a single capability. The model picks the tool, you don't:
What's a competitive priority fee right now for an account that touches Raydium?
That fans out to getRecentPrioritizationFees with the right address, and the model summarizes the P50/P75/P90/P99 percentiles into chat. You don't have to know the JSON shape of the response.
Build me a Yellowstone gRPC config that streams Jupiter swap transactions from Frankfurt.
That hits subscribeTransactions, which returns a ready-to-use YAML you can drop straight into orbitflare grpc --config.
Quote 1 SOL to USDC with 0.3% slippage.
That hits getSwapQuote, which runs through Jupiter Metis routing. SOL and USDC get auto-resolved to their mint addresses, and the response carries the route, expected output, and price impact.
All 53 tools are independently callable. No internal action router, no pagination dance for large payloads, and setApiKey swaps either of the two keys at runtime.
The docs are also exposed as MCP resources under orbitflare://docs/*, so the model grounds answers in pages it can actually quote.
Three places, one stack
Three different surfaces, same stack underneath. Same license keys. Same eleven regions (ash, ny, la, slc, ams, fra, lon, dub, siau, tok, sgp). Same docs, just exposed differently to whichever surface is asking.
Pick whichever fits how you work. The CLI when you're in a shell. The skill when you're in your IDE with an agent open. The MCP server when you're in a chat window and would rather not turn the question into a coding task in the first place. You'll probably end up with all three.
Resources
If you build something with any of these, or run into a rough edge that should be smoother, we'd love to hear about it and help you out.
Top comments (0)