Coding agent skill overview

The recommended way to add TokenPolice is to let your coding agent do it. You install a small skill once, say the word, and the agent handles the rest — reading your code, wiring the SDK, and proving it works before it calls the job done.

You don't write any integration code yourself.

What the skill does

The skill is a set of instructions your coding agent (Claude Code, Cursor, Copilot, Antigravity, or Codex) follows when you ask it to add TokenPolice. Once installed, the agent:

1. Reads your repo — finds your LLM calls, your framework, and where your user_id, plan, and session values live. It never asks you something the code already answers.
2. Asks you a few questions — one short batch: your API key, the collector URL, and which fields identify your users and sessions.
3. Shows you a plan and waits — it lists every edit it wants to make and changes nothing until you say yes.
4. Wires the SDK — the smallest possible diff, in dry-run mode so nothing is blocked yet.
5. Proves it worked — you run your app once; the agent checks that TokenPolice actually received the data and reports pass or fail.

What it actually writes

The edits are small and they're all yours to read. For a Python service that calls OpenAI, the diff looks like this:

  # main.py — startup, before any LLM client is imported
+ import token_police as tp
+
+ tp.init(
+     api_key=os.environ["TOKENPOLICE_API_KEY"],
+     base_url="https://collect.tokenpolice.ai",
+     firewall="dry_run",
+ )

  from openai import OpenAI
  client = OpenAI()

  # chat.py — the function that handles one conversation turn
+ @tp.workflow(name="support_agent")
  def handle_turn(user_id: str, paid_plan: str, session_id: str, message: str):
      return client.chat.completions.create(...)

Plus token-police in your dependency manifest and TOKENPOLICE_API_KEY in .env.example. That's the whole shape of it — an init() call, a wrapper, and the identity values threaded through. A bigger app gets more of the same: step names in a multi-step loop, tool wrapping where the framework doesn't do it, a flush in a serverless handler, and a try/except where a blocked call needs to become an HTTP response.

Zero code-touch for you

Your side of the deal is small: answer a few questions, approve the plan, and run your own app once so the agent can verify it. The agent does the reading, the editing, and the proving — starting in dry-run mode, so your live traffic is never blocked while you get set up.

Next