Skip to content

devlog/token-math/separate-fluxo-keys-for-two-terminal-projects-72.md

Separate Fluxo Keys for Two Terminal Projects

Two repositories, two keys, one billing boundary

When two projects share an API key, their token spend becomes one mixed number. Your interactive coding session, background worker, and experimental script all look like the same caller. Giving each project a separate key creates a useful attribution boundary without changing providers or rebuilding your application.

Fluxo provides one base URL, https://api.fluxorelay.com, and a key that can access Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. Here, we deliberately use two keys: one for each repository. The model can change while the project identity stays attached to its credential.

If you want to follow along, create a Fluxo account and use two small projects you already run locally.

Create keys named after your repositories

Create two separate API keys in Fluxo, naming them project-api-local and project-worker-local. Copy each secret when it is issued. These names describe ownership and environment; a label like test-key will be much less useful next month.

Keep production separate later with another credential, such as project-api-production. A project key should belong to one billing boundary, even when several scripts inside that project use it.

Save each key inside its own project directory

The following commands use Bash. Start a Bash session so the hidden-input prompt and shell escaping behave consistently: — bash

Create two working directories and initialize Git repositories: — mkdir -p ~/fluxo-demo/project-api ~/fluxo-demo/project-worker

git -C ~/fluxo-demo/project-api init — git -C ~/fluxo-demo/project-worker init

Configure the first project. Paste its key at the hidden prompt, then press Enter:

cd ~/fluxo-demo/project-api — printf '\n.fluxo.env\n.venv/\n' >> .gitignore — read -r -s -p 'Paste project-api-local key: ' PROJECT_KEY; printf '\n'

(umask 077; printf 'export OPENAI_API_KEY=%q\n' "$PROJECT_KEY" > .fluxo.env)

unset PROJECT_KEY

Repeat with the second project's credential: — cd ~/fluxo-demo/project-worker

printf '\n.fluxo.env\n.venv/\n' >> .gitignore — read -r -s -p 'Paste project-worker-local key: ' PROJECT_KEY; printf '\n'

(umask 077; printf 'export OPENAI_API_KEY=%q\n' "$PROJECT_KEY" > .fluxo.env)

unset PROJECT_KEY

The files contain secrets, so keep them local. The restrictive creation permissions and Git ignore rule handle the basic repository hygiene. For existing repositories, also check that a credential file has never already been tracked.

Send an isolated request through the OpenAI SDK

Run this setup in each directory: — python3 -m venv .venv

.venv/bin/python -m pip install openai — Choose Claude Sonnet 5.5 or DeepSeek V4 Flash, then copy its exact API model identifier from Fluxo. Display names and API identifiers can differ; use the supplied identifier rather than guessing one from the name.

Run this request from the project you want to charge. The parentheses keep its credentials inside a temporary subshell:

( source ./.fluxo.env; read -r -p 'Fluxo API model identifier: ' FLUXO_MODEL; export FLUXO_MODEL; .venv/bin/python -c 'import os; from openai import OpenAI; client = OpenAI(api_key=os.environ["OPENAI_API_KEY"], base_url="https://api.fluxorelay.com/v1"); response = client.chat.completions.create(model=os.environ["FLUXO_MODEL"], messages=[{"role":"user","content":"Reply with one short greeting."}], max_tokens=32); print(response.choices[0].message.content); print(response.usage)' )

The /v1 suffix selects the OpenAI-compatible API path. Repeat from the other directory with its own environment file. Changing directories alone never changes an exported credential; explicitly loading the file is the important step.

Reconcile project spend against actual billing

Treat the printed usage as a request sanity check. For money, use Fluxo's billing records and the available key-level attribution. Confirm that you can distinguish both keys before routing substantial traffic; local credential separation alone does not produce a spending report.

  • Record each key's project, environment, owner, and creation date.
  • Compare matching billing periods when reviewing the two projects' spending.
  • Include cache reads and writes when reconciling billed usage totals.
  • Rotate exposed credentials and preserve their historical project ownership records.

Fluxo bills real token usage, including cache reads and writes, with no monthly fee. That makes request count alone a poor spending estimate. The same credential discipline applies when configuring Claude Code, Codex, or Gemini CLI, which Fluxo also supports; each tool needs its own provider settings.

Keep referral earnings separate from project consumption when reviewing account totals. Fluxo gives users a referral share when people they invite pay. If key attribution needs clarification, leave a note on the contact page after signing in.

Next in the buffer

Sign up in a minute and get credit to try every model mentioned here. Sign up →