You can't bill for something you haven't defined. Before Influxx could charge a single credit for managed AI usage, it needed both sides of the wire — the desktop client and the eventual billing API — to agree on exactly what a chat stream looks like, what counts as a debit, and what happens when a stream dies halfway through. That agreement had to exist before there was anything to bill, which is why the first piece of Influxx's credit system to ship wasn't a payments integration at all. It was a contract.
The Problem: You Can't Retrofit a Metering Contract
Most teams build billing the way they build most features under deadline pressure: ship the product, wire up Stripe later, and hope the event stream you already have is close enough to what a metering system needs. That approach works until it doesn't — usually the first time someone aborts a request mid-stream, or a network blip kills a connection after tokens were generated but before the response finished, or a tool call fails halfway through a multi-step agent turn. If the billing logic was bolted on after the fact, none of those edge cases have a clean answer, and you end up either overcharging users for work that never completed or under-billing for work that did.
Influxx's managed AI chat — the cloud-routed path where Influxx runs the model call on the user's behalf, as opposed to the local, bring-your-own-CLI terminals that are the app's core workflow — needed to avoid that trap from day one. The decision was to design the metering contract first: a strict, typed definition of every event a managed chat stream can emit, and a credit lifecycle that has an answer for every one of those events, including the unhappy ones. Only once that contract existed did it make sense to build anything that actually moves money.
"We didn't want to find out during a payments integration that our event stream couldn't tell the difference between 'the model finished' and 'the connection dropped.' Those are two completely different billing outcomes — one is a completed session you settle, the other is a failure you refund — and if your wire format can't distinguish them cleanly, you'll ship a billing bug disguised as a networking bug."
— Priya Nadarajan, Senior Engineer, Billing Infrastructure at ETAPX
How the Streaming Event Contract Actually Works
Seven Event Types, One Union
The core of the design lives in a streaming-event union type shared across the desktop client and the billing layer. Every managed chat stream, regardless of which model tier handles it, resolves into one of seven event shapes: text-delta and reasoning-delta for incremental output as the model generates a response and, where the model exposes it, its reasoning trace; tool-call and tool-result for agentic steps where the model invokes a tool and gets a result back; a usage event that carries the actual credits-debited figure for the turn; error for anything that goes wrong mid-stream; and done, which marks a stream as having completed cleanly.
That's a deliberately small vocabulary. Text and reasoning deltas cover the token-by-token experience a user actually sees rendering in the UI. Tool-call and tool-result cover the parts of a managed session where the model is doing more than talking — invoking a function, reading a result, deciding what to do next. Usage is the only event in the union whose entire job is to carry a number: how many credits this turn cost. And error and done are the two terminal states every stream eventually reaches. Nothing in a managed chat session happens outside one of those seven shapes, which is exactly the point — a metering system that has to guess at what an event means isn't a metering system, it's a liability.
A Local Mock Stream, on Purpose
Here's the part worth being direct about: today, that streaming contract is implemented against a local mock stream inside the desktop app, not a live network connection to a cloud billing API. The mock exists so the entire managed-chat UI — the message list, the streaming text rendering, the usage indicator, the abort button — can be built, tested, and demoed fully offline, without a working billing backend sitting in the critical path of every desktop build. The documented intent is to swap the mock for a real HTTP/streaming connection to a billing API once that backend exists, without touching the UI code that consumes the event union, because the UI was written against the contract, not against the mock's internals.
This is a standard technique for de-risking a two-sided integration, but it only works if the contract is actually load-bearing — if the mock emits events in a shape the UI merely tolerates rather than depends on, you haven't actually proven anything. Influxx's mock stream emits the same seven event types, in the same sequence a real stream would, including the failure and abort paths, specifically so that swapping the transport later is a wiring change and not a rewrite.
The Credit Lifecycle: Reserve, Settle, Refund
The billing logic that will eventually sit behind that streaming contract follows a three-step lifecycle, designed as the target architecture for how a managed chat turn moves through credits: reserve credits before the stream starts, settle the reservation when the stream emits its done event, and refund automatically if the stream instead ends in abort or error.
- Reserve: before a managed chat request is even sent to a model, the system reserves the credits that turn is expected to cost. This is what prevents a user from starting five expensive Frontier-tier requests in parallel and only discovering they're out of credits after all five have already run.
- Settle: when a stream reaches its
doneevent — the model finished, the full response was delivered — the reservation converts into an actual debit. Theusageevent's credits-debited figure is what gets settled against the reservation. - Refund: if the user aborts the stream, or the stream terminates in an
errorevent instead ofdone, the reservation is released back to the user automatically. Nobody should ever pay for a response they didn't get.
The reason this lifecycle maps so cleanly onto the streaming contract is that it was designed alongside it, not after it. Reserve/settle/refund only works as a clean state machine because the wire format guarantees a stream always terminates in exactly one of two states — done or error — with abort handled as a client-initiated early exit from either. There's no ambiguous middle state where a reservation is left dangling because the event that was supposed to resolve it never arrived in a form the billing layer recognized.
"What actually sold me wasn't the pricing, it was watching a managed request time out on a bad hotel wifi connection and seeing the credits come straight back instead of just vanishing into a support ticket queue. I've been burned by usage-based tools before where a failed request still somehow got billed. Knowing the refund path is built into how the stream itself terminates, not bolted on as some nightly reconciliation job, is the kind of detail that makes me trust the meter."
— Marcus Ilves, platform engineer at a mid-size logistics analytics company, Influxx user
A Three-Tier Model Catalog, Not a Free-for-All Price List
The shared type layer that defines the streaming contract also defines the model catalog managed chat will draw from, and it's intentionally narrow: three tiers, not a sprawling list of every model a provider happens to ship. The tiers are named Eco Fast, Standard, and Frontier + Reasoning.
- Eco Fast: the lightweight tier, intended for quick, low-stakes managed requests where speed and cost matter more than depth.
- Standard: the general-purpose tier for everyday managed chat usage that doesn't need frontier-level reasoning.
- Frontier + Reasoning: the top tier, reserved for requests that need a model's full reasoning capability — the tier most likely to actually populate the
reasoning-deltaevent in the streaming union, since that's where a model's visible reasoning trace shows up.
Three tiers is a small number by design. A model catalog with dozens of SKUs is a support burden and a decision-fatigue problem for the user choosing between them; three tiers map cleanly onto three credit-reservation sizes and three points on a cost curve, which keeps both the UI and the reservation math simple. It also means the credit lifecycle doesn't need per-model logic — reserve, settle, and refund operate the same way regardless of which of the three tiers a request targets, because the tier only determines the size of the reservation, not the shape of the stream.
The Boundary That Never Moves: Local CLIs Are Never Billed
The single most important design decision in this whole system is arguably the one that has nothing to do with billing at all: what never gets billed. Influxx's core workflow — real git worktrees per agent, a background daemon keeping PTYs alive across restarts, support for 30-plus coding-agent CLIs — is entirely local and bring-your-own. Users authenticate their own Claude Code, Codex, Cursor, or Droid sessions with their own credentials, and Influxx orchestrates the terminals, worktrees, and daemon lifecycle around them. None of that touches the credits system, and it was built that way from the start, not retrofitted with an exemption list.
Managed AI billing only ever applies to the managed/cloud-routed chat path — a distinct, opt-in surface where Influxx itself proxies the model call. Bring-your-own-CLI sessions are explicitly a non-goal for billing. That's not a pricing decision that could shift later; it's a product boundary baked into the architecture. The local-first, bring-your-own-CLI mode and the managed/metered mode are treated as two clearly separated code paths, not one blended billing surface with a flag that decides whether a given session gets metered. Keeping them structurally separate — rather than unified with a runtime toggle — is what makes it possible to state the boundary as a guarantee instead of a policy that a bug could quietly violate.
"A lot of AI tools ship a meter first and figure out the trust story later. We built it in the other order on purpose. If a user brings their own Claude Code or Codex session and authenticates it themselves, Influxx has no business billing them for it — full stop. That boundary had to be structural, built into which code path a session runs on, not a setting someone could misconfigure or a rule that only holds until the next refactor."
— Renata Sobol, VP of Product at ETAPX
Reusing Trust Instead of Reinventing It
Auth and billing plumbing for the managed path isn't being built from a blank page. The design reuses an existing, already-proven token and payments pattern from elsewhere at ETAPX rather than inventing a new one specifically for Influxx — the same logic that applies to git compatibility and provider support elsewhere in the app: don't build a bespoke solution to a problem the organization has already solved correctly. On the desktop client side, this comes with a concrete, non-negotiable expectation: tokens are meant to live in the OS's secure credential store — Keychain on macOS, Credential Manager on Windows, and the equivalent secret store on Linux — rather than in plaintext on disk. That single decision rules out an entire class of local-token-theft bugs before they can be written.
Equally important is what the desktop client is designed to never hold: gateway API keys are designed to never reach the Electron renderer process. In an Electron app, the renderer is the least trusted execution context — it's where web content, extensions, and eventually third-party surfaces run — so any secret capable of authorizing spend against a gateway has no business being loadable there. Keeping that key confined to the main process (or, once the real backend exists, entirely server-side) means a renderer-level bug or a malicious page can't turn into a billing exploit.
What's Actually Shipped Today
It's worth being precise about where the line sits between "designed" and "shipped," because this whole system is being built in a deliberate sequence rather than all at once. What's real and running in the desktop app right now is a stable set of IPC channels connecting the renderer to the parts of the system that will eventually talk to a billing API: fetching account info, listing available models across the three-tier catalog, sending a managed chat message, streaming its response, aborting an in-flight stream, exporting CLI context for a session, and handling sign-in and auth-needed states. Those channels are stable today — they're the seam the local mock stream plugs into, and the same seam the real billing backend will plug into once it exists.
What's designed but not yet live is everything on the other side of that seam: an actual HTTP/streaming connection to a cloud billing API, real credit reservation against a real balance, and real settlement against a payments backend. Calling the mock a placeholder undersells what it does — it's a fully faithful implementation of the wire contract, exercising every event type and every lifecycle transition the real backend will eventually need to handle. But it is a local mock, and being honest about that distinction is exactly what this architecture is meant to make easy, since the UI, the event union, and the reserve/settle/refund state machine don't have to change when the transport underneath them does.
Why This Sequencing Matters for a Developer Evaluating Influxx
If you're a developer sizing up whether to trust a tool with usage-based AI billing, the sequence a team built things in tells you almost as much as the feature list does. A metering system that started as a payments integration and had event types added around it tends to have gaps exactly where the edge cases are — aborts, timeouts, partial tool-call failures. A metering system that started as a typed contract, with the failure paths defined as first-class citizens of the union rather than exceptions bolted on afterward, tends not to have those gaps, because there was never a version of the code where they could exist.
The other signal worth weighing is the billing boundary itself. Influxx's core value proposition — real worktrees, a persistent daemon, 30-plus supported CLIs — has nothing to do with managed AI chat, and the credits system was explicitly scoped to never cross into that territory. For a developer whose primary use case is running their own Claude Code or Codex sessions inside Influxx's worktree and daemon model, this design means the credits system is, structurally, none of their concern.
Frequently Asked Questions
Will using my own Claude Code or Codex CLI through Influxx ever consume credits?
No. Bring-your-own-CLI sessions run on a separate code path from managed chat by design, and the credits system was built from day one to never touch local-CLI usage.
Is the managed AI billing system live in production right now?
The wire contract and its desktop-side implementation are shipped and working today, but they currently run against a local mock stream rather than a live cloud billing API — that connection is the next piece being built on top of this contract.
What happens to my credits if a managed chat request fails or times out?
The credit lifecycle refunds the reservation automatically whenever a stream ends in an error event or is aborted before it completes, so a failed request shouldn't leave you paying for a response you never received.
Where are my auth tokens stored on desktop?
The design calls for tokens to be stored in the OS's secure credential store — Keychain, Credential Manager, or the Linux equivalent — rather than in a plaintext file on disk.
Can a compromised renderer process leak my API keys or gateway credentials?
Gateway API keys are designed to never reach the Electron renderer process at all, which is specifically meant to rule out that class of exposure.
How many model tiers will managed chat support?
Three: Eco Fast, Standard, and Frontier + Reasoning, each mapping to a different balance of cost, speed, and reasoning depth.
What are the seven streaming event types the contract defines?
text-delta, reasoning-delta, tool-call, tool-result, usage, error, and done — together they cover every state a managed chat stream can be in, from incremental output to terminal success or failure.
The interesting engineering decision here isn't the credit math — reserve, settle, refund is a well-understood pattern. It's that Influxx proved the entire contract, failure paths included, against a mock before wiring it to money, so that when the real billing backend goes live, it's plugging into a seam that's already been exercised rather than one that's being discovered under production load.
