From the Red Hat edition of October 31, 2026
Red Hat AI Americas field build: platform-billing-operator adds token metering, prepaid wallets, budgets and GPU reservations to OpenShift AI Models-as-a-Service, with an untested setup guide
Red Hat AI Americas field organization (GitHub: redhat-ai-americas) · AI platform engineering; shared inference services and GPU capacity management · Not location-specific; applicable to US SLED shared-services and research-computing platforms
- Publisher
- GitHub (redhat-ai-americas/platform-billing-operator)
- Original publication
- Demo cluster setup guide committed Oct. 30, 2026; repository created July 30, 2026; OLM bundle v0.0.1 (alpha) listed Aug. 6, 2026
- Source retrieved
- 2026-11-01
What happened
Vendor field build: a Red Hat-copyrighted, Apache-2.0 Kubernetes operator that adds billing, metering and FinOps to OpenShift AI Models-as-a-Service. It compiles billing Plans into Kuadrant enforcement policies, meters per-request token usage, manages prepaid wallets, supports Stripe, applies budget actions (Notify, Throttle, Freeze) and offers Guaranteed or Preemptible GPU reservations through Kueue. The guide added on Oct. 30, 2026 calls itself a first draft that nobody has followed end to end on a fresh cluster, marks several OpenShift steps unverified, and lists a tested stack of Connectivity Link 1.4.2, OpenShift AI 3.4.2 (vLLM 0.13.0+rhai19) and Service Mesh 3.1.0. It warns that some OpenShift AI 3.x versions ship a conflicting Authorino version. The repository has no releases. The OperatorHub community bundle (v0.0.1, alpha) is not from a verified publisher, and Artifact Hub's Oct. 31 image scan reports 37 high, 71 medium, 19 low and 4 unknown findings (no critical).
Why it matters
State IT shared-services agencies, county consolidated IT and university research-computing centers increasingly run one GPU pool for many departments or labs. Chargeback, quotas and reserved capacity are what turn that pool into a governed service. This build shows one Red Hat-aligned way to do it on OpenShift AI. It is a prototype, and public-sector chargeback usually runs through internal journal entries rather than card payments, so the Stripe path has limited relevance.
Evidence and measured results
Read the setup guide and README in the repository, checked the GitHub repository metadata and commit history (guide added Oct. 30, 2026 15:42 UTC; zero stars; no releases), and pulled the Artifact Hub package record (version 0.0.1, alpha channel, unverified publisher, security scan summary). Also read the upstreambeat.ai Oct. 30 write-up, which agrees the project is a field reference implementation rather than a supported product. No usage, cost or accuracy results are published.
Limitations and uncertainty
Prototype with no releases; setup guide untested end to end by its own account; Artifact Hub scan findings on the alpha community bundle; no published outcomes. Committed the morning of Oct. 30, before the 10-30 run started, but not in the archive.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-01; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Shared GPU and model-serving capacity has no fair, enforceable way to allocate and charge back usage across agencies, departments or labs.
- Stakeholders
- State or county CIO shared-services lead
- Research computing director
- Finance / chargeback office
- AI platform engineering lead
- Discovery questions
- How do you allocate GPU or model-serving costs to departments today?
- Do tenants need reserved capacity or is best effort acceptable?
- What spending caps or approvals apply to AI usage?
- Can you run unsupported reference code in a lab?
- Value hypothesis
- A lab proof of concept can turn chargeback policy into testable gateway rules and clarify requirements for a supported solution (interpretation).
- Potential engagement
- Time-boxed lab evaluation (two to three weeks) of metering and plan enforcement on a non-production OpenShift AI cluster.
- Unsupported claims
- That this is a supported Red Hat product
- Any cost savings or billing accuracy figures
- Production readiness of the OpenShift install path
Pre-sales engineering
Role takeaway
- Fit
- Fits OpenShift AI 3.4-era Models-as-a-Service deployments using Connectivity Link (Kuadrant) and Gateway API.
- Architecture and integration
- WASM capture filter on the Envoy gateway feeds a PostgreSQL ledger; Plans compile to Kuadrant TokenRateLimitPolicy, RateLimitPolicy and AuthPolicy; Kueue handles GPU reservations.
- Prerequisites
- OpenShift 4.14+ with cluster-admin, 16+ vCPU, 32 GB RAM, x86_64
- Connectivity Link 1.4.2 and OpenShift AI with MaaS enabled
- Go and Rust toolchains to build components
- Constraints
- No releases; setup guide untested end to end
- Authorino version conflict on some OpenShift AI 3.x versions
- Community bundle from an unverified publisher with scan findings
- Security
- Review image scan findings, rebuild images from source, and set retention rules for the per-request usage ledger.
- Proof of value
- Confirm a tenant over budget is throttled or frozen as configured
- Reconcile ledger token counts with model-server metrics on a test workload
- Document every unverified step that fails
Delivery
Role takeaway
- Work
- Stand up the lab, run the demo scenarios, map sample plans to real departments and record gaps.
- Dependencies
- Non-production OpenShift AI cluster
- Finance input on chargeback rules
- Platform team time
- Ownership
- Central IT shared-services or research computing platform team.
- Skills and adoption
- Kubernetes gateway and policy skills are needed; pair platform engineers with finance analysts on plan design.
- Governance checkpoints
- Security review before any real tenant traffic
- Finance approval of plan and price definitions
- Decision gate on supported versus custom path
- Acceptance criteria
- Proposed: ledger and model-server token counts agree within an agreed tolerance on test traffic
- Proposed: budget Freeze blocks requests within one minute of threshold
- Proposed: written list of unverified steps with outcomes
- Risks
- Code drift with no release or support
- Image vulnerabilities
- Stakeholders mistaking a lab for a product
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Metering sits at the Gateway API data plane (a WebAssembly capture filter on Envoy) with a PostgreSQL ledger, and enforcement uses Kuadrant rate-limit and auth policies. That places billing and access control at the same gateway layer Red Hat recommends for protecting inference endpoints. Install order matters because of the Authorino conflict.
Governance
Who approves, reviews and stays accountable for outcomes?
Budget thresholds and per-tenant plans give a mechanism for enforcing departmental AI spending limits, but the policies, prices and appeal processes remain the agency's to define.
Security and privacy
What data, permissions and controls need testing?
Per-request usage capture creates a ledger of who called which model and when; agencies should decide retention and whether prompts or only token counts are recorded. The community bundle's image scan findings and unverified publisher status need review before any non-lab use.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Requires Kubernetes, Gateway API, Kuadrant, Go and Rust (for the WASM filter) skills; this is an engineering kit, not an administrator tool.
Procurement
What should contracts, pricing and exit terms secure?
Unsupported field code: buyers should not treat it as a Red Hat product commitment. It can inform requirements for a supported chargeback capability in RFPs for shared AI platforms.
Operating model
Which teams own the service once it runs?
Enables a provider-and-tenant model in which central IT runs inference as a service and departments consume against plans or reservations, similar to existing cloud chargeback.
Publication history
- 2026-10-31Red Hat · Issue 033 resources
Stable resource ID: redhat-ai-americas-platform-billing-operator-openshift-ai-maas-metering-20261030