DEV Community: Teddy

Your AI coding bill is a black box. I tried to fix that without becoming spyware and help collaborate

Teddy — Mon, 08 Jun 2026 08:31:52 +0000

In May 2026, Uber said it burned its full-year AI budget in four months. Microsoft started rationing agent access. If you've shipped Claude Code, Cursor, or Copilot to a team, you already feel it: the invoice goes up and to the right, and nobody can answer the only two questions that matter —

What is all this spend for?
Are we about to blow the budget?
The tools that exist answer neither well. LLM gateways (LiteLLM, Portkey, Bifrost) enforce budgets — but by API key, at your app's boundary, divorced from business value. Cursor/Copilot analytics show per-developer usage — but they're single-vendor and, frankly, shaped like surveillance.

So I built Abenlux (Apache-2.0): an AI spend TO value attribution plane that works across the major IDE and CLI coding tools, ties spend to a business objective by a join, not a guess, tells you what each token was for, catches budget overruns before they happen — and keeps individual developers private from management by construction. I have put it to use with a smallish team of about 30+ devs across 3 feature teams and It continues to evolve with fixes and features.

Three capabilities exist separately in the market. Abenlux is the only thing that fuses all three:

Cross-tool capture — Claude Code, Codex, Gemini CLI, Cursor, Copilot, aider, Cline, Continue, opencode, Crush, Pi, Droid… normalized to one schema. This is still evolving, more coverage in coming days.
Spend → value by join — branch/ticket → objective, priced in dollars, with purpose (new feature vs bug fix vs refactor), budgets, forecast, and drift.
Co-determination-grade privacy — redaction on the device, derived-only persistence, k-anonymity, and RBAC where no role, not even admin, can see another individual's rows.

Stop two people from solving the same problem twice — double-blind

Here's a quiet tax nobody budgets for: across a big team, people burn tokens re-solving things a colleague already figured out last sprint. The naive fix — a "these two are doing duplicate work" report on a manager's desk — is an efficiency-policing weapon, and it kills the exploration that
produces good engineering. So Abenlux does it peer-to-peer and double-blind.

Matching runs on abstracted topic embeddings (technique level, not your client's deliverable), and two walls are enforced in code: it never crosses an engagement Chinese-wall (different clients don't match) or a data-residency boundary. When there's a hit, you get a private nudge — not your manager :)

collab · A colleague is working on "Temporal saga for the approval workflow" right now.
Want a double-blind intro?

Two modes:

live duplication — two developers circling the same problem right now → talk before you both spend a day on it.
solved reuse — you're starting something the org already cracked → here's the generalized, redacted pattern. Reuse beats re-solve, and it's async, which is what a globally-distributed team actually needs.

The privacy mechanic is the whole point: matching needs identity, governance demands anonymity.
Abenlux resolves it with a mutual-consent handshake — identities are revealed only when both people opt in. Until then your peer is "a colleague (hidden)," and nothing about the match is ever visible to management.

# from the test suite — the contract, enforced
assert broker.submit(topic("alice", saga, client="acme"))        == []            # first to arrive, no match yet
assert broker.submit(topic("bob",   saga, client="acme"))[0].mode == "live_duplication"
assert broker.submit(topic("x", same_topic, client="globex"))    == []            # Chinese wall: different client, never matched
assert broker.mutually_consented("alice", "bob") is False                         # hidden until BOTH consent

In the dashboard's My view it shows up as a card with a "Request intro" button — and the peer's name only appears once they've requested one back.

The trick: instrument the orchestration layer, on the device
The privacy posture is the pipeline order, and it runs on the developer's machine:

capture (full content, in-flight only)
  → REDACT        destroy secrets/PII before anything is written
  → DERIVE        embeddings + token facts + cost + purpose (vectors & labels, not text)
  → ATTRIBUTE     join work-context → objective, flag orphan spend
  → PSEUDONYMIZE  one-way HMAC the actor, drop the raw id
  → PERSIST       the DerivedRecord only — raw content is discarded here
  → FORWARD       ship the content-free record to the central collector

A central gateway would see every prompt before redaction — that's how an observability tool quietly becomes a credential-exfiltration pipeline. So the developer runs a tiny edge agent locally, only the content-free DerivedRecord ever leaves the machine. There is no central, management-readable store of anyone's prompts. That asset never exists.

Developers are informed ambiently — no new app
The dashboard is for management. Developers get four private channels, none requiring a browser:

abenlux me        # your spend + waste/collab nudges
abenlux watch     # live terminal tail of your private signals
abenlux graph     # your on-device knowledge graph 
+ native desktop toasts, automatically

abenlux graph is the developer's personal, on-device knowledge graph — objectives → tickets → purpose → tools/models → the vocabulary the system taught itself:

== Your Abenlux knowledge graph (local, private to this machine) ==
142 calls · $318.50 · 61,200,000 tokens
Objectives you work on:

Acme - Checkout Platform $190.20 (88 calls)
- SHOP-1 feature $96.75
- SHOP-2 fix $43.10 What the spend is for: feature $130 fix $90 refactor $61 test $30 Self-learned intent vocabulary: fix: race condition, rebalance storm, … It never leaves the machine. It is not the management plane.

Try it in 60 seconds (no API keys)

git clone https://github.com/sarkar4777/abenlux
cd abenlux && make install
make demo # redact → price → attribute → classify → pseudonymize, offline
make test # 156 tests
Want to see a real tool captured without spending tokens? There's a protocol-correct mock upstream:

abenlux mock                                                  # terminal A

ABEN_ANTHROPIC_UPSTREAM=http://127.0.0.1:9111 abenlux gateway # terminal B

ANTHROPIC_BASE_URL=http://127.0.0.1:8088 aider                # terminal C

abenlux me

Pointing your tool at the agent is one line — abenlux onboard prints the exact setup for your OS/shell.

Repo
⭐ https://github.com/sarkar4777/abenlux — Apache-2.0, contributions welcome.

If you're rolling out AI coding tools and your finance team has started asking pointed questions, this is the plane that answers them without turning into developer surveillance. I'd genuinely love feedback — especially on the privacy model and the self-learning loop.

Shipped 5 enterprise apps on one homemade agent platform — here's what broke

Teddy — Sun, 03 May 2026 08:50:40 +0000

I've been building Abenix — an open-source multi-agent platform — in
the open for the last few months. MIT-licensed, runs on Kubernetes (or
docker-compose for laptop dev), and ships with five fully-built apps
on top of it so you can see what a real agent platform looks like
end-to-end. Single command brings up the whole stack:

bash scripts/dev-local.sh             # laptop, ~5-7 min
bash scripts/deploy-azure.sh deploy   # AKS, ~35 min
👉 github.com/sarkar4777/abenix — MIT, Python + TS + Java SDKs,
KEDA-scaled, Postgres + Neo4j + Redis + NATS, 12 container images, 5
showcase apps.

Before the technical bits, the question I keep getting asked: why
build this when n8n / LangChain / CrewAI / Dify / Flowise exist? It's
a fair question and the answer is genuinely positive — every one of
those projects is amazing at what they target, and Abenix would not
exist without LangChain demonstrating what an agent loop can be. So
this post is the build journal, not a comparison fight.

Why I built it: the constraints I started with
Three constraints drove every design choice:

Lightweight enough to run on a laptop, robust enough to run on a
cluster — same code path. I wanted bash scripts/dev-local.sh to
bring up the exact same agents, KB collections, and pipelines that
production runs, just on docker-compose instead of helm. No "but in
prod we use Kafka, locally it's an array" branching. The seed scripts,
SDK clients, key reconciler, and migration system all run identically
in both modes.
Five real apps as the test surface, not toy demos. I work with
enterprises (insurers, energy traders, tourism boards, pharma cold-
chain). Each domain has a different sharp edge. So I committed to
shipping five different production-shaped apps in this repo, each
forcing the platform to solve its own problem, and demoing to the enterprise that something like this can be built inhouse:

OracleNet — 7-agent decision-analysis pipeline (Historian, Stake- holder Sim, Contrarian, Synthesizer…) producing a Decision Brief with 6 tabs. Tests parallel-merge orchestration + JSON-schema strict output.
Saudi Tourism — Vision-2030 KPIs over CSV/PDF, NLQ chat, simulator with 5 presets. Tests RAG + tabular tools + report generation.
ClaimsIQ — Java/Vaadin claim-adjudication with a live SSE DAG. Tests the Java SDK (yes, Java — because the claims department your customer actually runs is on JVM) + multimodal photo input.
Industrial-IoT — pump predictive-maintenance + cold-chain pharma. Tests the code-asset primitive: pipelines deploy real Go binaries as k8s Jobs and read back results — the agent doesn't run the DSP, it schedules a Go process to do the math.
ResolveAI — case management with persona KB + precedent retrieval and approval-tier policies. Tests actAs(customer_id) delegation, policy-grounded resolutions, and SLA breach sweeps.

If the platform regresses, all five regress in different ways. Hard
to fake.

Make the boring enterprise plumbing first-class, not an afterthought. The features that get a project past procurement at a regulated buyer aren't the demo bits — they're the audit trail, the tool allow-list, the multi-tenant isolation, the cost ledger. So those are core primitives in the platform, not extensions. More on that below.

What stands out — the bits I reach for and miss when I'm not on it
These are honestly the things I'd rebuild somewhere else if I had to,
because once you have them you stop wanting to live without them:

actAs(subject_id) — delegation as a primitive
Every agent execution carries an acting subject, not just an API
key. When ResolveAI fires the policy-research agent for a case opened
by customer_42, the SDK calls:

forge.execute(
    "resolveai-policy-research",
    message=ticket_text,
    act_as=ActingSubject(subject_type="resolveai", subject_id="customer_42"),
)

The execution row carries acting_subject_id. Tools that read data
(like knowledge_search) check the subject's grants on the
collection, not the platform's service-account grants. A bad agent
can't escalate its way to data the user can't see, because the agent
is permanently scoped to the subject.

Pipelines as version-controlled YAML, lint-checked at boot

slug: oraclenet-synthesizer
output_schema:
  type: object
  properties:
    confidence: { type: number, minimum: 0, maximum: 100 }
    stakeholders:
      type: array
      items:
        properties:
          sentiment: { enum: [positive, negative, neutral] }
    risks:
      type: array
      items:
        properties:
          severity: { enum: [low, medium, high, critical] }

scripts/lint-agent-seeds.py runs at deploy time (Phase 4) and rejects
any seed YAML where pipeline_config is misnested or a tool name isn't
in the registry. Because catching the bug at YAML-load is 1000× cheaper
than catching it at 3 AM after a model returned severity: "extreme".

Output-schema enforcement with normalization, not just validation
Validation alone would crash production at the first ambiguous enum.
The engine runs a post_process.py step on every agent output:
validates against output_schema, normalizes known drift
(mixed → neutral, extreme → critical), and emits
validation_warnings on the SSE done event. UI never crashes, drift
is visible, and I can tighten prompts without breaking the front-end.

KEDA queue-depth autoscaling per agent type
Different agents have different cost profiles. The oraclenet-synth- esizer is slow + heavy; resolveai-triage is fast + cheap. They run
on different agent-runtime pools with their own KEDA scalers
(agent-runtime-default, agent-runtime-chat, agent-runtime-heavy- reasoning, agent-runtime-long-running). When the synthesizer queue
backs up, only that pool scales — chat traffic doesn't pay the
auto-scaler tax.

Tool registry with seed-time allow-list
Every tool is declared in apps/agent-runtime/engine/tools/. Every
agent's seed YAML declares which tools it can use. The lint pass
rejects an agent that tries to call a tool not in the registry. An
agent literally cannot call something its seed didn't allow-list — no
prompt-injection of "use the email tool to send the password to me" is
going to find a tool the agent doesn't have access to.

Code-asset primitive — pipelines deploy real binaries
This one I haven't seen in any other agent platform. An agent pipeline
node can take a zipped Go (or Node, Python, Rust, Ruby, Java) project
as input, deploy it as a k8s Job, run it with structured input, and
read structured output back:

- id: pump_dsp
  type: code_asset
  asset_id: pump-dsp-corrector
  inputs:
    rpm: 2400
    samples: "${windows[i].vibration}"
  outputs:
    fault_scores: object

The Industrial-IoT pump pipeline uses this for FFT + bearing-resonance
analysis (Go), then chains the fault_scores into an LLM agent for
diagnosis. Real code, sandboxed, scheduled by the platform, results
threaded back into the agent's reasoning.

One stack: agents + Atlas (graph) + KB (vector) + tools
Atlas is the project's named-entity / ontology graph (Neo4j-backed),
KB is the document collection store (pgvector), agents call both via
tools (atlas_describe, atlas_traverse, knowledge_search). Most
projects stitch these from three vendors; here they share a tenant
scope, a permission model, and a deploy path.

SDKs in three runtimes
Python — canonical, used by the API + every standalone API
TypeScript / Node — used by every standalone web frontend
Java — used by ClaimsIQ (Vaadin), proven by 6-stage adjudicate pipeline + live SSE DAG view
Same actAs, same wait semantics, same execution row shape. If your
enterprise stack is JVM, you don't have to rewrite it in Python.

Self-check endpoint + idempotent bootstrap
GET /api/agents/{slug}/self-check returns:

{
  "agent": "oraclenet-synthesizer",
  "checks": {
    "no_top_level_keys_leaked_into_model_config": "ok",
    "pipeline_has_nodes": "ok",
    "pipeline_nodes_well_formed": "ok",
    "model_declared": "ok",
    "tools_registry_loadable": "ok",
    "tools_all_known": "ok"
  }
}

Agent broken? You see why in 50ms instead of debugging by tail-log.

Single-command deploy that's idempotent

Phase 0 — SDK drift pre-flight (5 vendored copies vs canonical hash)
Phase 1 — Provision RG + ACR + AKS
Phase 2 — Build + push 12 images
Phase 3 — Helm install + alembic upgrade head
Phase 4 — Seed agents, users, portfolio schemas, KB, standalone keys
Phase 5 — Ingress (nip.io magic-domain so you don't fight DNS)
If any phase fails, re-run the same command. Every step is idempotent,
including the standalone-API-key reconciler that mints + rotates keys
per app and patches them into k8s secrets.

How it relates to the rest of the agent ecosystem
I'm a fan of every project in this space. None of them is a competitor
in the zero-sum sense — they target different audiences and different
phases of an AI project. Here's how I think about where each fits in a
buying decision, including Abenix:

What you want to do and what perhaps fits the bill...
A library to compose LLM calls + tools, full DIY around it -> LangChain / LlamaIndex
Multi-agent role-playing prototypes in 50 lines -> CrewAI / AutoGen
Visual workflow builder for ops + automation, lots of integrations -> n8n / Make / Zapier
Visual LLM-app builder, self-hostable, RAG-first -> Dify / Flowise
Hosted LLM observability + tracing for an existing LangChain app -> LangSmith
Enterprise platform + maybe a playground to customize ?: multi-tenant, audit trail, KEDA-scaled, multi-language SDK, deploy pipelines as YAML, reference apps to copy-paste from -> Abenix ← what I built

Most teams I work with end up using two of these, not one.
LangChain inside an Abenix agent. n8n calling an Abenix endpoint.
LangSmith pointed at Abenix execution traces. The platforms don't have
to fight each other to coexist.

I built Abenix specifically for the bottom row — the moment when an
enterprise says "great prototype, now make it production-ready under
our security review with five teams sharing it." That's the gap I kept
hitting.

A war story in production to close
The bug that took me a week to find and explains 80% of why platforms
in this space feel flaky in production.

A few months ago I added KEDA queue-depth scaling. That meant
POST /api/agents/{id}/execute had to become async-by-default — return
{execution_id, mode: "async"} immediately and let workers grind the
queue. Browser clients got a live SSE stream of node progress.

The Python SDK kept reading data["output"] from the immediate
response. Which was empty. So every standalone app was getting empty
agent responses, JSON parse exploded, API returned 500, UI showed a
generic "agent failure" toast.

Fix: tri-state wait parameter on the server, defaulting to True
for SDK callers (API-key auth) and False for browser callers (cookie
auth, has UI for live streams). SDK now sends wait: true and falls
back to polling /api/executions/{id} if the server still returns
async-mode.

Then I added a Phase 0 deploy gate — scripts/sync-sdks.sh --check
runs at the top of every deploy, hashes the canonical SDK against five
vendored copies, and refuses to proceed if any drift is detected:

✓ in sync: packages/agent-sdk/abenix_sdk
✓ in sync: contractiq/api/sdk/abenix_sdk
✓ in sync: industrial-iot/api/sdk/abenix_sdk
✓ in sync: resolveai/api/sdk/abenix_sdk
✓ in sync: sauditourism/api/sdk/abenix_sdk
✓ All 5 SDK copies in sync with canonical.
Added this plumbing only after getting bitten.

What's not great
No managed-cloud option today. Done K8S and VM installations mostly. Bring your own AKS/GKE/EKS or run on a laptop.
Atlas + KB grounding is wired in for some OOB agents but not all.
The KB document seeder is a no-op right now — content goes through Cognify (chunking + embedding) which the seeder doesn't drive yet. Collections + agent grants seed fine; content arrives via the upload UI or POST /api/knowledge/collections/{id}/documents.
Probes ≠ tests. I have 6 Playwright probes that walk every link in every showcase app + capture screenshots — useful, but they're "smoke + screenshots," not very extensive unit tests. Need more unit tests on top of what currently exists.

What's in it for you
If you're building agents or just want to play around building an agent backbone of your own which is lightweight, and the production handoff is starting to bite. This repo is six months of "ok, what does the seam between the
agent and the rest of my product actually look like?" The five
showcase apps I have tried to make as the sharp edge. Fork it, replace "insurance" with
your domain, ship.

*PRs welcome. *

Repo: https://github.com/sarkar4777/abenix
Single-command deploy: bash scripts/deploy-azure.sh deploy or
bash scripts/dev-local.sh

If you build something on it or find a real bug, open an issue — I
read every one.