Three data points. That is the entire evidentiary base. A launch date. An input price of $0.10 per million tokens. A cached-input price of $0.01 per million tokens.
No architecture document. No model card. No parameter count. No latency figure. No throughput number. No accuracy benchmark. No team roster. No funding round. No on-chain data, because there is no chain.
The fourth data point is the one that would matter most, and it is absent: the output price.
I have spent enough of my career reading documents like this to know that an announcement presenting as disclosure can function as redaction. In 2017 I spent sixty hours inside the unverified source of a fork calling itself Ethereum Gold, hunting the minting function, and found an integer overflow that let any caller generate supply without limit under a specific block-height condition. I wrote the patch. I filed it. My team shipped the marketing anyway, because the marketing had a narrative and the patch had a diff. Two weeks later the project collapsed and took two million dollars of other people's money with it.
The lesson was not 'audit more.' It was narrower and more useful: the absence of a field is itself a field, and you read it exactly the way you read the ones that are filled in.
So let's read the empty space. Logic prevails where hype fails to compute.
Context: What a Pricing Announcement Actually Encodes
The first thing to establish is what this document is not.
It is not a protocol launch. It contains zero crypto-native vocabulary. No chain. No wallet. No contract. No staking. No governance. No TVL. No validator set. No bridge. No sequencer. The billing unit is per-million-tokens, which is the standard metering convention for large language model inference APIs and has no relationship to a transferable asset. The product name is AI-service naming, not protocol naming.
That matters because this announcement was routed into Web3 feeds and classified as a Web3 item. The classification is almost certainly wrong, and the mechanism of the error is worth naming: the word token carries two unrelated meanings, and a pipeline that matches on strings rather than semantics will collapse them. One meaning is a unit of text segmentation used for billing. The other is a transferable digital asset with supply, custody, and market structure. A document about the first, ingested by a system indexing the second, produces a category error that then propagates into every downstream analysis built on top of it.
I have watched this failure mode before, in a different costume. During the DeFi Summer of 2020 I built a Python harness that pushed five thousand mock transactions through Aave v1 and Compound to map flash-loan arbitrage paths between Uniswap and Sushiswap. The thing that nearly broke the model was not the math. It was that two protocols used the same symbol for two different things. Price feeds looked comparable and were not. Four seconds of oracle latency during high volatility opened a window wide enough to push an account into insolvency, and that window was completely invisible in any dashboard that had normalized on the symbol rather than the underlying quantity.
Same structural problem here. Same fix: go down to the semantics, not the label.
Once you reclassify this correctly as an inference-service pricing announcement, three things become analyzable that were previously noise.
First, the maturity signal. The phrase about a full launch is the only technical milestone in the document, and it is a real one. It means the service has cleared a beta or limited-access phase and is now generally available. In a market where a large fraction of announced AI products live permanently behind a waitlist, that is a genuine data point about delivery capability. It is weak evidence, but it is evidence, and weak evidence properly weighted beats strong narrative improperly weighted every time.
Second, the price band. $0.10 per million input tokens is not a disruptive number. It is the median of the mainstream lightweight tier. The genuinely aggressive number is the cached price at $0.01, which sits near the floor of anything publicly listed. The spread between the two, a ten-to-one ratio, is the most information-dense fact in the entire document, and I will come back to why in detail.
Third, the omission. Output pricing is absent. In API pricing announcements, output pricing is not optional garnish. It is the line that determines actual customer cost, because output tokens are almost always billed at a multiple of input tokens, commonly three to five times, because decode is memory-bandwidth bound and generates one token at a time per sequence. A pricing page without an output line is either truncated, or deliberately anchored, or describing a product whose output is so small that it barely bills. All three possibilities are informative. None of them are the story the announcement wants you to read.
There is a discipline to this kind of reading that I want to state plainly, because it is the difference between analysis and speculation. When the evidentiary base is three fields, you do not fill the remaining thirty with plausible-sounding invention. You build a gap map. You name every field a competent due diligence would require, you mark each one as present, absent, or unverifiable, and then you reason only across the fields that exist. What you get is not a verdict. It is a set of constraints. Constraints are more useful than verdicts, because constraints survive contact with new information and verdicts do not.
Core: Pushing Three Numbers Through a Cost Model
Here is where the actual work happens. The pricing structure is the only high-density data in the document, and it supports three reverse inferences. I will take each one and show the arithmetic rather than assert the conclusion, because a number you can re-derive is worth ten numbers you have to trust.
Inference A: The Model Is Small, Distilled, or Running on Owned Capacity
Start with the marginal cost of prefill.
Take an H100 at roughly two dollars per hour on the current spot and reserved market. That is $0.000556 per second, or two dollars per 3,600 seconds of wall clock.
An eight-billion-parameter model doing prefill at a realistic thirty to sixty thousand tokens per second processes between 108 million and 216 million tokens per hour. Divide the hourly cost into that throughput and you land between $0.0093 and $0.0185 per million input tokens. Call it one to two cents.
At a ten-cent sticker, that is a gross margin somewhere between eighty-one and ninety-one percent. That is a software margin. That is a healthy business with room for engineering headcount, egress, retries, and idle capacity.
Now run the same envelope on a seventy-billion-parameter model. Prefill throughput on the same silicon drops to somewhere between five and ten thousand tokens per second, because attention cost and weight movement scale with parameter count and the arithmetic intensity of prefill does not rescue you. That is eighteen to thirty-six million tokens per hour. Marginal cost lands between $0.056 and $0.111 per million input tokens.
Against a ten-cent price, the margin runs from roughly forty-four percent down to negative eleven percent. And that is before you pay for anything else. No engineering payroll. No egress. No KV cache memory residency, which at long context is a serious line item because the cache competes for the same HBM that holds the weights. No retries. No idle capacity. No rate-limit headroom.
Real serving keeps substantial overprovisioning because traffic is bursty and tail latency is a product requirement. Effective utilization in production routinely sits well below the theoretical ceiling, which pushes the real marginal cost up by a meaningful multiple. A model that looks marginally profitable at one hundred percent utilization can be deeply unprofitable at forty percent.
So the price is only sustainable under one of three conditions. The model is small enough that the throughput assumption holds. The operator owns or has deeply discounted compute. Or the price is a customer-acquisition subsidy that will be repriced once the installed base is large enough to make repricing survivable.
I want to be explicit that this is a model, not a measurement. I have no parameter count, no hardware disclosure, no utilization data, no batch size. But the direction of the constraint is not ambiguous: at $0.10 per million input tokens, model size is not a free variable. It is pinned. You cannot serve a frontier-scale dense model at that price and clear a margin on rented silicon. The arithmetic does not permit it.
There is a second-order consequence that most readers will skip, and it is the one that matters for anyone building on this.
If the model is small, the capability ceiling is small. A distilled or narrow model can be excellent inside its task distribution and fail badly outside it, and the failure mode is not graceful. It does not say I do not know. It returns a confident label drawn from the nearest region of its training distribution.
Decision as a task category, meaning classification, routing, adjudication, is precisely the kind of narrow task where a small model can match a large one. It is also precisely the kind of task where a wrong answer is expensive, because decisions get acted on. A chatbot that hallucinates is embarrassing. A router that misclassifies is a production incident. A risk scorer that drifts is a regulatory event.
Inference B: Prompt Caching Is Real, and It Is the Strongest Signal in the Document
The cached-input price is one tenth of the input price. That ratio is not arbitrary. It is the ratio that emerges when you have actually built prefix caching, because a cache hit skips the prefill computation entirely and leaves you paying only for KV cache memory residency plus the residual decode work.
To offer a ninety percent discount and still clear a margin, an operator needs several things working simultaneously. A KV cache that persists across requests rather than being freed at request boundary. A prefix-matching strategy that finds the longest reusable block efficiently, because a naive scan costs more than it saves. A scheduler that batches cache-hit requests differently from cache-miss requests, since mixing them wastes the whole advantage. Session-affinity routing so a request carrying a hot prefix lands on the replica that already holds it, which means the load balancer has to be prefix-aware rather than round-robin. And an eviction policy that does not thrash when the working set exceeds HBM capacity.
That is a real inference stack. That is not an HTTP wrapper around somebody else's endpoint.
This is the part of the announcement I trust most, and the reason is falsifiability. A ninety percent cache discount is hard to fake. You can fake a benchmark. You can fake a waitlist. You can fake a partnership announcement with a logo and a quote. You cannot fake a cache hit rate at scale, because the moment real traffic arrives with real prefixes, a system without prefix reuse either serves slowly or loses money on every single request. The discount is a public commitment that the infrastructure behind it exists, and it is the only such commitment in the document.
There is a corollary, and it is strategic rather than technical. The existence of cache pricing implies the existence of cache traffic. Someone is sending requests with long, repeated prefixes. That is the signature of agent systems: a fixed system prompt, a fixed tool schema, a fixed policy block, a fixed set of few-shot examples, with only the tail varying per call. In a well-designed agent loop, the reusable prefix can easily exceed ninety percent of total input tokens. The pricing page is telling you who the customer is, even though the customer list is not disclosed.
Inference C: The Product Is Narrow, and the Missing Output Line Proves It
Now the omission pays out.
Decision tasks emit labels. A class, a score, a routing target, a short JSON object with two or three fields. The output token count per call is tiny. Often under twenty tokens. Sometimes under five.
If you are billing primarily on input, and your output is a handful of tokens, publishing an output price is almost an afterthought. The economics live entirely on the input side, and the input side is where the cache discount does its work.
Compare that to a general chat or completion API, where output is the expensive direction. Every general-purpose provider leads with both numbers, prominently, because the output number is the one that determines the monthly bill. A pricing page that publishes input and cached input and then stops is describing a different shape of product. It is an interface where the input is the workload and the output is a receipt.
That inference has a direct security consequence, which I will develop in the next section, because it changes what an attacker's objective looks like. If the valuable surface is the input, then the attack surface is the input. Prompt-level manipulation is not a side channel in this architecture. It is the main channel.
The Competitive Ladder, and Why the Headline Number Is Not the Weapon
Place the two prices against the public market.
Frontier general models: roughly $2.50 per million input tokens, with cached input around $1.25. That is twenty-five times the headline input price here, and it is not a threat comparison, because nobody choosing between these two products is actually choosing between these two products.
Mainstream lightweight models: roughly $0.10 to $0.30 per million input, with cached input in the $0.03 to $0.075 band. That is one to three times on input and three to seven times on cache.
Hosted small open-weight models: roughly $0.05 to $0.15 per million input, with caching inconsistent or absent across providers. That is half to one and a half times on input, and the cache comparison is not even meaningful because the feature frequently does not exist.
Read that ladder as a competitive statement rather than a price statement. The input price says we are not attacking the frontier. The cache price says we are attacking a specific workload shape.
The workload shape is high-repetition prefix with low-variance tail. Agent orchestration. Batch document adjudication. Policy evaluation against a fixed rulebook. Routing layers with stable instruction blocks. Those workloads are brutally price-sensitive because they run at volume, and they are exactly where a ninety percent cache discount dominates the total bill. In an agent workload where the reusable prefix is ninety percent of input, a ten-to-one cache ratio cuts the effective blended input price by roughly eighty percent relative to a provider with no cache tier at all. That is the whole argument.
It is a coherent product thesis. It is also a thesis with almost no moat, which brings me to the part where the document stops being helpful and structural reasoning has to carry the weight.
Unit Economics: Why Ninety Percent Off Is Pass-Through, Not Generosity
A ninety percent cache discount reads like a subsidy. It is not. It is cost pass-through with a margin on top.
When a prefix is fully cached, the prefill computation does not happen. What remains is reading KV state out of HBM, which is memory-bandwidth cost rather than compute cost, plus the residual decode for the output tokens. If output is five tokens, the residual is negligible. The marginal cost of a cache hit is therefore a small fraction of the marginal cost of a cache miss, frequently under ten percent and sometimes under five.
Which means a ten-to-one price ratio approximately tracks a ten-to-one or better cost ratio. The operator is not losing money on cache hits. The operator is charging approximately what the hit costs, plus a normal software margin, and using the visible discount as a marketing instrument against providers who have not built the feature.
I have seen this exact pattern of misread economics in DeFi yields. A headline APY that looks like generosity is usually a decomposition problem: strip the emission subsidy out of the base rate and you find a number that is merely competitive. The skill is not in reading the headline. It is in decomposing it. The cached price is not a gift. It is a receipt for infrastructure that the competitor does not have, printed in the only unit the market reads.
The Anchoring Problem
Which brings back the missing output line, because its absence is not neutral.
Inference service pricing is dominated by output cost in most real deployments. A three-to-five-times output multiple is standard. If this product follows that convention and the output multiple is four, then a customer whose workload is input-heavy sees an effective blended cost far above the headline number, while a customer whose workload is output-heavy sees a blended cost several times the headline. Neither customer experiences the ten-cent figure as their actual bill.
A pricing page that publishes the cheapest line and omits the expensive one is doing something that has a name in behavioral economics, and it is the same thing a project does when it announces total value locked without disclosing how much of it is recursive. The number is not false. It is selected.
This is not an accusation of fraud. It is a description of standard marketing practice applied to a technical document. But an analyst who takes the headline as the cost basis is doing the same thing as an analyst who takes TVL as the liquidity depth. Both numbers are real and both are answering a different question than the one being asked.
What a Complete Disclosure Would Contain
A gap map is only useful if you name the gaps precisely, so let me do that.
A competent disclosure for a product in this category would include output pricing and the exact multiple it implies. It would include context window limits, because cache behavior at long context is the whole engineering story. It would include per-key rate limits and burst allowances, because headline pricing without throughput ceilings is a number without a denominator. It would include p50 and p99 latency under stated load, because a decision endpoint in a synchronous agent loop lives or dies on tail latency. It would include an evaluation suite with methodology, not just a score, because a score without methodology is a screenshot. It would include a data processing agreement, retention policy, residency options, and an explicit statement about whether customer inputs are used for training. It would include a status page and an incident history. It would include the legal entity, because enterprise procurement cannot sign with a placeholder.
Every one of those fields is absent. That is not a scandal. It is a maturity marker. This is an early-stage product with a genuinely good price and genuinely unproven operational depth, and the announcement is written for developers who will try it in an afternoon rather than for buyers who will run a twelve-month evaluation.
Which is fine, as long as you know which audience you are in.
Contrarian: The Blind Spots the Pricing Page Cannot Cover
The Middle-Layer Squeeze
The ecological position implied by this product is a classic sandwich. Upstream sit compute providers and foundation model weights. Downstream sit agent platforms, internal automation teams, and adjudication systems. The Decision API sits between them, adding routing and task specialization.
Both ends of that sandwich can compress it.
Upstream, if the operator is wrapping a third-party foundation model rather than serving its own weights, the gross margin belongs to the upstream vendor, and the upstream vendor can ship a direct integration at any time. Downstream, a customer's migration cost is a single endpoint string. There is no lock-in, no data gravity that survives export, no switching penalty beyond a configuration change.
I have watched this structural weakness play out in another domain for two years. The layer-two sequencing debate is the cleanest recent example: decentralized sequencing has been a slide deck for roughly two years while the production topology remains a single operator with a failover script and a multisig key. The lesson generalizes cleanly. A middle layer that cannot control its upstream and cannot bind its downstream survives only on operational excellence, and operational excellence is invisible from a pricing page.
The one thing that could create real gravity is accuracy or latency that competitors cannot replicate. Neither is disclosed. No benchmark. No p50 or p99 figure. No throughput-under-load number. No third-party evaluation. A price with no capability data attached is not a value proposition. It is a question with a decimal point.
And the moat question has a brutal answer. Any provider with a working prefix cache can match this price within weeks. Pricing is copyable. The only defensible positions are accuracy, latency, and integration depth, and those three are exactly the three the announcement does not address.
Cache Poisoning: The Attack Surface That Cache Pricing Implies
This is the part I would flag first if I were reviewing this as a procurement item, and it is the part no pricing announcement will ever mention.
Prefix caching introduces a shared state layer between tenants. That is the entire point of it. Reuse. And any shared state layer between tenants is a lateral movement surface.
Consider how a prefix cache is typically keyed. A hash of the token sequence, sometimes with a tenant identifier mixed in, sometimes not. The sometimes not is where things get interesting. If the key is purely content-derived, two tenants who happen to send the same prefix share a cache entry. In most cases that is a performance win and nothing else. But the semantics of shared KV state are not obviously identical to the semantics of shared text, because the KV state is a function of the model weights, the tokenizer version, the positional encoding scheme, and the attention implementation. Version skew between replicas can produce a cache hit that returns attention state computed under different conditions than the current request assumes. That is not a security vulnerability in the classical sense. It is a correctness bug with a security-shaped blast radius, and it is the kind of thing that never shows up in a benchmark.
I spent four months in 2026 building a sandbox environment where language models could generate and test transaction payloads without touching real funds, and the vulnerability class I found most consistently was not in the model's reasoning. It was in the plumbing around it. Adversarial prompt engineering does not have to make a model say something wrong. It only has to make a downstream system do something wrong. A crafted prefix that occupies a cache slot, combined with a routing policy that prefers the hot replica, is a mechanism for influencing which requests share context and which replica serves them. That is a logic bomb assembled out of operational primitives rather than code.
The practical version for a decision endpoint is worse than for a chat endpoint, because the output is a label that gets acted on. If an attacker can bias the prefix state toward a particular decision boundary, they do not need to break the model. They need to nudge a routing decision, a risk score, or an adjudication outcome by a few points in a direction that is profitable. And because the output is short, the attacker never sees a paragraph that looks wrong. They see a number that looks normal.
In a system whose entire value proposition is that it decides, the integrity of the decision path is the product, and no pricing page has ever disclosed a cache isolation model.
The mitigations are known and boring. Tenant-scoped cache keys. Cache invalidation on model or tokenizer version change. Per-tenant memory quotas so one workload cannot evict another's hot prefix and degrade its latency. Provenance logging that records which cache entry served which request. Adversarial testing of prefix collisions as part of the release gate. None of these appear in the announcement. That is not proof they are absent. It is proof they are not being sold, which for a B2B inference product is itself a signal about how enterprise-ready the offering currently is.
The Governance Stress Test: One Endpoint, No Fail-Safe
My work on the Terra Classic recovery mechanisms left me with a specific habit. When I look at any system that claims resilience, I go find the pause button and ask who holds the key.
I found that the emergency pause function on that chain relied on a single multisig wallet, which contradicted every decentralization claim in the surrounding documentation. The finding was not dramatic. It was mundane, and it was disqualifying, because a fail-safe that depends on one key is not a fail-safe. It is a single point of failure with better branding.
Here the pause button is the endpoint itself. There is no service-level agreement disclosed. No multi-region failover description. No status page referenced. No uptime history. No incident postmortem. For a hosted inference dependency, that is the entire reliability story and it is unwritten.
Trace the failure path. An agent platform builds its decision layer on this endpoint. The endpoint degrades, whether from capacity shortfall, a bad model rollout, a cache invalidation storm, or a regional outage. What happens downstream? The agent either halts, which means the automation stops, or it falls back to a default path, which means decisions get made by whatever the fallback is. In most systems I have audited, the fallback is return the previous value or escalate to a human, and in neither case does anyone get paged at three in the morning with the right context to understand what changed.
A distributed fail-safe requires that the degraded path be defined, tested, and observable before the incident. A pricing announcement that does not mention the degraded path is telling you the degraded path has not been productized. That is not a criticism of the price. It is a statement about what you would be depending on if you built on it.
Governance Theater, Revisited
There is a version of this problem that appears after the token, not before it, and I want to name it now because the pattern is predictable.
On-chain governance turnout sits below five percent on most major protocols, and the decisions that actually move parameters are made in channels that do not produce a transaction until the vote is already settled. The mechanism is transparent. The power is not. I have watched the same choreography migrate into AI governance: safety councils with advisory mandates, ethics boards without veto power, published principles without a binding trigger. The form is accountability. The function is insulation.
If this service later acquires a foundation, a token, and a validator set, watch whether the safety parameters, meaning rate limits, model version pinning, cache isolation policy, and deprecation schedules, are controlled by a token vote or by an operator key. The answer will be obvious within one incident, and it will be the same answer the sequencer question produced.
The Regulatory Edge Created by the Product Name
One more blind spot, and this one is created by the naming choice rather than the pricing.
Decision is a loaded word in regulated industries. Automated decision systems used in credit, employment, insurance, or access to essential services fall under transparency and explainability obligations in several jurisdictions, most visibly the high-risk classification regime in the European Union. A vendor that names its product a decision API and publishes no model card, no evaluation methodology, no bias testing, and no explanation interface is a vendor that has not yet had to answer the question.
The regulatory exposure is not in the API itself. It is in the customer's use case, and the vendor inherits it through the name. That is a solvable problem. Publish an intended-use statement. Publish an evaluation suite. Ship a rationale field alongside the label. All of it costs money and time, and none of it appears in the announcement.
The Data Governance Silence
For a B2B inference API, the single most common procurement blocker is not price and it is not latency. It is the answer to one question: does my input train your model, and where does it physically live.
The announcement says nothing. No data processing agreement. No retention policy. No isolation model. No residency options. No SOC 2 or ISO 27001 reference. No statement about whether prompts are logged, and if so for how long and under whose access control. In financial services, healthcare, or legal workflows, the three verticals where a decision endpoint would be most valuable, that silence is disqualifying at the procurement stage regardless of how good the price is.
I want to be fair about the epistemics here. Absence of disclosure in a short announcement is not absence of capability. The announcement may simply be truncated, and the sparseness may be an artifact of the ingestion pipeline rather than a property of the original document. But a buyer cannot act on a capability that is not documented, and a vendor selling into enterprises who does not lead with data handling is a vendor that has not yet sold into enterprises.
Takeaway: What to Watch, and What the Missing Line Will Tell You
Strip the narrative and you are left with a clean, unglamorous read. A small or distilled decision model, served on a real inference stack with working prefix caching, priced at market-median input and market-floor cache, from an operator whose team, funding, compliance posture, and accuracy numbers are all undisclosed.
That is not a scam. There is no unlock schedule, no leverage, no governance attack surface, no treasury to drain, no recursive collateral. The business model is a software margin on metered inference, and if the model is small the margin is real. Logic prevails where hype fails to compute, and here the computation comes out boring, which is the most reassuring thing I can say about it.
What I would watch, in order.
The output price line. When it appears, the multiple tells you what the product actually is. A three-to-five-times multiple confirms a narrow decision interface with tiny outputs. A one-to-one multiple suggests something closer to a general completion endpoint wearing a narrower name. No output line at all, six months from now, suggests the product is being repriced or repositioned behind a quiet migration.
The rate limit table. Aggressive headline pricing is frequently paired with tight per-key throughput ceilings, and the gap between the published price and the achievable price is where the real unit economics hide. A price you cannot reach is a price you were never offered.
The data processing terms. The first enterprise contract will force this into the open, and the shape of those terms will tell you which vertical the operator is actually targeting. Retention measured in days versus retention measured in minutes is a completely different product.
The accuracy disclosure. No amount of caching sophistication substitutes for an evaluation suite. A decision endpoint without published evaluations is a black box with a discount attached, and discounts are exactly the kind of thing that gets withdrawn once the black box is load-bearing.
And one thing I would watch for specifically, because the pattern is now well-worn. Whether this gets wrapped in a decentralization narrative. If within a year the same service reappears with a token, a validator set, and a claim about trustless inference, go back and read the topology before you read the announcement. The sequencer playbook ran for two years on slides, and the manufactured-problem pattern that produced liquidity fragmentation as a narrative category is available off the shelf for anyone who needs a reason to issue. Inference has more moving parts and the same temptation.
The question to ask then is the question to ask now. When the system degrades, who holds the key, and can you see the degraded path before it happens? Three data points are enough to establish a cost basis. They are not enough to establish trust. Those are different questions, and this announcement only answered the first one.