Archibot has to pay API rates.

The short version is this: Archibot gives Archibus partners and customers a repeatable upgrade and performance lab, AI-assisted WebCentral expertise, and managed environments for development, testing, UAT, and support. It is useful because it sits near the real work. It costs money for the same reason.

Archibot is a repeatable upgrade and performance lab with AI-assisted WebCentral expertise attached.

A partner asked for the plain explanation recently, and the feedback was useful because it forced the wording back toward the actual job. Not "AI for facilities management." Not "ChatGPT for Archibus." The real product shape is upgrade readiness, repeatable test environments, diagnostics, performance investigation, support triage, and managed DevOps around the environments where that work happens.

That framing also exposes the economics. Archibot is not doing one cute prompt against a blank chat window. A serious support session can involve WebCentral version details, database engine and version, Tomcat/JDK/Gradle stack, integrations, customizations, representative logs, backup format, license constraints, workspace runtime, and a human who still owns the answer.

const archibotRun = {
  workspace: ["WebCentral", "SQL Server or Oracle", "Tomcat/JDK", "backup restore"],
  context: ["AXVW", "config", "metadata", "logs", "customizations", "known pain points"],
  aiLoop: ["search", "inspect", "reason", "tool calls", "triage", "human review"],
  costDrivers: ["long context", "frontier retries", "provider API rates", "environment runtime"]
};

The subsidy story matters because I do not get subsidized rates.

The developer-tool market trained people to expect frontier-model work at flat subscription prices. Some of that was real product value. Some of it was customer acquisition. The messy part is that both showed up in the same invoice. A user could pay a fixed monthly price and get far more inference than the provider would charge on the public API.

That gap is getting harder to hide. GitHub's Copilot billing change moves agentic work toward token-based AI Credits. Google's Gemini CLI update tells users who want direct quota and billing control to use their own paid API key or Vertex AI. OpenAI's Codex pricing documentation says credits are moving toward API token-based rates for the relevant plan types. The unit economics are getting closer to the surface.

That is the part I have to be clear about as an app developer. I can build a better Archibus support surface. I can route cheaper work to cheaper models. I can cache stable context. I can make workspaces repeatable so people stop rebuilding the same local environment. I cannot safely sell "unlimited expert AI" as if OpenAI, Anthropic, Google, Azure, storage, and Kubernetes all agreed to sponsor the customer.

OpenAI's public API pricing makes the point plainly enough. As of May 6, 2026, GPT-5.5 is listed at $5 per million input tokens and $30 per million output tokens, with cached input cheaper. GPT-5.4 is lower, GPT-5.4 mini is lower again, and routing matters. The exact number will move. What matters is that the number exists.

The subsidy was never the product. It was a go-to-market tactic with an invoice behind it.

Archibot's cost problem is tied to why it is useful.

Generic chat is cheap when the answer is short and the context is shallow. Archibot gets valuable when the context is not shallow. Upgrade readiness means looking at a current WebCentral version, database, app server, JDK, Tomcat, Gradle, integrations, customizations, licensing, backup and restore process, and known blockers. Performance work means slow views, reports, workflows, database sizing, indexing, query behavior, JVM configuration, cache behavior, and environment sizing.

The expensive thing is exactly the thing that makes the answer better: carrying enough context to avoid generic advice.

This is why I keep coming back to fit-checks. Short discovery is not sales theater. It is how we decide whether the work is a match, which data path is allowed, which environment shape is needed, and whether AI usage should be included, capped, metered, or moved into a dedicated/customer-controlled deployment discussion.

The answer is routing, not pretending everything is free.

The right product behavior is not to send every task to the most expensive model and hope the margin works out. The right behavior is to make the cost shape match the work. Some tasks should be static lookup. Some should use smaller models. Some should use a frontier model because the ambiguity and blast radius justify it. Some should not run in hosted Archibot at all until the data path is approved.

archibot_model_policy:
  cheap_path:
    use_for: static lookup, navigation, first-pass summaries
  mid_path:
    use_for: AXVW review, config comparison, repeatable support triage
  frontier_path:
    use_for: upgrade blockers, multi-file debugging, performance investigations
  always_show:
    - provider boundary
    - data approval path
    - included credits
    - overage behavior

This is also why WebCentral 2025.02+ has the strongest current reference support while older versions stay assessment-first. It is not a hard cutoff. It is an honesty rule. The older and more customized the environment is, the more the work shifts from repeatable support flow into discovery, migration judgment, and environment-specific risk.

Oracle is the same story. We can support Oracle-backed environments, but projects often need extra planning around licensing, backup format, storage, and runtime footprint. That is not friction for its own sake. It is how we avoid a demo that collapses when it meets the customer's real constraints.

The pitch I can stand behind.

Archibot should not be sold as unlimited AI expertise. It should be sold as a repeatable Archibus delivery and support surface where AI helps the work move faster. The customer gets upgrade assessment, test environments, support triage, and operating evidence. The price has to reflect that those things consume model calls, runtime, storage, and human judgment.

That is less flashy than pretending the token bill is someone else's problem. It is also the only version I want to defend. If partners are going to trust Archibot with upgrade, performance, UAT, or support work, they need to understand what it does, where the data goes, what is included, and what happens when the work becomes bigger than the initial scope.

The real product is not free inference. The real product is a repeatable way to do hard Archibus work without losing the context every time.