AutiTech.
← Selected work

DEVELOPER TOOLS / COST & USAGE

API token accounting

Matching TypeScript and Python libraries that separate preflight counts, offline estimates, and actual usage so AI applications can make better budget decisions.

MY ROLE

Product specification, accuracy requirements, policy design, and cross-language validation direction.

PROJECT MILESTONE

SDK release candidate

API TOKEN ACCOUNTING01
Exact.
Estimated.
Understood.
AIARCHITECTURE STUDY
01 / THE CHALLENGE

Know what the estimate means.

A single token number can conceal very different levels of certainty. Multimodal payloads, endpoint behavior, usage reports, and model settings need a vocabulary that tells a developer what is known.

02 / HOW I DID THE WORK

From the idea
to the implementation.

  1. 01

    Specify what each number means

    I required separate contracts for exact API counts, reported usage, and offline estimates. Unsupported components remain unknown rather than becoming silently precise numbers.

  2. 02

    Align two developer interfaces

    The TypeScript and Python implementations share schemas, fixtures, and model-catalog metadata. This gives applications a consistent vocabulary for counting, cost estimates, budget checks, and usage normalization.

  3. 03

    Integrate the accounting into a product

    Echo uses the SDK locally, turning the accounting rules into part of an application workflow. Production credential-pool operation and public package release have their own readiness criteria.

03 / THE THINKING

Decisions that
shape the system.

01

Name the evidence level

Expose exact_api, actual_usage, and offline_estimate instead of silently presenting an estimate as an exact count.

02

Match behavior across languages

Use shared schemas, fixtures, and catalog-generated metadata for TypeScript and Python APIs.

03

Connect counting to decisions

Provide usage normalization, cost estimation, budget validation, and model-policy checks rather than an isolated text counter.

04

Keep credentials on the server

Treat the separate key-pool prototype as infrastructure with its own access, tenancy, accounting, and production-readiness requirements.

HOW THE PIECES CONNECT Conceptual architecture
  1. Request profile
  2. Count or estimate
  3. Budget check
  4. Actual usage
  5. Reconcile

Inside the implementation

The key design choice is explicit uncertainty. An offline estimate remains labeled as such, and an unsupported component remains unknown. Model settings and dated catalogs inform policy; they do not magically change the certainty of an input-token estimate.

04 / THE RESULT

What the work
demonstrates.

The repository contains a dual-language SDK release candidate with common contracts and documented accuracy tiers. Echo uses the SDK locally for its accounting integration.

Why it matters to a client

Useful for teams integrating AI into products that need explainable costs, shared budgets, and predictable interfaces.

TypeScriptPythonJSON SchemaShared fixturesModel catalogs
KEEP EXPLORINGCams and more ↗
HAVE A PROBLEM WORTH SOLVING?

Let’s make
something work.

Tell me what you’re building, what’s getting in the way,
and what a useful result would look like.

↗