Henosis CLI
Henosis CLI is a multi-provider coding agent for your terminal.
Use frontier models from every major provider in one workflow, point them at your codebase, and keep work connected across the CLI, Henosis Chat, and Remote Control. Bring your own API keys, use your Codex subscription where supported, or run on Henosis credits.
Why Henosis CLI
- Work across providers without vendor lock-in
- Let agents read files, apply patches, and run commands with configurable controls
- Continue the same threads between browser, terminal, and remote sessions
- Monitor and steer active sessions from the web with Remote Control
What it does
Henosis CLI gives you a connected coding workflow across terminal and web.
With Henosis CLI, you can:
- chat with leading models from OpenAI, Anthropic, Google, xAI, DeepSeek, Moonshot, and more
- switch models as a task evolves instead of committing to a single provider
- run long-lived coding sessions against your repository
- review and approve sensitive actions before they execute
- keep threads, context, and billing connected with the Henosis web app
- monitor active CLI sessions remotely with
--agent-mode
Core capabilities
- Interactive chat over SSE with usage and cost summaries
- Model picker and per-turn controls
- Local tool execution with configurable approval levels
- Workspace and host-scope filesystem controls
- Optional web search controls for supported OpenAI models
- Thread persistence and usage tracking through the Henosis backend
- Remote Control support for monitoring and steering active terminal sessions
Install
- pip:
pip install henosis-cli
- pipx:
pipx install henosis-cli
Quick start
- Run the CLI:
henosis-cli
- Default server:
https://henosis.us/api_v2
- Override server:
henosis-cli --server https://your-server
- Dev server:
henosis-cli --dev
When prompted, sign in and choose a model. Tools are enabled by default.
Common commands
/menuor/settings— open settings/model— open the model picker/model <name>— set a model directly/tools on|off|default— toggle tool availability/fs workspace|host|default— choose filesystem scope/hostbase <abs path>— set the host scope root/level 1|2|3— choose approval level/map on|off— injectCODEBASE_MAP.mdinto the first message/websearch on|off|domains|sources|location— configure web search options/title <name>— rename the current thread/clear— clear chat history/login,/logout,/whoami— auth helpers
Gemini 3.6 Flash
The backend and CLI support gemini-3.6-flash with a 1,048,576-token context
window and 65,536-token maximum output. Standard pricing per 1M tokens is
$1.50 input, $0.15 cached input, and $7.50 output (including thinking tokens).
Supported thinking levels are minimal, low, medium, and high. Gemini
3.6 requests omit the deprecated temperature, topP, and topK parameters.
Configuration
Server URL
- Env:
HENOSIS_SERVER
- Flag:
--server
- Dev shortcut:
--devusesHENOSIS_DEV_SERVERorhttp://127.0.0.1:8000
Agent Mode
- Enable remote session connectivity with:
--agent-mode
Local tools and approvals
Henosis CLI can execute a controlled set of local tools when requested by the server.
Available tool categories include:
- file reading and writing
- directory listing
- patch application
- command execution
- managed background processes
- managed interactive terminals
Approval levels:
- Level 1 — read-only
- Level 2 — write and exec actions require approval
- Level 3 — unrestricted local execution
Filesystem modes:
- workspace — sandboxed to the current working directory by default
- host — restricted to a chosen Agent scope directory
You can also override the workspace root with:
--workspace-dir /path/to/rootHENOSIS_WORKSPACE_DIR=/path/to/root
Remote Control
Henosis CLI supports a connected remote workflow through Agent Mode.
Start the CLI with:
henosis-cli --agent-mode
Then open Remote Control at:
https://henosis.us/agent
From there, you can:
- monitor active sessions
- review terminal state
- send follow-up instructions
- handle approvals from the web
- reconnect without losing session continuity
Background Mica on a connected terminal
When a primary terminal connects to authenticated Remote Control, supported,
configured ready local subscription/BYOK model/routes are advertised for
background Mica, independently of the foreground model and route defaults.
Automatic startup is quiet: it prints no Mica enabled/unavailable banner.
No empty terminal or /mica serve command is required. The terminal can keep
its ordinary conversation and work while a separate Mica request runs.
On https://henosis.us/mica, use the same Henosis account, refresh execution
readiness, select Connected CLI subscription (or BYOK) and the advertised
model/executor, then explicitly send. Read & remember still requires the Mica
disclosure consent. Connection alone sends nothing, and an unavailable local
route never falls back to Henosis credits. Machine Link ownership is unrelated.
The background lane has fresh private provider state and does not import the terminal's history, system prompt, AGENTS, or native continuation. It has no filesystem, shell, or browser tools, regardless of ordinary tool/trust settings. Only one active/unresolved Mica request can own a terminal at a time; that limit is separate from ordinary foreground work. Explicitly granted remote-agent delegation and per-turn memory tools remain separately authorized.
/mica statusshows local readiness, execution mode and negotiated catalog./mica stoppauses Mica for this process, including reconnects; it does not cancel/resend an active or unknown turn. Observe that turn before stopping./mica onor/mica serveexplicitly enables background mode again.- To disable automatic background availability across launches, set
HENOSIS_MICA_BACKGROUND=offin the launching environment. Explicit/mica onstill enables it for that process. /mica serve dedicatedand/mica serve delegatedare explicit opt-ins for the local-tool executor: an empty idle terminal is required, ordinary input is blocked, and existing scope/approval controls apply.
Catalog protocol v1 must be negotiated by the authenticated server registration. Older servers retain exact selected-only legacy background behavior; the CLI does not pretend that they accepted a multi-model catalog. Catalog entries contain only model/route/memory-tool capability and static descriptive profile metadata, never keys or account credentials (256 entries/64 KiB maximum, fail closed). Dedicated/delegated executors and ordinary-chat attachments remain selected-only.
Private adapters use Responses (Codex/OpenAI/Meta/xAI), Anthropic Messages
(Direct OAuth or BYOK), Chat Completions (DeepSeek/Kimi/GLM), Gemini
generateContent, and distinct Gemini Argon Interactions. Argon uses the native
stored background interaction contract: Google stores those interactions;
other private Responses requests use store=false. Native reasoning/signatures
remain private to a turn. Foreground inference settings are not inherited.
Coverage uses isolated fake provider HTTP and a real owned loopback browser,
not live-provider acceptance or proof of account entitlement.
Real local credential/profile/account changes, session resets, executor mode changes and socket generations fence continuation. A foreground model/default change alone does not reselect a catalog request. Ambiguous effects block all catalog pairs on that terminal and are never automatically retried or sent by a fallback route. This does not expand hosted-credit models or attach Mica memory to ordinary chat.
Troubleshooting
If a provider streams deltas but never sends a final message.completed, the CLI prints a diagnostics block with:
- stream stats
- recent event tail
- relevant response headers
It also writes the same information to:
logs/session-*.jsonl
Useful flags and environment variables:
--debug-sse--debug-reqHENOSIS_CLI_SSE_TAIL=80
Minimal test harness:
python test_stream.py
Optional overrides:
HENOSIS_TEST_URLHENOSIS_TEST_MODELHENOSIS_TEST_PROMPT
Requirements
- Python 3.9+
- Rich terminal support is included by default
- The reusable local tools library is available as
henosis_cli_tools
Support
- Email:
henosis@henosis.us
1 maintainer
Metadata
1 maintainer
Release files for henosis-cli 0.6.200
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| henosis_cli-0.6.200.tar.gz | 1.1 MB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| henosis_cli-0.6.200-py3-none-win_amd64.whl | Python 3 | none | Windows x86-64 | Details |
Total release size: 4.3 MB
Release files / henosis_cli-0.6.200.tar.gz
| Download URL | henosis_cli-0.6.200.tar.gz |
|---|---|
| Size | 1.1 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
af239fa5c693511d24b1434671c9c4ba742d9426529a926d9846e6bc17d98d95
|
|
BLAKE2b-256 checksum How to use checksums |
074329dbca190c1684eac488a50a8da6cb9c5a87472bd8bbf0c24c578de846f6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.12.4
|
Release files / henosis_cli-0.6.200-py3-none-win_amd64.whl
| Download URL | henosis_cli-0.6.200-py3-none-win_amd64.whl |
|---|---|
| Size | 3.2 MB |
| Tags | Python 3 Windows x86-64 |
|
SHA-256 checksum How to use checksums |
e74b6627f2d80fa37b41041a41142396ac24929ec9196ff7b841acca8fad8ae9
|
|
BLAKE2b-256 checksum How to use checksums |
847441891264a9625fe922b8cdd7c715e1e32bec738fc68d689a4bb5f6e1ef77
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.12.4
|
Security for henosis-cli 0.6.200
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
