See your AI spend, your AI activity, and the tools nobody approved. Govern access to all of it, behind your own firewall.

Token Observe is a customer-hosted platform for SMBs and mid-market businesses that answers four questions about the AI your organisation uses: what it costs, what it is being asked to do, which tools nobody approved, and who may use any of it. It keeps a register of your AI services and subscriptions, each with a named owner. It imports invoices as JSON or CSV to record what was actually billed in each currency, and records metered token estimates separately — a charge and an estimate are different measurements, and adding them together produces a total that is true of nothing. It classifies what it observes as approved, prohibited, unknown or unobserved, so an approved paid subscription is never reported as unauthorised use and a source nobody has connected is reported as unknown rather than as zero usage. Where a configured integration exposes the content, it records bounded, redacted prompts, replies and tool activity with truncation and source provenance kept beside them; hidden chain of thought is not readable from any provider and is not claimed. Operators reach all of it through one dashboard, REST API and MCP interface under team scoping. It runs on your own infrastructure behind your own firewall, model requests go to your own provider accounts on your own keys, and the vendor receives no prompts, keys, telemetry or trace data. The inline governance capabilities — permissions, budgets, redaction, approvals and a hash-chained audit log — still ship and are described across the platform pages; since the product direction was updated on 6 September 2026 they are retained capabilities rather than the headline.

Token Observe is not a FinOps suite for your whole cloud bill: it covers AI services, subscriptions and model traffic, and nothing else. It does not discover every subscription by itself — an invoice import finds what the invoice lists — and it does not read hidden chain of thought, because no provider exposes it. It is not an LLM evaluation platform, not an identity provider, not a sandbox or durable agent runtime, not a CMDB-style AI inventory, not a general AI firewall or prompt scanner, not a static agent-BOM scanner, and not an agent marketplace. Those are named strategic non-goals in Token Observe’s own roadmap, and the instruction that follows them is to build adapters and evidence exchange for those layers instead — so the recorded strategy is to federate your identity system, consume your security platform’s verdicts, and run above or beside your existing gateway rather than ask you to remove any of them. It does ship a registry, provider routing, quotas, cost dashboards, prompt and response redaction, trace trees and MCP tool ACLs. Every one of those is treated as table stakes rather than as a reason to buy, because most of the market now ships them too.

Two separate measurements, kept separate on purpose. The first is what you were actually billed: you register each AI service and subscription with a named owner, then import the invoices as JSON or CSV. Charges are recorded per currency and carry their source and the period they cover, and repeated imports are replay-protected so loading the same invoice twice does not double the total. The second is metered usage through the gateway, priced as a token-cost estimate. Those two numbers are never added together, because an invoice and an estimate measure different things and a combined figure would be true of nothing — a subscription you are billed for monthly and the API traffic beside it are not the same money, and presenting them as one number is the fastest way to produce a total nobody can reconcile against a real vendor record. Two limits matter before you plan around it. An import finds what the invoice lists, so it does not by itself discover a subscription nobody has told you about or expensed elsewhere. And live billing adapters that reconcile continuously against real vendor records are not built yet — what ships today is the register, the import path and the provenance on both sides of it.

Yes. AgentControl Plane is the engineering name Token Observe is developed under: it is the name on the repository, the licence, the architecture decision records and the threat model, so anyone who has read the source will search for it. Token Observe is the product name and is the only name used everywhere else, because two names in the copy split one entity into two half-described ones. Nothing else differs — same code, same source-available licence, same self-hosted deployment, same published defect list. If you arrived from the repository, the documents you have already read remain the authority: the data-flow document, the threat model, the compliance mappings and the known-issues list are what a security review should actually run on, and this site paraphrases them rather than replacing them. Where the two disagree, the repository is right and the site is a defect.

An agent normally starts routing through Token Observe by changing one environment variable. For the supported OpenAI-compatible, Anthropic and Gemini ingress, pointing OPENAI_BASE_URL or ANTHROPIC_BASE_URL at your Token Observe host is a base-URL change rather than an application refactor, and from that moment the agent has an identity, a permission set, a budget and a searchable record of each governed request. The ingress surface is explicit rather than implied: /v1/chat/completions, /v1/responses, /v1/messages, /v1/embeddings, the native Gemini generateContent and streamGenerateContent paths, /v1/models filtered to what that agent may reach, and /mcp over Streamable HTTP. Whether your own SDK and version behave that way is the first thing a proof of concept settles, and it is the honest limit on the claim. The offline path needs no provider key at all, because a built-in mock provider answers — but it fabricates text, so it proves the plumbing and nothing else.

If Token Observe is unavailable, the agents it governs stop calling models, and that is the design rather than a defect. Governance is inline and fails closed: the evaluator returns allow only when every gate passes, and missing, unresolvable or erroring state denies the request. A control you can bypass by turning it off is not a control — which makes Token Observe’s own availability a governance property of your environment rather than somebody else’s problem. Plan for it explicitly: run it close to the agents, watch /readyz, and decide in advance what you do if it stops, because the design-partner gate requires that emergency decision to be named and owned before traffic arrives. Two related behaviours: process admission is global and applied before the body is read, returning 503 ACP_OVERLOADED with a Retry-After when the ceiling is reached, while health, readiness and metrics probes stay reachable.

No. Token Observe is self-hosted and bring-your-own-key: there is no telemetry, no phone-home, no licence callback and no vendor-operated component in the path, and the licence carries that as a contractual undertaking rather than only a claim. Governed payloads leave your network only for the model and tool providers you configure, after policy and redaction. You do not have to take it on trust, and the check takes about five minutes: list every outbound call site and every hard-coded URL in the server and core packages, confirm each destination comes from operator-supplied configuration bar the admin-invoked price catalogue, check the dependency list, then run the process with egress allowed only to your providers and watch nothing break. Two qualifications belong beside that. Anything you voluntarily send in a support ticket is governed by your support agreement, not by the architecture. And whether the vendor is legally never a processor is counsel’s analysis, not an engineering fact.