Workerin julkinen sopimus on pieni tapahtumapari jokaista operaatiota kohti:
bus.usage.record.request -> bus.usage.record.response
bus.usage.list.request -> bus.usage.list.response
bus.usage.delete.request -> bus.usage.delete.response
Record-pyyntö sisältää tapahtumatyypin, tilin tunnisteen, tapahtuma-ajan, vapaamuotoisen JSON-datan ja valinnaisen uudelleenyritysavaimen:
{
"event_id": "evt-20260426-llm-0001",
"account_id": "00000000-0000-4000-8000-000000000001",
"event_type": "llm.usage",
"data": {
"total_tokens": 42
}
}
Onnistunut vastaus palauttaa saman korrelaation alla hyväksynnän. Jos pyyntö on virheellinen, worker julkaisee response-eventin virhekoodilla kuten bad_request. Jos usage-tallennus ei ole käytettävissä, virhe näkyy koodina usage_storage_unavailable.
{
"accepted": true,
"event_id": "evt-20260426-llm-0001"
}
Listaus ja poisto käyttävät samaa sivutettua mallia: before, page ja page_size. Sivut järjestetään tapahtuma-ajan ja tallennus-ID:n mukaan, jotta keräilijä voi käsitellä usage-erät deterministisesti. Poisto palauttaa vain poistetun rivimäärän, jolloin jatkokäsittelijä voi kirjata etenemisen ilman, että sen tarvitsee tuntea tallennustoteutuksen yksityiskohtia.
event_id ei jää vain event-payloadiin. PostgreSQL-usage-store tallentaa sen omalle sarakkeelle ja käyttää ei-tyhjille arvoille uniikkia indeksiä. Siksi sama llm.usage- tai container.run-kirjaus voi tulla uudelleen ilman, että uudelleenyritys kasvattaa laskutettavaa käyttöä kahteen kertaan.
Paikallisessa kehityksessä työntekijän saa ajettua muistitaustalla, ja julkaistussa ympäristössä se käyttää PostgreSQL-taustaa. Sama työntekijä voidaan käynnistää omana bus-integration-usage-prosessinaan tai rekisteröidä yhteiseen bus-integration-hostiin usageintegration.Registration(...)-pinnalla.
$ bus-integration-usage --self-test
bus-integration-usage self-test OK
Events-listener käyttää samaa retry-konfiguraatiota kuin muut Bus-integraatiotyöntekijät. BUS_EVENTS_LISTENER_RETRY, minimi- ja maksimiviiveen asetukset sekä BUS_EVENTS_TOKEN_REFRESH näkyvät suoraan helpissä. Käytännössä usage-worker voi käynnistyä ennen Events APIa ja muodostaa kuuntelun myöhemmin, ja streamin katkeaminen johtaa reconnect-yritykseen. Staattisen tokenin 401- tai 403-virhe pysyy nopeana virheenä, jotta väärä credential ei peity loputtomaan odotukseen.
Operaattorin kannalta tärkein ero on tunnusten rajaus: malli-, VM-, container- ja muut providerit eivät tarvitse suoraa usage-tietokantayhteyttä. Ne julkaisevat usage-pyynnön Bus Eventsiin, ja usage-työntekijä omistaa tallennuksen. Katso jatkoon bus-integration-usage-dokumentaatio, usage-providerin dokumentaatio ja bus-integration-runtime.
