- Run: one workflow happened, such as
support_replyorgenerate_weekly_report. - Cost event: one provider call or tool call inside that run spent money.
Quick decision
Use this table first:| Situation | Use |
|---|---|
| You want the easiest setup for OpenAI or Anthropic | margovia.openai(client) or margovia.anthropic(client) |
| You want to patch an existing provider client | wrapOpenAI(..., { autoTrack: true }) or wrapAnthropic(..., { autoTrack: true }) |
| You want explicit helper code around one provider call | trackOpenAI(...) or trackAnthropic(...) |
| One product workflow has multiple provider/tool calls | margovia.track(...) around wrapped clients or manual cost calls |
| You use a custom provider, search API, queue, or tool | startRun(...), run.trackCost(...), run.complete(...) |
Pattern 1: tracked provider client
This is the simplest integration. Create a tracked OpenAI or Anthropic client once, then pass Margovia fields plus the real provider request each time.- Margovia starts a run named
score_tweet. - The tracked client calls Anthropic with
request. - Anthropic returns token usage.
- The SDK sends a cost event using Anthropic usage.
- The run is completed with outcome
tweet_scored.
- You call OpenAI or Anthropic directly.
- One provider call maps cleanly to one Margovia run.
- You want the clearest implementation with the least boilerplate.
Pattern 2: auto-track a patched provider client
Use this when you want to keep calling the normal provider method and pass Margovia fields through providermetadata.
- Margovia starts a run named
score_tweet. - Anthropic returns token usage.
- The SDK sends a cost event using Anthropic usage.
- The run is completed with outcome
tweet_scored.
- You call OpenAI or Anthropic directly.
- You want the smallest code change across existing call sites.
- One provider call maps cleanly to one Margovia run.
- One user workflow has several provider calls and you want them grouped under one run.
- Your customer metadata does not fit in provider
metadata. Use the tracked provider client or explicit provider helper instead.
Pattern 3: explicit provider helper
Use this when you already have your own helper function, likecreateTrackedAnthropicMessage(...), but you do not want to manually call startRun, trackCost, and complete.
- Margovia starts a run.
- Your function calls Anthropic.
- The SDK reads
response.usage. - The SDK records cost.
- The SDK completes or fails the run.
- You already have a helper function around provider calls.
- You want attribution to come from your app code instead of provider metadata.
- You are okay with the callback style.
trackOpenAI(...) or trackAnthropic(...). Do not pass an already-wrapped client into these helpers or you may double-report the same provider call.
This is the clean replacement for code like:
Pattern 4: workflow wrapper with .track(...)
margovia.track(...) creates a workflow boundary. It does not extract provider tokens by itself.
This is good:
.track(...)creates one parent run namedgenerate_weekly_report.wrapOpenAI(...)records cost events for both OpenAI calls inside the run..track(...)completes or fails the parent workflow.
- The raw Anthropic client is not wrapped.
.track(...)has no access toresponse.usage.- Margovia will see a completed run with no cost events.
.track(...) when:
- You need one Margovia run around several provider/tool calls.
- The calls inside use wrapped clients.
- Or you manually call
run.trackCost(...)somewhere inside the workflow.
.track(...) by itself for one raw provider call.
Pattern 5: manual runs
Manual runs are for integrations the SDK cannot understand automatically.- The provider is not OpenAI or Anthropic.
- You already know the cost in dollars.
- You are tracking a paid tool call, search API, vector DB operation, or custom model.
running until you call run.complete(...) or run.fail(...).
What if I do not use OpenAI or Anthropic?
You can still use Margovia. OpenAI and Anthropic have first-class helpers because their response shapes are known, but any provider can be tracked if you send either token usage or direct cost.If the provider returns token usage
Use a manual run and send the token fields from the provider response.provider and model, or when you add pricing for it later.
If the provider returns actual cost
SendcostUsd directly.
If the provider returns neither tokens nor cost
You can still track the workflow, but Margovia cannot calculate provider spend unless your app supplies a cost..track(...) around an unsupported raw provider and expect cost to appear. .track(...) only manages the run lifecycle. It does not know how to read arbitrary provider responses.
Customer attribution
Always send a stable customer key from your app. Good:Common mistakes
Mistake: using .track(...) with a raw provider client
trackAnthropic(...):
Mistake: starting a manual run and never completing it
running.
Fix:
Mistake: sending only userId
customerId for the account, workspace, tenant, organization, or billing customer. Use userId for the human or service actor inside that customer.