DEV Community

littlemex
littlemex

Posted on • Originally published at zenn.dev

Stratoclave: a tenant-aware credit gateway for Amazon Bedrock — now with OpenAI codex support

If you let a team share a single AWS account for Amazon Bedrock, you quickly run into questions Bedrock alone does not answer: who called which model, under whose budget, through which identity. Stratoclave is a small OSS gateway that puts those answers in front of Bedrock without dragging in Postgres, Redis, or a SaaS control plane.

It was originally written for myself — I just wanted per-user credits in front of Bedrock for personal use of Claude Code. It grew into something that now also covers OpenAI codex / GPT-5.x via Bedrock's bedrock-mantle endpoint.

Repo: littlemex/stratoclave (Apache 2.0, alpha)

What it actually does

Stratoclave is a single FastAPI service on ECS Fargate that exposes two inference routes:

Route Wire format Backend
POST /v1/messages Anthropic Messages API bedrock:Converse in us-east-1
POST /openai/v1/responses OpenAI Responses API bedrock-mantle in us-east-2 / us-west-2

Both routes share the same DynamoDB-backed credit reservation, the same messages:send / responses:send RBAC scopes, the same audit log, and the same three identity paths (Cognito password, AWS SSO via Vouch-by-STS, long-lived sk-stratoclave-* keys).

Stratoclave architecture: clients to CloudFront to ALB to ECS Fargate, with DynamoDB, Cognito, Bedrock, bedrock-mantle (us-west-2 / us-east-2 cross-region), STS, and CloudWatch Logs.

The control plane is one AWS region (us-east-1) and one Fargate task. Bedrock for OpenAI is cross-region, but no second control-plane region is deployed.

The web console login screen redirects to the Cognito Hosted UI for password / SSO sign-in; CLI users instead run stratoclave auth login and then bring this tab into focus with stratoclave ui open.

Stratoclave web console login screen with the language switcher, a

The thing I actually wanted: per-tenant, per-user credits

The reason this exists. Every inference call atomically reserves max_tokens + input_estimate from the caller's budget with a conditional UpdateItem, invokes the upstream, then refunds the diff from the real token counts on return. UsageLogs always records the actual spend, not the reservation. Concurrent requests cannot race past the quota — the conditional write either commits or fails.

Credit reservation flow: 4 lanes (Client / Backend / DynamoDB / Bedrock or bedrock-mantle), 8 steps top-to-bottom from POST to refund + UsageLogs row.

The pipeline lives in one file (backend/mvp/_pipeline.py) and is shared between both routes — the OpenAI Responses route applies an extra reasoning-effort multiplier (1× / 2× / 4× / 8× for low / medium / high / xhigh) on the upfront reservation because reasoning traces can blow output by an order of magnitude. The minimum reservation is 8 192 tokens regardless of multiplier.

Personal usage history shows per-call token counts, model names, and credit spend drawn from the same UsageLogs table.

Stratoclave web console: personal usage statistics page listing recent inference calls with model, token counts, and credit amounts consumed.

Vouch by STS: passwordless login without holding an IdP secret

The single behaviour I am proudest of. The CLI signs an sts:GetCallerIdentity request locally with SigV4, the backend forwards the signed payload to STS verbatim, and the backend trusts only the Arn / UserId / Account STS returns. No IdP refresh token ever touches the backend.

Vouch by STS: 4 lanes (CLI / Backend / STS / DynamoDB+Cognito). CLI signs locally, backend replays to STS, STS returns canonical Arn/UserId/Account, backend resolves identity-type gates and mints an access_token.

The pattern is the same one HashiCorp Vault has used for a decade in its AWS iam auth method. Anything that populates ~/.aws/credentials works the same way: aws sso login, saml2aws, Entra ID / Okta / ADFS SAML federation, even a regular IAM user with long-lived keys (default DENY unless explicitly allowed per trusted account). EC2 instance profiles are rejected by default because they cannot be attributed to a single human.

A full backend compromise cannot pivot into the customer's IAM Identity Center or SAML IdP. The worst-case blast radius is bounded to Stratoclave's own resources — Bedrock overspend, DynamoDB tampering, impersonation within this deployment.

The trusted-accounts admin page is where AWS account IDs and allowed_role_patterns (fnmatch) are managed — this is the allowlist that gates SSO logins from outside accounts.

Stratoclave web console: admin trusted-accounts list showing AWS account IDs registered for SSO with allowed role patterns.

Three little things that turned out to matter more than expected

1. stratoclave codex -- "..." (and stratoclave claude -- "...")

A wrapper subcommand that mints a 30-minute ephemeral responses:send (or messages:send) key, hands it to the child process via env, and revokes the key on exit:

$ stratoclave codex -- "Write a hello-world Python function"
[INFO] Launching codex via Stratoclave proxy (model=openai.gpt-5.4, key=sk-stratoclave-...)
[INFO] Child process uses an ephemeral responses-only API key;
       the Cognito bearer is not exported and the user's
       ~/.codex/config.toml is untouched.
Enter fullscreen mode Exit fullscreen mode

The child gets a key scoped to exactly one route; the user's Cognito bearer never leaves the parent process. MCP servers and tool subprocesses started by codex cannot pivot back into the user's stratoclave admin endpoints because the env they inherit doesn't carry the right credentials.

The same wrapper exists for Claude Code (stratoclave claude). They share the env-scrub list and the revoke-on-exit lifecycle through one Rust struct (ChildLauncher) so a fix to one applies to both.

2. /.well-known/stratoclave-config

One unauthenticated discovery endpoint that drives the entire CLI bootstrap:

$ stratoclave setup https://<your>.cloudfront.net
$ stratoclave auth sso --profile your-aws-sso-profile     # or `auth login --email`
$ stratoclave codex -- "..."
Enter fullscreen mode Exit fullscreen mode

The endpoint returns Cognito IDs, default model names, and OpenAI base path / supported regions when CODEX_ENABLED=true. Old CLI binaries hitting a new backend deserialize cleanly because every new field is Optional.

3. The CLI is the source of truth for "what works through the proxy"

Anything that speaks Anthropic Messages or OpenAI Responses with a custom base_url works. The CLI is just a quality-of-life wrapper. If you prefer using the OpenAI SDK directly:

import openai

client = openai.OpenAI(
    base_url="https://<your>.cloudfront.net/openai/v1",
    api_key="sk-stratoclave-xxxxxxxx...",   # mint via web console or CLI
)
resp = client.responses.create(
    model="openai.gpt-5.4",
    input="Hello",
)
print(resp.output_text)
Enter fullscreen mode Exit fullscreen mode

Same for Anthropic:

from anthropic import Anthropic

client = Anthropic(
    base_url="https://<your>.cloudfront.net",
    api_key="sk-stratoclave-xxxxxxxx...",
)
print(client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
).content[0].text)
Enter fullscreen mode Exit fullscreen mode

Claude Desktop's Cowork (Gateway mode) and Cline / Continue / Aider with ANTHROPIC_BASE_URL work the same way.

The personal API-keys page is where you manage long-lived sk-stratoclave-* keys yourself — the same key-shape the wrapper subcommands mint ephemerally and revoke on exit.

Stratoclave web console: personal API key management page listing active sk-stratoclave keys with their scope, creation date, and individual revoke buttons.

Screenshots: admin walkthrough

The admin flow from dashboard to a provisioned tenant member, top to bottom.

The dashboard summarises tenants, users, recent activity, and credit consumption.

Stratoclave web console main dashboard showing summary tiles for active users, total tokens consumed, credit budgets, and recent activity.

The new-user form collects email, role (admin / team_lead / user), tenant assignment, and an initial credit budget.

Stratoclave web console admin new-user creation form with fields for email address, role selection, tenant, and initial credit limit.

The user detail view shows assigned role, tenant, remaining vs total credit, and the user's own API keys.

Stratoclave web console admin user detail page showing role / auth, tenant, credit balance, and the three admin actions: reassign tenant, override credit, delete user.

The tenant detail view lists members, their credit balances, and the tenant-wide monthly cap.

Stratoclave web console admin tenant detail page listing the tenant's members with their roles, credit usage, and the tenant-wide monthly budget ceiling.

The admin usage-logs page is the audit trail. Filter by tenant_id, user_id, and ISO-8601 since / until — backed by a PK Query when tenant_id is set, a GSI Query when user_id is set, and a Scan otherwise (truncated at 100 rows).

Stratoclave web console admin usage-logs page with filter controls for tenant_id, user_id, since, until, and an empty results table for the current filter window.

What it deliberately does not do

  • No multi-provider fan-out. It is Bedrock-shaped. If you need OpenAI direct, Vertex, Gemini, Ollama, and so on in one proxy, LiteLLM is the right tool — it speaks 100+ providers and has a much richer commercial budgeting tier.
  • No Postgres, no Redis. All state is in DynamoDB. That keeps the deployment small and the failure modes few; it also caps the budgeting feature set at what fits a key-value store.
  • No us-east-1 escape for the control plane. All Stratoclave infrastructure runs in us-east-1; only the bedrock-mantle calls for OpenAI are cross-region (us-east-2 / us-west-2).
  • No SaaS dependency. No external control plane, no telemetry, no license server. The deployment is yours.
Dimension Stratoclave LiteLLM Proxy
Providers Amazon Bedrock (Claude family + OpenAI GPT-5.x) 100+ (OpenAI, Anthropic, Bedrock, Vertex, Azure, Gemini, Ollama, …)
State DynamoDB only (serverless) Postgres required, Redis recommended
RBAC admin / team_lead / user, tenant-scoped Proxy / Internal User / Team, global / team / user / key / model budgets
API keys sk-stratoclave-*, scope narrowing, cap of 5 active, immediate revoke Virtual keys with expires / max_budget / rpm_limit / tpm_limit / models
SSO / STS Built-in (Vouch by STS, covers aws sso, saml2aws, IAM users) Enterprise tier (Okta / Entra ID / OIDC / SAML)
Deploy AWS CDK v2, Fargate from 256 CPU / 512 MiB Docker / Helm / ECS / EKS / Cloud Run
License Apache 2.0 (everything OSS) Dual license (MIT + Commercial); SSO / audit are commercial
CLI integration stratoclave claude -- / stratoclave codex -- ephemeral wrappers ANTHROPIC_BASE_URL / OPENAI_BASE_URL env override

When this is the right tool

You're an AWS-native team that already has IAM Identity Center / saml2aws, you only call Bedrock, and you do not want to run an RDBMS for a proxy. You want per-tenant credit, per-user override, an audit trail, and the option to mint short-lived keys for CI without touching Postgres.

You're not? Pick LiteLLM. Stratoclave is opinionated and small on purpose.

Quick start

# Deploy to your AWS account
git clone https://github.com/littlemex/stratoclave.git
cd stratoclave
export AWS_PROFILE=your-admin-profile
export AWS_REGION=us-east-1 CDK_DEFAULT_REGION=us-east-1
export CDK_DEFAULT_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
cd iac && npm install && ./scripts/deploy-all.sh

# Build the CLI (pre-built binaries TBD)
cd ../cli && cargo build --release
export PATH="$PWD/target/release:$PATH"

# Bootstrap and use
stratoclave setup https://<your>.cloudfront.net
stratoclave auth sso --profile <your-aws-sso-profile>
stratoclave codex -- "Hello, who are you?"
stratoclave claude -- "Summarise this repository"
Enter fullscreen mode Exit fullscreen mode

Status

Alpha. Public HTTP surfaces, DynamoDB schemas, and CDK construct props may change without notice until v0.1.0 is cut. Issues and pull requests welcome.

If you read this far and the tradeoffs match your situation, I would be very glad to hear how the deploy goes.

Top comments (0)