cc-fleet

module
v0.3.2 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jul 12, 2026 License: Apache-2.0

README ยถ

๐Ÿšข cc-fleet

๐Ÿค– Plug any third-party model into Claude Code's โš™๏ธ Dynamic Workflows, ๐Ÿ‘ฅ Agent Teams, and โšก Subagents โ€” from DeepSeek ยท GLM ยท Kimi ยท Qwen โ€ฆ to your Codex subscription, with your main session's auth untouched; no Claude subscription needed to run a full Claude Code on any provider ๐Ÿš€


Claude Code's multi-agent orchestration โ€” Dynamic Workflows, Agent Teams, Subagents โ€” only runs Anthropic's own models. cc-fleet lets any model with an Anthropic- or OpenAI-compatible API, even your Codex subscription, join as a workflow leaf, a long-lived teammate, or a one-shot subagent โ€” scheduled by your main session, with the same identity and capabilities as a native Claude agent.

Every third-party worker is a real claude process with its LLM backend swapped to the provider, so Claude Code drives it exactly like a native agent. Your main session's own auth (OAuth subscription or API key) is untouched, and provider keys never enter env, argv, or shell history โ€” zero leak risk.

Two steps to get going: one-line install, register a provider. Then state your intent in Claude Code with /workflow, /team, or /subagent โ€” or just describe the task in plain language, and Claude figures out the rest.

No Claude subscription? ccf run <provider> starts an interactive session driven by that provider โ€” the same claude you know, just running on the provider's model.

cc-fleet can be driven from Codex too: a Codex plugin gives a Codex session the same fan-out โ€” cc-fleet subagent and cc-fleet workflow, with the claude engine as the worker. (Teammates stay Claude-Code-only.)

Install

0. Install Claude Code first โ€” cc-fleet drives the official claude CLI, so install it if you don't have it yet (skip if claude is already on your PATH):

macOS / Linux:

curl -fsSL https://claude.ai/install.sh | bash

Windows (PowerShell):

irm https://claude.ai/install.ps1 | iex

1. Install cc-fleet with the one-line script (recommended) โ€” one command does it all: downloads and verifies the CLI, puts it on your PATH (with a ccf alias, so ccf launches it from then on), and installs the Claude Code plugin (skill + session hook) via the marketplace. Ready to use right after:

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/ethanhq/cc-fleet/main/install.sh | sh

Windows (PowerShell):

irm https://raw.githubusercontent.com/ethanhq/cc-fleet/main/install.ps1 | iex

Codex plugin โ€” to drive cc-fleet from a Codex session, after the install above run codex plugin marketplace add ethanhq/cc-fleet then codex plugin add cc-fleet.

Other channels (npm / go install / Releases / source) and adding the Claude Code plugin, installer overrides, and requirements & maintenance live in Install & maintenance.

Common commands:

ccf                      # open the interactive TUI
ccf doctor               # health check: dependencies, providers, plugin status
ccf update               # self-update by install channel + refresh the plugin
ccf uninstall --all      # remove the binary and plugin too

Once installed, run ccf to register a provider and start delegating.

Quickstart

๐Ÿ”Œ Provider management โ€” one API key, connected

provider management demo
  1. ccf opens the TUI; choose Add provider
  2. Pick any Anthropic / OpenAI-compatible vendor
  3. Enter the API key and default model; optionally an effort level and a Claude permission mode
  4. Save and go; add more models and toggle them in the list, s sets the default, d deletes
  5. (Optional) Add Codex: reuse an existing OAuth, or log in fresh

๐Ÿ–ฅ๏ธ ccf run โ€” run Claude Code on any provider

ccf run demo
  1. ccf run launches an interactive claude on your default provider; ccf run <provider> picks one
  2. All tools, the full REPL; no Anthropic subscription, your main session's login untouched
  3. Switch anytime mid-session: /model for the model, /effort for thinking effort, Shift+Tab for permission mode

โš™๏ธ Dynamic Workflows โ€” the same orchestration API as native workflows

dynamic workflow demo
  1. /workflow to kick it off, or just tell Claude: "map each module with deepseek, glm drafts an audit checklist per module, gpt synthesizes"
  2. Claude writes the JS script and runs it in the background โ€” no tokens off your main session
  3. workflow wait blocks until it finishes โ€” event-driven, no polling
  4. The TUI board shows every leaf and phase live โ€” x to hold / r to rerun a single leaf or a whole phase

๐Ÿ‘ฅ Agent Teams โ€” native multi-agent collaboration in tmux panes

agent team demo
  1. /team to kick it off, or just tell Claude: "spawn a glm and a deepseek teammate, then compare their strengths"
  2. Each teammate is a real claude process working live in a side tmux pane โ€” mix providers in one team, hand follow-ups across turns
  3. The TUI board shows each teammate's full inbox and status; h hides / s shows a pane โ€” split in the foreground or run in the background

โšก Subagents โ€” the lightest one-shot delegation

subagent demo
  1. /subagent to kick it off, or just tell Claude: "fan out kimi, qwen, and glm over these three files in parallel"
  2. Claude runs the models and collects results synchronously โ€” dispatch as many in parallel as you like
  3. slim-ro read-only mode: let a provider analyze your repo safely, without touching code
  4. The TUI board shows each job's prompt, answer, and spend

๐Ÿ“Š The TUI board โ€” your whole fleet on one screen

TUI board demo
  1. After ccf launches, press Tab for the Agents Board โ€” every Workflow / Team / Subagent laid out by project โ†’ session
  2. Open any one for detail: a Workflow's run โ†’ phase โ†’ leaf progress tree, a Team's teammate inbox, each drilling into prompt, answer, and spend
  3. Act inside the board: x / r to stop or rerun, p to pin against cleanup, c to clear finished, d to delete, h / s to hide or show a pane
  4. Finished teams stay on record; the UI follows your system light / dark theme

Deep dive

cc-fleet's capabilities fall into two groups:

  • Three delegation lanes (Workflow / Agent Team / Subagent) โ€” scheduled automatically by Claude: say what you want and the skills pick the lane and the model for you, no manual choice.
  • Provider and ccf run โ€” tools you configure and use directly.

โš™๏ธ Dynamic Workflows


Agents Board: the phase โ†’ leaf tree
drill into one leaf: full prompt and synthesized output

Orchestration API: multi-phase orchestration lives in a JavaScript file, with an API identical to Claude Code's native Workflow tool โ€” agent() starts a node, parallel() fans out, pipeline() chains a flow. The one difference is that agent() takes a provider option to assign each node's model, so different vendors mix and run in parallel within a single run:

const meta = {
  name: "api audit",
  description: "map endpoints, then draft audit checklists",
  phases: [{ title: "map" }, { title: "build" }, { title: "judge" }],
};

phase("map");
const maps = (await parallel(
  ["auth", "billing", "users"].map((m) =>
    () => agent("List the exported endpoints in module " + m, { provider: "deepseek" }))
)).filter(Boolean);

phase("build");
const checklists = await pipeline(maps,
  (endpoints, _, i) => agent("Draft an audit checklist:\n" + endpoints,
                             { provider: "glm", label: "build:" + i }));

phase("judge");
const verdict = await agent("Pick the strongest one and say why:\n" + checklists.join("\n---\n"),
                            { provider: "claude", model: "opus", label: "judge" });
return { checklists, verdict };

Running and managing: once kicked off, the whole run executes in a background engine, managed by a small command set. Runs are journaled by content hash, and budgets cap spend in USD or tokens:

RUN=$(ccf workflow run audit.js)            # starts in the background, prints the run id
ccf workflow wait "$RUN" --timeout 10m      # blocks until done, event-driven
ccf workflow stop "$RUN" --leaf build:1     # hold a single leaf (run keeps going)
ccf workflow restart "$RUN" --leaf build:1  # resume it
ccf workflow run audit.js --resume "$RUN"   # replay the journal, finished leaves hit cache

Holding and restarting: ccf workflow stop --leaf / --phase doesn't fail the run โ€” it just pauses the named node: the run keeps going and other nodes carry on, until you restart it to run again. If every node currently running gets paused, the whole run settles into a parked state that needs you to step in before it continues.

Wait without polling: ccf workflow wait blocks until the run ends, then exits โ€” drop it in the background and come back when it exits, no repeated checking. The exit code states the outcome: 0 succeeded, 1 failed, 3 parked and waiting, 124 wait timed out (run still going), 130 interrupted.

Budget-adaptive: budget.spent() / budget.remaining() are readable live inside the script (USD or tokens), so a workflow can decide for itself whether to dispatch another batch.

Mixing in your own subscription: a node assigned provider: "claude" runs on your own Claude login โ€” the judge above uses your subscription, not a provider key, which suits a synthesis-and-finish node.


๐Ÿ‘ฅ Agent Teams


four teammates working side by side in tmux panes
a teammate's overview / messages / output on the board

Prerequisites: Agent Team is the only lane that needs setup up front, and because it relies on tmux it doesn't support Windows yet. Two conditions before you use it:

  1. Be inside a tmux session (tmux new-session -s work) so teammate panes can show up alongside you;
  2. Enable Claude Code's agent-teams: the first time you run ccf it detects this isn't on and offers to write it in for you โ€” or add it once yourself to ~/.claude/settings.json:
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

How they collaborate: each teammate is a real claude process; Claude builds the team with native TeamCreate and assigns work with native SendMessage, and teammates stay alive across turns so you can keep adding tasks. One team can use several providers at once, then have one teammate gather and compare the results.

Permission inheritance: each teammate inherits your main session's permission posture (plan / acceptEdits / default). If that can't be detected, it falls back to the safest default and won't open up risky permissions on its own.

Park and restore: ccf hide tucks a teammate's pane out of the way while the process keeps running โ€” messages and context are never lost โ€” and ccf show brings it back. At cleanup, ccf teardown thoroughly clears every related process, including ones still running in the background and consuming the key after their pane was closed, so no ghost quietly bills you.

Outside tmux: the teammate runs in a background cc-fleet-swarm-<team> session, exactly the same flow with the pane just not on screen. To look in, attach with tmux -L cc-fleet-swarm-<team> attach.


โšก Subagents


fan out three subagents in parallel from one ask
the job list and one job's detail

Three run modes: the default slim sends the model a trimmed system prompt with a narrowed tool set, so the first request is much smaller than a full session โ€” cheaper and faster on metered providers. --profile slim-ro is read-only, with tools cut to inspection only (Bash / Glob / Grep / Read / Skill) and no creating, editing, or deleting files, so a provider can read code and check logs without touching your workspace. Use --profile full when you need full-session capability.

Tool trimming and parallelism: --tools takes a comma-separated list to set exactly which tools are open (a replacement, not an addition to the defaults), --skills=false turns off the Skill tool, and --mcp controls whether the host MCP config carries over. A subagent builds no team, takes no pane, and holds no locks, so running many against one provider doesn't interfere โ€” ideal for large batches in parallel.

Background and wake-up: add --background to send a long job to the background, then ccf subagent-status <job> --wait blocks until it's done and wakes the session that launched it โ€” no repeated checking. Each job is capped by spend (USD), turns, and timeout, and a failure returns a fixed error_code your program can branch on.

Structured result: with --json you get a result object with fixed fields, easy for scripts to parse โ€” besides the answer text it includes the model id that actually responded, the call's spend, token usage, turns, and session_id.

Run key nodes on your own subscription: as with Workflow, setting the provider to the reserved name claude (ccf subagent claude --model opus โ€ฆ) uses your own Claude login and bills your subscription โ€” good for a synthesis-and-finish node, not large parallel batches.


๐Ÿงฉ Drive from Codex

cc-fleet plugs into OpenAI Codex too: a Codex plugin lets a Codex session fan out the same provider workers โ€” one-shot or batch subagents (cc-fleet subagent) and multi-phase JS workflows (cc-fleet workflow), each a real claude process on the provider's model. Install it with codex plugin marketplace add ethanhq/cc-fleet then codex plugin add cc-fleet (the cc-fleet and claude binaries install separately). The teammate lane stays Claude-Code-only; from Codex you get the subagent and workflow fan-out.


๐Ÿ”Œ Provider management


presets for many vendors
set each tier's model, effort, and permission

Broad compatibility: works with any Anthropic- or OpenAI-compatible API endpoint โ€” the former includes DeepSeek, Kimi, GLM, Qwen, and more; the latter Groq, Together, Fireworks, a local vLLM, and OpenAI itself. Common vendors ship as presets โ€” select one and the endpoint and protocol are filled in, no manual entry; for anything not listed, pick Custom and enter the address.

Model tiers: each provider can carry default / strong / fast model slots, each separately taggable with 1M context and a reasoning effort. So Claude just asks for "the strong model" โ€” no hardcoded model IDs. ccf default <provider> sets the fleet-wide default provider, and any call that doesn't name one goes to it.

Multi-key rotation: one provider can hold several API keys, rotated by off / round_robin / random to spread quota and avoid rate limits.

API key protection: a key is fetched only at request time, emitted once, and never written into environment variables, command-line arguments, or shell history; a worker process starts with the main session's credentials cleared, so the two never leak into each other. On disk it's saved 0600, readable only by you, or handed to pass, 1Password, Vault, or your OS keyring; every UI and log shows the key masked (sk-โ€ฆ238).

Codex (ChatGPT subscription): one device-code login and your ChatGPT subscription becomes a regular provider โ€” usable across Workflow / Team / Subagent / run.

[!WARNING] Codex is unofficial. Reusing a ChatGPT subscription outside the codex CLI may violate OpenAI's terms, and ccf codex login asks you to confirm first. The OAuth token lives only inside the local conversion daemon; cc-fleet keeps its own login chain and never touches the codex CLI's auth.


๐Ÿ–ฅ๏ธ ccf run


one-line launch: ccf run / ccf run codex
inside, it's a full claude โ€” here on gpt-5.5

Launch: ccf run <provider> opens an interactive claude on the named provider; with no provider (ccf run) it resolves to the fleet-wide default.

ccf run deepseek        # an interactive claude, on DeepSeek, billing the provider key

It's just native claude: ccf run adds no extra process layer โ€” it replaces itself with claude, cc-fleet steps out entirely, and from then on it's a plain claude process whose feel and exit behavior match typing claude yourself.

Credentials isolated automatically: even if you run it from inside a logged-in Claude Code session, it first clears any leftover Anthropic auth from the environment and uses the chosen provider's auth instead โ€” so billing lands on the provider's key, never your own subscription.

Flags:

  • --model strong / fast โ€” override the default with the provider's strong or fast model
  • --permission-mode โ€” set the permission posture
  • -- <claude args> โ€” everything after is passed through verbatim to the underlying claude

[!NOTE] This lane is for hands-on interactive use: it needs a real terminal and doesn't support pipes or redirects โ€” for non-interactive, one-shot output use a Subagent instead.

Documentation

  • CLI reference & advanced usage โ€” every command, flag, and envelope.
  • Writing workflows โ€” the JS scripting API for the workflow lane.
  • Architecture โ€” how spawning, key safety, the conversion daemon, and the workflow engine actually work.
  • ccf <cmd> --help โ€” always authoritative.

Contributing

PRs are very welcome โ€” bug fixes, new provider presets, docs, tests, features. Please read the contribution guide first; a few house rules:

  • UI changes and bug fixes need a screenshot or GIF in the PR.
  • AI-assisted commits credit the tool with a Co-Authored-By trailer.
  • Fully AI-authored PRs add an autonomous-PR marker at the bottom of the PR body.

License

Apache-2.0.

Directories ยถ

Path Synopsis
cmd
cc-fleet command
Command cc-fleet is the CLI entry point for the cc-fleet provider-profile manager.
Command cc-fleet is the CLI entry point for the cc-fleet provider-profile manager.
internal
ccver
Package ccver locates the installed `claude` binary and reports its version.
Package ccver locates the installed `claude` binary and reports its version.
childenv
Package childenv builds the environment handed to a child claude process that cc-fleet launches โ€” a one-shot subagent (`claude -p`) or an interactive `run` session.
Package childenv builds the environment handed to a child claude process that cc-fleet launches โ€” a one-shot subagent (`claude -p`) or an interactive `run` session.
codexproxy
Package codexproxy hosts the local Anthropic-Messages <-> OpenAI-Responses conversion daemon that lets a Codex/ChatGPT subscription drive OpenAI models as a cc-fleet provider.
Package codexproxy hosts the local Anthropic-Messages <-> OpenAI-Responses conversion daemon that lets a Codex/ChatGPT subscription drive OpenAI models as a cc-fleet provider.
config
Package config reads, writes, and validates ~/.config/cc-fleet/providers.toml.
Package config reads, writes, and validates ~/.config/cc-fleet/providers.toml.
diag
Package diag is the --verbose diagnostic sink: a tiny injected logger that timestamps, redacts, and serializes step-trace lines.
Package diag is the --verbose diagnostic sink: a tiny injected logger that timestamps, redacts, and serializes step-trace lines.
doctor
Package doctor implements the health checks behind `cc-fleet doctor`, split into a Core group (every run mode) and an Optional group (live teammates only โ€” tmux).
Package doctor implements the health checks behind `cc-fleet doctor`, split into a Core group (every run mode) and an Optional group (live teammates only โ€” tmux).
fileutil
Package fileutil holds small file-system primitives shared across cc-fleet.
Package fileutil holds small file-system primitives shared across cc-fleet.
fingerprint
Package fingerprint provides the per-cc-version spawn template (env vars + flag list) that cc-fleet replays when launching provider teammates.
Package fingerprint provides the per-cc-version spawn template (env vars + flag list) that cc-fleet replays when launching provider teammates.
homedir
Package homedir is the single home-directory resolver for every package that roots config state under the user's home (~/.config/cc-fleet, ~/.claude).
Package homedir is the single home-directory resolver for every package that roots config state under the user's home (~/.config/cc-fleet, ~/.claude).
ids
Package ids validates cc-fleet identifiers (team names, member names) that flow into filesystem paths, tmux labels, inbox file names, and agent IDs.
Package ids validates cc-fleet identifiers (team names, member names) that flow into filesystem paths, tmux labels, inbox file names, and agent IDs.
leadsession
Package leadsession detects the parent Claude Code session for commands that are launched from a Claude Bash tool but do not otherwise have a team context.
Package leadsession detects the parent Claude Code session for commands that are launched from a Claude Bash tool but do not otherwise have a team context.
models
Package models caches and refreshes per-provider model lists fetched from each provider's `/v1/models` endpoint.
Package models caches and refreshes per-provider model lists fetched from each provider's `/v1/models` endpoint.
neterr
Package neterr centralizes the single question three call sites need to answer the same way: did a request fail at the transport layer โ€” before any HTTP response came back?
Package neterr centralizes the single question three call sites need to answer the same way: did a request fail at the transport layer โ€” before any HTTP response came back?
onboarding
Package onboarding implements cc-fleet's first-run guided setup: it nudges about the agent-teams prerequisite for provider teammates, guides the user to fix it WITH CONSENT, and persists the user's decision so later runs never re-nag.
Package onboarding implements cc-fleet's first-run guided setup: it nudges about the agent-teams prerequisite for provider teammates, guides the user to fix it WITH CONSENT, and persists the user's decision so later runs never re-nag.
panevis
Package panevis orchestrates hiding and showing a teammate's tmux pane without killing its process.
Package panevis orchestrates hiding and showing a teammate's tmux pane without killing its process.
permmode
Package permmode is the shared permission-mode vocabulary for cc-fleet's claude launchers (spawn teammates and run sessions): the --permission-mode enum, its validation, and the enumโ†’CLI-flag mapping.
Package permmode is the shared permission-mode vocabulary for cc-fleet's claude launchers (spawn teammates and run sessions): the --permission-mode enum, its validation, and the enumโ†’CLI-flag mapping.
pinned
Package pinned is an out-of-band registry of the board records a user has chosen to keep.
Package pinned is an out-of-band registry of the board records a user has chosen to keep.
procintrospect
Package procintrospect provides the small set of process-introspection operations cc-fleet performs by reading process state: a process's argv, its immediate child pids, and the whole process table.
Package procintrospect provides the small set of process-introspection operations cc-fleet performs by reading process state: a process's argv, its immediate child pids, and the whole process table.
profile
Package profile generates the per-provider JSON files that Claude Code loads via its `--settings` flag (a.k.a.
Package profile generates the per-provider JSON files that Claude Code loads via its `--settings` flag (a.k.a.
providerclass
Package providerclass is the one shared place that turns a raw provider failure into a stable, key-safe classification.
Package providerclass is the one shared place that turns a raw provider failure into a stable, key-safe classification.
redact
Package redact masks key-like tokens in any text that may flow into a JSON envelope or error message.
Package redact masks key-like tokens in any text that may flow into a JSON envelope or error message.
run
Package run implements `cc-fleet run <provider>` (lane 0): launch an interactive foreground claude REPL backed by a provider's profile + default model, handing the process over to claude (an execve on unix, a wait-on-child on Windows).
Package run implements `cc-fleet run <provider>` (lane 0): launch an interactive foreground claude REPL backed by a provider's profile + default model, handing the process over to claude (an execve on unix, a wait-on-child on Windows).
secrets
Package secrets dispatches provider API-key lookups across pluggable backends.
Package secrets dispatches provider API-key lookups across pluggable backends.
selfupdate
Package selfupdate updates the cc-fleet binary and its Claude Code plugin to the latest GitHub release.
Package selfupdate updates the cc-fleet binary and its Claude Code plugin to the latest GitHub release.
sessiontitle
Package sessiontitle resolves human-readable session titles: Claude Code titles from transcript metadata, and Codex session titles from a rollout's first user prompt.
Package sessiontitle resolves human-readable session titles: Claude Code titles from transcript metadata, and Codex session titles from a rollout's first user prompt.
spawn
Package spawn orchestrates the end-to-end "spawn a provider teammate" flow: provider probe, profile install, fingerprint apply, team registration, and tmux split-window.
Package spawn orchestrates the end-to-end "spawn a provider teammate" flow: provider probe, profile install, fingerprint apply, team registration, and tmux split-window.
subagent
Package subagent runs a ONE-SHOT, HEADLESS provider subagent: it launches `claude -p` backed by a third-party provider model (via the provider profile's --settings + --model) and returns the result synchronously.
Package subagent runs a ONE-SHOT, HEADLESS provider subagent: it launches `claude -p` backed by a third-party provider model (via the provider profile's --settings + --model) and returns the result synchronously.
teamhist
Package teamhist persists a board-observed snapshot of every live team so a team cleaned up by its lead keeps a presence on the Agents Board until the user deletes the record.
Package teamhist persists a board-observed snapshot of every live team so a team cleaned up by its lead keeps a presence on the Agents Board until the user deletes the record.
teardown
Package teardown removes cc-fleet teammates and team state.
Package teardown removes cc-fleet teammates and team state.
tmux
Package tmux is a thin subprocess wrapper around the `tmux` binary covering the operations cc-fleet's spawn / teardown / ps / hide-show flows need: pick a spawn target, split a window to host a teammate or create a tiled swarm session, enumerate / kill panes, kill a server, and break / join panes for hide/show.
Package tmux is a thin subprocess wrapper around the `tmux` binary covering the operations cc-fleet's spawn / teardown / ps / hide-show flows need: pick a spawn target, split a window to host a teammate or create a tiled swarm session, enumerate / kill panes, kill a server, and break / join panes for hide/show.
tui
Package tui implements the interactive terminal UI shown when cc-fleet is run bare (no subcommand) from an interactive terminal.
Package tui implements the interactive terminal UI shown when cc-fleet is run bare (no subcommand) from an interactive terminal.
userops
Package userops implements the user-layer CRUD operations behind `cc-fleet init / add / edit / remove / list / repair / uninstall`.
Package userops implements the user-layer CRUD operations behind `cc-fleet init / add / edit / remove / list / repair / uninstall`.
version
Package version exposes the cc-fleet build version.
Package version exposes the cc-fleet build version.
workflow
Package workflow is cc-fleet's deterministic orchestration runtime: it runs a JavaScript workflow script that fans out provider subagent leaves, in a cc-fleet process OFF the main Claude context.
Package workflow is cc-fleet's deterministic orchestration runtime: it runs a JavaScript workflow script that fans out provider subagent leaves, in a cc-fleet process OFF the main Claude context.
tools
sign-checksums command
Command sign-checksums is the release-side counterpart to the self-update signature verifier: it signs a release artifact (checksums.txt) with the project's Ed25519 release key, derives the public key for the release key-match preflight, or generates a fresh keypair.
Command sign-checksums is the release-side counterpart to the self-update signature verifier: it signs a release artifact (checksums.txt) with the project's Ed25519 release key, derives the public key for the release key-match preflight, or generates a fresh keypair.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL