Opviera CLI
An agentic coding tool for your terminal, wired to the Opviera platform. It runs against your organisation’s gateway and nothing else: your administrator issues you a key, the CLI validates it, scopes your work to a project, and every request is metered against your organisation’s quotas and budgets.
There is no separate model subscription to manage, and no way to route work somewhere unbilled.
Install
One command. The installer detects your operating system and CPU, downloads the matching build, and puts the opviera binary on your PATH.
curl -fsSL https://opviera.ai/install | bash
Supported platforms: macOS and Linux on arm64 and x64, and Windows on x64. On Linux the installer picks a musl build on Alpine, and a baseline build automatically on CPUs without AVX2.
Sign in
You need two things from your administrator: an Opviera API key beginning vsk_, and the name of the project your work should be billed to.
Run the CLI in your project directory and enter both when prompted. The key is validated against the gateway before the agent starts, then stored in ~/.local/share/opviera/auth.json with 0600 permissions — so you do this once.
cd <your-project>
opviera
CI and containers
Where there is no terminal to prompt at, supply the credential through the environment instead. It is validated exactly the same way — this supplies the key, it does not skip the check.
export OPVIERA_API_KEY=vsk_…
export OPVIERA_PROJECT_ID=your-project
OPVIERA_PROJECT_ID is required when your key’s policy restricts it to particular projects. If you omit it in that case the CLI stops and lists the projects the key is allowed to use, rather than guessing.
Configuration
Project settings live in opviera.json (or opviera.jsonc) in your project directory, with global defaults in ~/.config/opviera/.
| Environment variable | What it does |
|---|---|
OPVIERA_API_KEY |
Your vsk_… key. Use instead of the interactive sign-in. |
OPVIERA_PROJECT_ID |
The project to bill work to. Required when the key’s policy restricts projects. |
Your key decides which gateway you reach
There is nothing to configure. Your key carries the environment that issued it — a QA key looks like vsk_qa_… — and the CLI resolves the right console from the key itself. Present a key to the wrong deployment and it tells you which environment it belongs to, rather than reporting an invalid key.
There is also no setting that can change it. A client able to repoint the CLI could route your team’s traffic, and its keys, somewhere your administrator does not control. Self-hosted Enterprise deployments get a build with their own domain compiled in instead — talk to us if that is you.
One machine, several projects
Credentials are stored per directory, so signing in for one project does not sign you in for another. That keeps a key — and the spend it authorises — attached to the project it was issued for, even when the projects belong to different teams. opviera login and opviera logout act on the directory you are in and say which one.
Already using Claude Code, Codex or opencode?
You do not need the Opviera CLI to put those under budget. Point the tool you already use at your Opviera gateway with a single command and keep your existing workflow — same budgets, same per-project attribution, same dashboard.
Stuck on something?
Run opviera --help for the full command list, or talk to us — we would rather hear about it than have you work around it.