Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to walkthrough replaces developer-held provider keys with a gateway that tags every call with org, team and user. The tagging is server-side, which is the right call, and the dashboards behind it refresh every 15 minutes.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A call under this design leaves the laptop with a team-scoped key aimed at `https://gateway.reclaimllm.com/v1/{org_slug}` [12]. The gateway resolves the org, substitutes a master provider credential held in its vault [4], checks the requested model against policy [10], stamps the record with org, team and user identity server-side [6], and forwards the request to Anthropic, OpenAI or Google [11]. Attribution is therefore a property of the credential, not of the person typing. The cost report has exactly the resolution of the key issuance policy. One key per team gets team lines where there were none [1]. One key for all of engineering moves the same blindness one hop closer to the code.
Two of the post's statements need a bridge it does not supply. Tagging is described as durable and includes user identity [6], while the keys themselves are scoped to teams such as `frontend-team` and `data-platform` [5]. Either keys are minted per developer in practice, or the client passes a user field with the request. If it is the second, the best property of the design goes soft: a server-side tag cannot be forged by a developer's machine, a client-supplied one can. That distinction is the reason to collect the record at all for a SOC 2 reviewer [3].
The post's own title promises real-time auditing. The number underneath it is a set of PostgreSQL materialized views refreshed every 15 minutes [7], which works out to 96 refreshes a day [13]. For monthly chargeback that is generous. For an agent stuck retrying a frontier model, it is up to a quarter hour of billable surprise before any aggregate tab shows it. The Sessions tab is described as a filterable raw session list for drilling behind a metric spike [8]; whether it reads base tables or the same 15-minute views is not stated, and that is the detail that decides if it is usable mid-incident.
Adoption cost sits in the clients, not the gateway. Each surface from Part 1 (Gemini CLI, Antigravity, Claude Code, Cursor, Codex, API proxies) has to accept a base URL you control and a key you mint [9]. That is six separate configuration questions, and the post enumerates the tools without enumerating their base-URL support.
Credit where it is due: running DLP before execution rather than after [9], and tagging server-side rather than trusting the caller [6], are both the harder and the correct side of the choice. The vault is an honest trade rather than a free win. Many laptops each holding a master key [2] becomes one store holding master credentials for OpenAI, Anthropic, Gemini and Azure at once [4]. Smaller attack surface, larger blast radius, and worth it provided the vault has a better on-call rotation than the laptops do. In my context I would still route everything through the gateway, and I would mint keys at the granularity I intend to bill at, because that granularity is the only thing the dashboard can ever report.
Ranked by verification strength, evidence, and original report placement.
The described gateway holds a central provider vault in which enterprise admins store master OpenAI, Anthropic, Gemini and Azure credentials once, so master secrets never touch developer laptops.
Team-scoped gateway keys are issued to specific teams, for example frontend-team and data-platform, with strict rate limits and model restrictions.
Every gateway call is tagged server-side with durable org, team and user identity, feeding directly into the observability dashboard.
The ReclaimLLM enterprise portal's observability is backed by PostgreSQL materialized views refreshed automatically every 15 minutes.
The dashboard has five tabs: Overview, Usage, Tokens, Stats and Sessions, the last a filterable raw session list for drill-down behind every metric spike.
Model policy enforcement at the gateway whitelists or blacklists approved models, with the stated aim of stopping teams calling high-cost frontier models for basic classification or linting tasks.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Superpowers makes spec-driven work a precondition, then ships it to twelve harnesses1 distinct publisher
build
Twenty-three security checks, zero coverage: AI coding agents as build-pipeline attack surface1 distinct publisher
product
Claude's memory now writes while you talk, and it crosses products by default4 distinct publishers
product
Four leaderboards, four denominators: what you buy when you standardize on a coding agent1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One post, written by the builder
Everything rests on a single dev.to instalment by the person who makes the product: ASCII diagrams, feature bullets, no configuration, no logs, no measurements, no outside review. The one internally checkable detail — Postgres materialized views refreshed on a quarter-hour cadence — is plausible engineering rather than demonstrated engineering, and the enterprise pain the piece opens with arrives without a single number attached. Even the prior instalment that supposedly established the capture layer is asserted rather than available here.
No deployment on the record
Not one organisation, seat count, request volume or trial figure appears anywhere in this reporting. A branded hostname in a diagram tells us a URL has been chosen, not that traffic flows through it, and the dashboard tour is a tour of a product rather than of anyone's data.
"Real-time auditing" on a quarter-hour clock
The promise in the headline is real-time auditing; the machinery underneath is a set of materialized views recomputed four times an hour. For spend attribution that lag is harmless — you are comparing weekly team totals. For the credential misuse or exfiltration case the same page is sold against, fifteen minutes is a long time to be looking at yesterday's numbers. The architecture claims themselves are sober and modest, which is precisely why the vocabulary sticks out.
The problem and the cure share an author
This is Part 2 of a series by the person selling the portal it documents, and the construction shows it: three enterprise blindspots stated up front, each answered by a named feature further down, with the product's own hostname in the request path. None of it is concealed — the branding is right there in the endpoint — but the piece is a product tour wearing an architecture post's clothes, and the framing of the pain is doing sales work.
Sure what is claimed, blind to whether it holds
We can state precisely what is being asserted, because the post is unusually explicit about its own internals — key custody, tagging point, storage layer, refresh interval. What we cannot say is whether any of it survives a hundred developers, a provider outage or an auditor, because one self-published account is the entire record. High confidence in the description, low confidence in the outcome.