IronStratum

Documentation

Everything about calling the IronStratum API: get running in five steps, understand the prices (generated from the live catalog), and read every endpoint in the API reference — derived from the same OpenAPI specification the API serves.

Core

  • Quickstart — From zero to your first generated token in five steps. Create a key, export two variables, and call the API with curl.
  • Pricing — The live catalog generates every price on this page. The table is what the platform charges, to the token. Nothing else lands on the bill.
  • About IronStratum — IronStratum is an inference platform. We run and relay AI models behind one OpenAI-compatible API at `api.ironstratum.com`. Point any OpenAI SDK at it. Create a key in the console and call. There is no adapter layer and no dialect to learn.
  • Sessions — Server-side conversation continuity. You send only the new turn. We assemble the context. It is opt-in per request with one field, `session_id`. Every session-mode tool (list, inspect, cost, delete) lives under `/v1/conversations`.
  • Idempotency — Retries are safe here. Send an `Idempotency-Key` header. The same logical request returns the same logical response. There is no duplicate generation and no double billing. We shipped this for inference because nobody else has it, including OpenAI.
  • Streaming — Set `"stream": true`. The response becomes a server-sent-events stream of chat completion chunks. Same envelope, token by token.
  • Errors — Every error is one envelope: parse it once, handle it everywhere:
  • Rate posture — Honest current state, no marketing fog: what limits exist today, what is reserved for later, and where the numbers live.
  • Beta commitments — Five commitments, in the words we shipped them. Each one maps to a community pain we designed against. This page is the contract you hold us to.
  • OpenAI-compatible API guide: the compatibility matrix — An OpenAI-compatible API is a wire format agreement, not a relationship with OpenAI. The chat completions request and response shapes are the same. The bearer-key authentication is the same, and so are the streaming conventions. Somebody else serves it all. This guide defines the phrase precisely. It shows the two-line swap that moves any OpenAI SDK onto this platform. It publishes an endpoint by feature compatibility matrix that no ranking page carries. It lists the exact model strings to type. And it gives you a five-minute test that proves what an endpoint really accepts, including the failure you get back when you send a parameter it does not know.

Platform routes

  • VLA action route: the /v1/action endpoint contract — What the /v1/action endpoint takes and returns: camera frames, an instruction, and robot state in, an action chunk with norm stats out, one billed call.
  • Vision route: the /v1/vision endpoint contract — What the /v1/vision endpoint takes and returns: image file parts in, JSON or rendered bytes out via the response_format field, billed per image.
  • Robot embodiment stats: the per-embodiment reference — Robot embodiment, in working robotics terms, is a body described by numbers. The numbers say how many joints the model commands, which cameras it sees through, what the commands mean, and how fast they play. This page is the reference for those numbers. It decodes the vocabulary, then documents the norm_stats.json artifact field by field. It tabulates the known bodies exactly as the open publishers print them. It states the stats contract of the platform's published action route.

Guides: audio

  • Real-time speaker diarization: the build-or-buy guide — Real-time speaker diarization answers one question while the audio is still flowing: who spoke when. This guide walks the four-step pipeline. It shows why clustering is the hard part. It explains why offline diarization falls apart on live crosstalk. It teaches you to read the DER and cpWER numbers vendors quote. It states the session-length limits almost nobody publishes. It works the build-or-buy math with measured streaming latency from this platform's transcription lane. And it gives an honest account of where speaker labels stand today.
  • TTS local vs API: the break-even math — Local TTS versus a hosted API is a volume question, and volume questions have answers in arithmetic. This guide gives the crossover formula in characters per day. It works the formula across two real GPU tiers at September 2026 street prices. It uses the official United States electricity price. It also shows the latency and long-text physics that stay identical on both sides of the choice. So the decision lands on your numbers rather than on someone else's rig.
  • Transcribe long audio files: limits, chunking, speed math — Long audio breaks naive transcription setups in three places. One is the file cap on a single request. Another is the streaming session cap almost nobody publishes. The third is the client that tries to hold hours of audio in memory. This guide puts the duration and session limits of nine speech APIs and this platform in one dated table. It answers the 30-minute speed question with a measured real-time factor instead of a human-typist ratio. It gives you runnable chunking code for batch and streaming. The same spine then covers text output: model output caps, the continuation pattern, and the character caps on speech synthesis.
  • Ornith 1.5 local vs hosted: the break-even math — Running an open model on your own GPU or renting it per token is a volume question. Ornith 1.5 is the worked example this guide uses to answer it. The family spans two runnable members, the 9B dense model and the 35B-A3B mixture-of-experts model. The guide maps what each one needs in VRAM at each quantization. It covers how fast they run on named consumer cards, including this platform's own dated measured baseline. It names which providers serve the model hosted, and at what published rates. This platform serves both lanes today, with their rates named and dated. The crossover arithmetic turns your electricity price and your street-price card into a number. That number is the daily token volume where local stops being cheaper.
  • Building a Muse connector: the API, the costs, and what to prep — Meta opened Muse connectors to developers on 2026-09-18. Your service stops waiting to be installed. It starts being reached by an agent when a person's task needs it. This guide lays out what Meta has actually published about the program. It covers what an agent-facing API needs to have ready. It shows where the metered model spend sits in a connector's backend. And it explains how a prepaid wallet turns the worst backend bill into a top-up instead of a debt. It also separates the Muse agent platform from the Muse Glimmer open-weight model served on this platform. The shared name is already tangling searches.
  • Muse Glimmer 30B local vs hosted: the break-even math — Muse Glimmer 30B is the open-weight agentic model. Meta Superintelligence Labs distilled it from Muse Spark. Because it is open weights, you can run it on your own card or call it as a metered API. This guide gives the memory ladder from the 18 GB community-quant floor to the 60 GB full-precision build. It covers the two local gotchas the listings do not advertise. One is a non-JSON native tool-call format. The other is reasoning controlled by a system-prompt phrase. It also covers the hosted rates on this platform and on the marketplace beside it. And it gives the crossover arithmetic. That tells you at what daily volume your own card wins.
  • Whisper local vs API: the break-even math — Running Whisper yourself versus paying per audio hour is a volume question, and the answer is arithmetic. This guide gives the crossover formula in audio hours. It works the formula across two real GPU tiers at September 2026 street prices and the official United States electricity price. It reads the hosted rate ladder the way an invoice reads it. Two of the prices in that ladder turned out to be wrong in 2026, in ways that moved the answer by up to a hundredfold.
  • Whisper cost per audio hour: rates converted, crossovers worked — Whisper costs between 0.012 and 0.36 per audio hour across the hosted rates read for this page on 26 October 2026. Below roughly 30 audio hours a month, the hosted side wins on every tier worked here. Past roughly 7,400 hours a month, an owned card wins against every rate read here, budget floor included. Between those bounds the answer is a table lookup. This page is the tables: every named rate converted to per audio hour, local power priced per audio hour at three speed tiers, and the crossover worked for each party against each card tier.
  • ElevenLabs vs local TTS cost: the crossover arithmetic — ElevenLabs bills its speech API at 0.04 to 0.08 per 1,000 characters, read from its own price page in October 2026. A used card crosses over against those rates at a volume you can compute. This page runs the math on dated inputs, then adds a third option most reviews skip: hosted open weights near 1 per million.
  • Hayamimi Japanese speech-to-text: the Whisper duel on Japanese audio — For Japanese audio, the general-purpose default loses to a specialist. On real TV broadcast Japanese, the hayamimi project scores 3.8% character error rate. Whisper-large-v3-turbo reads 13.8% on the same clips. It runs 11 to 19 times faster on a plain CPU. This page lays out that duel with its dates. It shows where Whisper still wins. It walks the fine-tune lane between them.
  • Kokoro TTS local vs API cost: the break-even math for one model — Local Kokoro and a hosted speech lane cost the same at one daily text volume. This page works out that break-even point for Kokoro alone. The inputs: a measured 0.0149 seconds of synthesis per input character, September 2026 hardware reads, and the official power price. The answer lands in characters per day and in minutes of finished audio.
  • Kokoro vs Chatterbox: the local TTS head-to-head, decided job by job — Kokoro wins on speed. It is about six times faster per character on measured lanes. A plain CPU runs it. It also outranks Chatterbox on blind listening with stock voices. Chatterbox wins on voices. It clones a speaker from five seconds of audio. It carries an emotion dial, and it speaks 23 languages. This page settles the pair with dated numbers, then names the winner per job.
  • Transcribe long audio: the limits platforms actually enforce — Long audio hits four caps before it hits a price. The caps are the size of one request, the time one request may span, the life of a streaming session, and the tokens a model may return. This page states each provider's numbers as read on 2026-10-28. It then answers the 30-minute speed question with machine math, not a typist ratio.
  • Pocket TTS use cases: the Kyutai CPU voice, envelope by envelope — Pocket TTS is Kyutai's 100M-parameter speech model, and its use cases follow one rule: it goes where the hardware is thin. On two laptop CPU cores it speaks about six times faster than real time. In a browser tab it runs on WebAssembly. On a phone it reaches about real time through an outside port. This page maps what people build with it, envelope by envelope, from screen readers to game voices, with dated numbers and the cloning rules attached.
  • Pocket TTS vs Kokoro: two CPU voices, two different jobs — The two open models that speak faster than real time on a plain CPU are Kokoro and Pocket TTS. They split by job, not by rank. Kokoro, at 82M parameters, is the fixed voice pick for volume. It has 28 English voices on this platform, the faster measured lane, and no cloning. Pocket TTS, at 100M, is the flexible pick. It clones a voice from about five seconds of audio on your own machine, speaks seven languages, and holds its speed from a greeting to a chapter.
  • Real-time factor explained: the ratio that turns audio length into processing time — Real-time factor, written RTF, is processing time divided by audio length. An RTF of 0.5 means one hour of audio takes 30 minutes to process. Anything below 1.0 outruns the recording. This page gives the formula and measured examples from speech and video. It names the two conventions that trip buyers up. It closes with a method you can run on your own audio.
  • Real-time factor (RTF): the glossary of speech speed terms — Real-time factor, written RTF, is processing time divided by audio length. Both times use the same unit. Below 1.0, the system outruns the recording. The flipped form, RTFx, divides the other way. There, higher is faster. This glossary defines both. It also defines the latency, throughput, pacing, and clock-window terms around them. Every entry carries one worked number and one link.
  • STT streaming session limits: the caps, the failure modes, the reconnect loop — A live speech-to-text stream never runs forever. One major vendor ends streams at five minutes. Another allows eight hours per connection. Most publish the number nowhere a buyer would look. This page puts every published streaming session cap in one dated table, sorts the ways a stream dies into four shapes, and shows the reconnect loop that carries hours of live audio past any cap.
  • TTS voice cloning limits: consent gates, clone counts, and streaming caps — Voice cloning limits are published one vendor at a time, if at all. This page reads each vendor's own docs on one day and lines up what every TTS seller enforces: the consent gate, the sample floor, the clone count, the per-request text cap, and the concurrency cap. Every number carries its read date. The short version: consent checks are the first limit you hit. Clone counts are a plan feature. Streaming caps differ by more than a hundredfold.

Guides: robot

  • The GR00T license and commercial use, answered from the file — No. The license file that ships with the GR00T N1.7 weights does not permit commercial use. It limits the model to research and evaluation, keeps commercial rights with NVIDIA and its affiliates, and pushes that limit into every fine-tune. Three other NVIDIA surfaces tell a different story. The model card, the code repository, and the launch post all point to a license that would allow commercial use. This guide quotes the file, sets the four claims side by side, explains which document governs your copy, and names two Apache-2.0 vision language action models you can run commercially instead.
  • VLA normalization stats, from LeRobot to serving — The policy that moves your robot arm never sees your joint angles. It sees numbers that were shifted and scaled into a small band, and it predicts in that band. The map between your units and that band is a set of numbers. They are called norm stats, short for normalization statistics. The map is computed once from your dataset and stored in a small file beside the model. When the map is wrong, nothing crashes. The arm just moves wrong, and at times it moves in ways that are not safe. This guide covers the numbers, the file, the mode each model family wants, the failure signs, how to check and fix your own, and what a served policy owes you across an API.
  • VLA local vs API: the break-even math — Running a vision language action model on your own GPU or paying a hosted route per call is a volume question, and the answer is arithmetic. This guide gives the crossover formula in robot hours per month. It turns your control loop into calls per hour using the action chunk, the unit that frame counting overstates fifty times at thirty frames per second. Both sides price from dated public sources: street prices, manufacturer power, government electricity, public benchmarks. This platform's action lane serves three rows since 26 October 2026; the pricing page carries the listed rows' rates. The framework works on any rate card.
  • The SO-101 with its brain in the cloud — The SO-101 arm ships with a loop everyone teaches in four steps: record demonstrations, build a dataset, train a policy, then run it. The teaching stops right where the hard part starts. The trained policy has to run somewhere, and that somewhere decides what computer you need. This guide walks the whole loop and names where the brain sits at each step. It then shows the two ways to serve a policy when your own computer is not enough. One is a policy server you point at rented hardware. The other is a hosted action route. The hosted route on this platform serves three rows since 26 October 2026. The loop, the numbers, and the model choices are real today.
  • VLA evaluation: LIBERO and the benchmark zoo, honestly — Vision language action models get judged on LIBERO. This guide explains what the benchmark is, suite by suite, with the task counts that trip people up. It shows the two open paths for running it. It lists the published scores for the models this platform writes up on its action route, each with source and date. Two runs of the same model are never merged here. It also covers what LIBERO cannot tell a buyer, the robustness suites, and how to read a leaderboard without getting fooled. Three robot rows are on the public list since 26 October 2026. The benchmark, the numbers, and the run commands are real today.
  • Jetson vs cloud: where a robot's inference lives — A robot brain can sit in three places: on the robot, in a box at the site, or in a data center. The physics picks one, not preference. This guide places each layer of the control loop by its timescale, on measured numbers from a 2026 study, a placement model from Stanford and NVIDIA, and the publishers themselves. The action chunk is the reason a network hop is survivable at all, and Real-Time Chunking is the named fix that makes hundreds of milliseconds feel smooth. It also works the forgotten costs: battery hours, uplink bandwidth, and the memory cliff. The action routes here are not on the public list, the perception rows serve today, and the placement rules hold either way.
  • How to use MolmoAct2: from artifact to SO-101 — MolmoAct2 is an open vision language action model from the Allen Institute for AI, released in May 2026 under Apache 2.0. This tutorial walks the working path. It covers which checkpoint to download, what the honest numbers say, and how to record data and fine-tune on an SO-101. Then it covers what hardware each precision needs, and how the platform's published action route contract serves it with no GPU. Every number here is sourced and dated.
  • Segmentation and depth for robots — A robot that reaches into the world needs two answers from its cameras. Which pixels belong to the thing it must handle. And how far away those pixels are. Segmentation answers the first question. Depth estimation answers the second. This guide is for the builder putting both into one robot. What each output feeds, which family and tier to pick, how the two combine into a grasp point, and how perception sits next to a policy. Two of the vision lane's rows, sam2.1-base and da3-small, serve on this platform today; the large tier does not. The model facts, the numbers, and the recipes are real today.
  • Vision language action models explained: the 2026 map — A vision language action model, or VLA, is one neural network that looks through cameras, reads an instruction, and outputs the motion commands for a robot. This guide explains the class in plain words. It covers where the class came from, how it turns frames and text into action chunks, which models exist in 2026, and what they still cannot do. Every number carries its source and its date. The tour maps each model family to its page on this site. The action lane on this platform serves three rows since 26 October 2026. The class, the model set, and the call contract are real today. You can shape a client against the published contract now.
  • pi 0.5 quantile-normalization ValueError: the loud crash — Training stops on the first batch with `ValueError: QUANTILES normalization mode requires q01 and q99 stats`. The cause is simple. Your dataset's stats file holds no q01 and no q99, and pi0.5 normalizes state and action with those two bounds. Two fixes work. Recompute the stats, or run the job in mean and std mode. The recompute writes to `$HF_LEROBOT_HOME`, not to the copy your training command reads. That is where most people lose an afternoon.
  • Alternatives to OpenVLA: the hosted ways to run it, answered — There is no official OpenVLA API to switch from. Checked on October 27 2026, the real alternatives are four paths. Run the open weights on a rented GPU card. Try OpenVLA-OFT, the faster recipe the OpenVLA makers themselves now recommend. Run a smaller open model on hardware you already own. Or call a specialist host that serves four OpenVLA fine-tunes per call today. Every rate on this page carries its party and its date. Where a party publishes nothing, the table cell stays a dash.
  • Alternatives to the Physical Intelligence pi API — The Physical Intelligence pi API opened as a beta on 13 October 2026. It is waitlisted and it publishes no price. That is the whole first-party record today. The real alternatives are three paths. You can run the open pi 0.5 weights yourself. You can use another open vision-language-action model through a host that serves it. Or you can budget a per-call lane on this platform. Every path below was checked on 26 October 2026. Where a party publishes nothing, the table cell stays a dash.
  • Cosmos Reason 2 2B vs 8B: the size chooser, answered — Pick by hardware first, accuracy second. On the smallest Jetson class the 8B is not an option at all, and the 2B fits only in a quantized build. From a 24 GB card up to a 32 GB card or better, the 8B leads every published category total, so take it when scores matter. If you call an API instead of hosting, the market splits for you: NVIDIA's hosted tier carries the 8B only, at no charge inside request limits, and this platform carries the 2B. The license is identical on both sizes, so it breaks no ties.
  • Cosmos Reason 2 API pricing: three sizes, three different answers — Cosmos Reason 2 API pricing has three answers, one per size, and search mixes them up. As of 27 October 2026 the 8B model runs on NVIDIA's own hosted tier at no charge, inside rate limits. The 32B carries published per-token rates at one host and an hourly dedicated rate at another. The 2B has no third-party hosted row on any surface this page checked, and the one listed per-token rate for it sits on this platform's chat route. This page shows the dated census behind those three sentences, decodes the numbers search actually returns, and works the token math for a grounding loop.
  • Depth Anything 3 small API pricing: the dated answer, seller by seller, unit by unit — There is no official Depth Anything 3 API to price. The team behind the models, at ByteDance Seed, ships weights and code. It ships nothing hosted. The small tier's page on Hugging Face lists zero inference providers as of 26 October 2026. What you can buy is a scatter of units. Community rows on Replicate bill by GPU second. One V2 endpoint bills per image. A video model bills by length. A browser workspace bills credits. This page maps every seller with its unit, its date, and its license. Then it works a per-image budget on this platform's da3-small lane, which has served since 6 October 2026.
  • Do the big hosts serve robot models? A dated read of eight hosts — Checked on October 26 2026, seven general model hosts were read one by one. Not one of them serves a robot policy over its public API. Hugging Face carries the three most downloaded robot checkpoints, and not one of the 500 rows read from its robotics listing carries hosted inference. NVIDIA's build portal does serve robot models, but only its own. Two small specialists serve robot policies today, thirty models between them, and one of the two publishes prices.
  • What is embodied reasoning? The term, its senses, and the Gemini ER era — Embodied reasoning is a robot's skill at tying what it sees, what it plans, and what it does into one loop. The plan then answers to the real world, not just to a text prompt. But the phrase has more than one owner. This page splits the four senses apart. It names who uses the phrase, who avoids it, and what to ask the next person who says it. Every check on this page is dated October 26 2026.
  • Embodiment gap: the 2026 term, defined — The embodiment gap is the work left over when a shared robot model has to run on one particular body. A ten-author survey at Japan's national lab AIST named the term in August 2026. It also pinned a test to the term. Does the problem show up only after the body changes? Lighting, a new task, or a sim-to-real move on the same robot sit outside the gap. Anything that appears only after the body changes sits inside it. Three older readings of the phrase circulate and disagree. This page settles on the 2026 one. It prints the test, the four failure groups to debug against, and the gap as numbers in real checkpoint files. There, one model ships action horizons of 50, 15, and 10, one per body.
  • Gemini Robotics API pricing: the rate card, line by line — Google publishes exactly two robotics rows on its Gemini API pricing page. They are Gemini Robotics ER 2 Preview and ER 2 Streaming Preview, and this is every line of both, read on October 26 2026. Input costs 1.00 US dollars per million tokens through December 31 2026. It rises to 2.00 on January 1 2027. Output, with thinking tokens, costs 5.00 per million tokens through the end of 2026, and 10.00 after. Batch, caching, and grounding carry the same doubling date. The guide also covers the request shapes, the token limits, our robot-day estimate, and the other public robot rate cards of late October 2026.
  • GR00T API pricing: what N1, N1.5 and N1.7 cost to run — No host publishes a per-call price for any GR00T checkpoint, anywhere, as of 26 October 2026. Not NVIDIA, not the robot-only hosts, not the big model hosts. The costs that do exist are hardware costs. One GPU with 16 GB of memory runs inference. A rented H100 works out to about 17.45 per million action steps at the rate Spheron's own guide prints. This page shows the dated checks behind that absence, turns NVIDIA's published speed numbers into a budget you can compute, and explains why the one public robot rate card that does exist does not answer this question.
  • GR00T N1 vs N1.5 vs N1.7: the version chooser, answered — Pick N1.7 for anything new. It is NVIDIA's current release, it replaces N1.5 everywhere NVIDIA now points developers, and it carries the best published results in the family. Pick N1.5 only to finish or repeat an experiment that already started on it. Pick N1 only to read history. And if your robot must ship as a product, no version clears that bar: the license file inside every GR00T release, N1.7 included, permits research and evaluation only. That answer does not change by version, whatever the launch posts say.
  • GR00T on Jetson Thor or Orin: the run guide — Yes, GR00T runs on Jetson hardware, and the path is official. NVIDIA's Isaac GR00T N1.7 repo ships installers for Jetson AGX Thor and Jetson Orin, tested on JetPack 7.2. The stated floor for inference is one GPU with 16 GB of memory or more. On Thor, published control speeds run from about 10.7 to about 28 Hz by setup, and an NVIDIA recipe reaches 25 Hz. On Orin the published ceiling is 4.6 Hz, and the fastest Thor options do not exist there. This page walks the run steps on both parts, and ties every speed number to the table it came from.
  • How many humanoids will sell in 2026: the counted answer, the forecasts, and the gap — About 19,100 humanoids shipped worldwide in the first half of 2026. That is the only counted number for the year so far. Smart Analytics Global published the count in August 2026. The forecasts for the full year run from about 60,000 to 90,000 units. They come from SAG, from Goldman Sachs in September 2026, and from Bank of America in March 2026. Nobody knows the 2026 total yet. Anyone who quotes one is extrapolating, not counting. This page keeps the counts, the forecasts, and the gap between them separate.
  • How many humanoid robots shipped in 2025: the counted actuals — About 13,000 humanoids shipped worldwide in 2025. That is Omdia's count, published in January 2026. It is the widest scope of the headline counts. The International Federation of Robotics counted about 7,000. Its definition is stricter. Both counts are honest. They count different things. Roughly thirteen thousand machines left factories. Most were Chinese-made. Most are doing research and data work, not shift labor. This page holds every number to one rule: named counter, named date, and a stated verb. The counted table, the makers, and the definitions follow.
  • What is inference frequency? How fast a policy runs, defined — Inference frequency is how many times per second a robot policy computes a fresh set of actions, printed in hertz. It is the number behind every claim that a model runs at 50 Hz or at 6 Hz. One term hides several rates. The latency of one call is one. The rate of the robot's control loop is another. Execution, the pace the arm actually follows, is a third. Underneath sit faster loops still. This page defines the term and splits those rates apart. It shows the bars the field prints and where the bars come from. It lists the rates named models claim, each with its date and its hardware. Every check on this page is dated October 27 2026.
  • LeRobot camera errors: the camera never opens, or the keys do not match — Your LeRobot run stops at the camera step, in one of two ways. Either the camera never opens: find_cameras lists nothing, or teleoperate and record quit with a ConnectionError at startup. Or the camera opens fine and the failure moves downstream: the policy cannot find the image keys it expects, and a ValueError names the missing features. This page walks both families using the exact text LeRobot prints, then the cause, the fix, and the prevention for each message. The first move is always the same: run lerobot-find-cameras opencv and read what it prints. The second move is to compare the camera key names in your config against the keys the policy expects. Most reports close at one of those two checks.
  • Modal for robotics: running pi-family models on a serverless GPU platform — Yes, you can run pi-family robot policies on Modal. Physical Intelligence, the lab behind pi 0 and pi 0.5, ran real-time remote inference for robot control on Modal itself, and its published setup added only 10 to 15 milliseconds of network overhead. But know what you are walking into. Modal is a generic serverless GPU platform. It bills by the second, you bring the container, and its own documentation carries no robotics example at all. The recipe is real and this page assembles it, with every rate and limit dated October 27 2026.
  • Molmo2-ER API pricing: no host sells the ER variant, so here is the only live rate and the real math — Molmo2-ER API pricing has no third-party public number to look up. As of 26 October 2026, no marketplace sells the ER variant at a published rate. The price-shaped results in search belong to the base Molmo 2 models, and the number they quote is a stale database record. Behind it, the listings are not orderable today. This page shows the dated census behind all that. It then gives the Google rate that anchors the embodied reasoning market, the one listed live rate for the molmo2-er model id here, and the worked math for a real perception workload.
  • MolmoAct2 API pricing: no per-call price exists, one card carries it, and the per-robot-hour math — MolmoAct2 API pricing has no per-call rate to look up. As of 26 October 2026, no seller lists MolmoAct2 at a published per-call price. One market rate card does carry the model, and it bills per million tokens in and per million actions out. The weights are open and Apache-2.0, so the price you can act on today is a rented GPU by the hour. The other option is this platform's written record for the molmoact2-so100-101 model id. This page shows every dated check, then works the per-call and per-robot-hour math at the model's own 30-step horizon.
  • MolmoAct2 checkpoint loading and dtype errors: the exact strings, causes, fixes, and prevention — MolmoAct2 checkpoint errors cluster into four families: dtype crashes led by mat1 and mat2 must have the same dtype, missing normalization files, version-split config rejections, and a known slow-loading path in LeRobot. Every released checkpoint ships its weights in float32, and that one fact explains most of the dtype crashes. This page quotes each error string exactly as the publisher's code prints it. It names the cause, gives the fix, and lists the prevention. Every source was read on 27 October 2026.
  • The robot moves wrong and nothing crashes: the norm stats error family — The robot moves wrong and nothing crashes. You fine-tuned a vision-language-action policy, or loaded a pretrained one. The arm jitters, freezes, drifts, or barely moves. No traceback appears. The training loss fell the whole time. In most cases the cause is the norm stats: the numbers that map your robot's units into the band the model thinks in. Missing, skipped, or mismatched, they produce quiet wrong motion instead of an error. A wrong map is still a valid map to the code. This page walks the failure family. You get the symptoms in builders' own words, and the reason no error fires. You get four silent causes with fixes and prevention, plus the other causes to check when the stats are fine. Keep an emergency stop within reach on every first hardware run.
  • openpi / pi 0.5 multi-GPU NCCL + CUDA crashes — If your openpi pi 0.5 fine-tune dies with `NCCL operation ncclGroupEnd() failed: unhandled cuda error`, that message is only a wrapper. The real fault sits in the last NCCL warning line above it. That line names one of three things: a cuDNN convolution failure, a CUDA memory mapping error, or an illegal memory access. Each has its own fix, and only one of the three is really about VRAM.
  • OpenVLA-7B API pricing: no rate card, so count the calls — OpenVLA-7B API pricing has no number to look up. No host publishes a rate for the base checkpoint, and the one per-call OpenVLA offer found today publishes no rate either, both checked on 26 October 2026. The price you can act on today is a rented GPU by the hour. Its design sets the rest: it returns one action per call, so your control rate sets the call count and the bill. This page works the per-call and per-robot-hour math for a model that returns a single action.
  • OpenVLA-OFT API pricing: what a call costs when no API exists — No official OpenVLA-OFT API exists to price, and as of 26 October 2026 no marketplace sells hosted access to any of its checkpoints. The authors ship weights, fine-tuning code, and a self-host REST script. This guide shows the dated checks behind the absence. It covers what the published path costs on rented GPUs, how hourly rates convert to a per-call cost, and how per-call pricing for robot models works. It ends with the platform's own written record for the openvla-oft model id.
  • OpenVLA and OpenVLA-OFT CUDA out of memory: the exact strings, causes, and fixes — OpenVLA and OpenVLA-OFT CUDA out-of-memory crashes sort into five documented situations. The error message itself tells you which one you have. Two numbers inside the line separate a real shortage from fragmentation and from another process holding the card. This page quotes the exact strings from the publishers' own issue trackers, names the cause behind each, and gives the fix and the prevention. The official memory tables set the floor: 25.7 GB per GPU to fine-tune on LIBERO at batch size 1, and 15.9 to 16.2 GB to run inference. Every source was read on 27 October 2026.
  • Physical Intelligence API waitlist (how access works) — Access to the Physical Intelligence pi API runs through one page: the waitlist form on the company's own site, checked 26 October 2026. You fill in one application about your team, your robot, and your data. The company reads it and admits teams in batches. There is no self-serve signup, no published price, no published rate limit, and no API documentation page. Each of those absences was checked today by asking the domain directly.
  • pi 0.5 (π0.5) API pricing: the waitlist, the one rate card, and the real cost per hour — Pi 0.5 API pricing has no first-party number. The only official API is the Physical Intelligence beta, waitlisted since 13 October 2026. Its post and its form carry no price, checked 26 October 2026. The big marketplaces host none of it. One new third-party platform publishes a rate card row for pi 0.5, read today and dated below. The weights are open, so the other real price is a rented GPU by the hour. This page checks every path, then works the per-call math into a cost per robot hour. The queries behind it, like pi0.5 api pricing and pi 0.5 hosted api, return no priced answer today.
  • pi 0.5 DROID checkpoint API pricing: no host prices it, the two licenses, and the cost per robot hour — No host prices the pi 0.5 DROID checkpoint. There is no per-call rate card for it on any marketplace, no published rate on the model maker's own beta, and no row on a public catalog. The weights are open, so the cost you can size today is a rented GPU hour and the training compute behind it. Two licenses apply, and they are not the same license. The checkpoint returns 15 actions per call, not the 50 the base model returns, so one robot hour holds 7,200 calls instead of 2,160. This page checks every path and prices the hour.
  • pi 0.5 LIBERO checkpoint API pricing — A LIBERO report bought through a per-call API is priced in calls, and the call count turns on one number: how many returned actions your client executes before it asks again. The documented protocol executes 10 per call. On that setting, the 500-episode report this site measured on a rented card, 1.93 in compute over 47.18 hours, holds 17,250 calls, and those calls cost 51.75 at the written-record rate for the pi05-libero model id. The card beat the meter by about 27 times, and the reason is not the rate. A card-hour meter prices the whole clock, including the simulator rebuilds that eat most of it. A per-call meter prices the policy and leaves the simulator on your machine. This page prices both paths for this one checkpoint, names every input, and lists the exact strings the run types. Third-party figures were read on 26 October 2026. The measured figures carry their own date, 2026-10-10.
  • What is a policy server? The robot term, defined — A policy server is the program that loads a trained robot policy and hands out actions over a network. The robot runs a small client. That client sends camera frames and joint positions. The server replies with an action chunk, a run of future movement. The arm works through that run while the next one is computed. This page defines the term in plain language. It separates the robot sense from the older access-control sense of the same words. Then it maps the small family of terms around the policy server. It also answers the practical questions: what the big robot stacks ship, whether running one is safe, and where the server machine should sit.
  • Can you run robotics or VLA models on Replicate? The October 2026 answer — No. As of October 26 2026, Replicate hosts no robot control models. Its collections index lists 39 model categories, and none of them is robotics. The collection pages for robotics and vla return not-found errors, while real categories return live pages. The pricing page, the blog, and the changelog carry no robot mention either. The models people hunt for here, OpenVLA, pi 0.5, SmolVLA, GR00T, are open weights you run yourself or get from small new specialists. This page shows the receipts, explains why the gap is structural, and gives you four working paths.
  • ROS 2 inference node latency / timeout: what is slowing the loop — A ROS 2 inference node that is slow, spiky, or timing out is almost always one of three families. The first call is slow and the rest are fine: model warm-up, from CUDA graph capture, cuDNN algorithm selection, or an engine build. Every call is slow and the timers stall: an executor is serializing callbacks behind the inference. The data arrives stale or not at all: a silent QoS mismatch or an old transform. Measure first with topic statistics, read the printed string, and fix the family it names. A timeout is a hold decision, not a retry.
  • SmolVLA API pricing: no third-party price exists, so here is the real cost per call and per robot hour — SmolVLA API pricing has no third-party public number to look up. As of 26 October 2026, no marketplace sells hosted SmolVLA access at a published rate. The big model hosts carry none of it. This platform's own row went on the public list that same day, metered per call, its rate rendering on the pricing page. The weights are open and Apache-2.0, so the other real price is a rented GPU by the hour. This page shows every dated check, then works the per-call and per-robot-hour math.
  • Stats missing with pretrained policies: the issue family, decoded — You loaded a pretrained policy, or started a training run, and the library complained about missing statistics. This family is real, old, and fixable. You are not the first. Seven threads in the LeRobot tracker describe it. Two discussions sit on the checkpoint pages. One pull request fixed a piece of it in a day. This page collects the whole family. You get the error strings exactly as they print. You get the four causes behind them. You get the fix each tracker entry proved. You get the habit that keeps the error away.
  • WebSocket stream dropped mid-inference: what the robot loop does next — When a robot policy stream drops mid-inference, the call in flight is already dead. No reply is coming on that socket, and the observation it carried is spent. The loop must treat the next missing action as a deadline expiry. It must hold or halt the arm on the last valid state. Only then may it reconnect, with a fresh handshake, before sending another observation. It must not replay the buffered action chunk after the gap. That rule, plus the exact strings each stack prints and the cause behind each, is this page.
  • Why humanoid forecasts disagree: the 23x spread, computed and decomposed — Two serious research houses have published humanoid shipment forecasts for 2030. Their numbers differ by about 23 times. Omdia said 38,000 units, in July 2024. Goldman Sachs said 890,000 units, in September 2026. Neither number is a typo. This page computes the spread in the open, then explains it. The two houses count different things. They start from different 2025 actuals. They treat China differently. And they build on assumption sets that disagree more than their conclusions do. A fifth factor, forecast vintage, explains as much of the gap as any of the four.
  • Alternatives to Depth Anything: the decision map — If you are weighing Depth Anything against the field, the answer splits by the job. For sharp relative depth from one image, the Depth Anything tiers are still the default. For metric depth in real units, rivals carry the job under cleaner terms. For multi-view geometry and camera pose, VGGT and MapAnything now compete with Depth Anything 3 itself. For depth bought as a hosted per-image call, the shelf is thin. This page maps every row on that shelf.
  • Alternatives to SAM 2 / SAM 2.1: which mask model for which job — The right alternative to SAM 2 depends on which wall you hit. Masks named by plain text moved to SAM 3, and Meta now sells that model per image on its own rate card. Raw speed on a small device belongs to MobileSAM and FastSAM. A fixed class list at camera rate belongs to YOLO. Most of this choice is license law, not benchmark scores. Every license and rate below was read at its source on 28 October 2026.
  • Depth Anything 3 small on a CPU: what runs, and how fast — Depth Anything 3 small is the CPU tier of its family, and the CPU story is now measured. The vendor's packaged phone runtime does one image in 157.8 milliseconds on a single Arm CPU core. A community int8 ONNX build does a run in 0.18 seconds on a Mac CPU. Plain PyTorch on an M1 laptop takes 0.3511 seconds per image. Nobody has published a desktop x86 figure in plain PyTorch. This page shows the searches that came back empty. The install, the code, the memory budget, the fast runtimes, and the hosted lane are below.
  • Depth Anything 3 usage: from pip install to your first depth map — You can watch the demand in Google's suggest box. Type depth anything api and the box finishes your query with the import line, from depth_anything_3.api import DepthAnything3. People paste Python into search because the quickstart lives in a repository, not on a product page. This page is that walkthrough, checked 28 October 2026 against the repository, its API document, and the model cards. It covers the pip route and the clone route, the import that works and the one that fails, the first call, the arrays that come back, the colormap flip, and the errors first calls hit.
  • Depth Anything 3 vs 2: what changed, and which one to run — Depth Anything 3 does not replace Depth Anything 2. It changes the job. V2 reads one image and returns a relative depth map, and it is still the sharper single-image tool on some scenes. DA3 reads any number of images, with or without camera poses, and returns depth, confidence, and camera geometry in one pass. The DA3 paper's own table has DA3 ahead of V2 on three of five monocular benchmarks and behind on two. This page prints that table, the license split, the output flip that breaks migrated code, and the one depth row this platform serves.
  • Depth Anything 3 vs Depth Pro: the metric depth matchup — Depth Anything 3 and Apple Depth Pro are the two names that come up when one image must yield real distances. The one shared benchmark table, printed in the DA3 paper, puts the DA3 metric tier ahead of Depth Pro on all five test sets, read 28 October 2026. Depth Pro keeps two edges that the table never scores. Its boundaries come out sharper, at higher native detail. And it guesses the focal length from the image alone. For business use, the licenses decide first. The DA3 metric tier ships under Apache 2.0. Depth Pro weights are locked to research use.
  • Depth Anything 3 vs VGGT: which depth model to pick — Depth Anything 3 and VGGT are both feed-forward geometry models. The winner depends on the tier you run. The DA3 giant tier beats VGGT on four of five pose benchmarks in the DA3 paper's tables and trails by half a point on the fifth, read 28 October 2026. The DA3 small tier loses to VGGT on pose. It runs about 4.7 times faster. Licenses split both families. The per-tier numbers and the decision rules are below.
  • Depth Anything video/OOM errors: match the string, then pull the right lever — Depth Anything does not leak on video. It runs out of memory because the bill is frames times pixels times tier times dtype, and video multiplies three of those four at once. A single frame at 518 pixels fits nearly any card. Thirty-two of them in one window, on the large tier, in fp32, asks for 26.7 GB on an A100. This page quotes the exact error strings from the publishers' own trackers, names the memory law for each of the three Depth Anything lanes, and orders the four fixes by cost. Every source was read on 28 October 2026.
  • Depth Anything vs MiDaS: the classic baseline and its successor — Depth Anything passed MiDaS, and the field moved with it. MiDaS last shipped a model in December 2022. Its repository was archived in August 2024. One table scores both families under the same protocol. It is the V2 paper's own table. There, the V2 large and giant tiers beat MiDaS v3.1 on relative error across all five test sets. MiDaS still holds two edges. It runs on almost any hardware, from phones to CPU camera feeds. And its code is MIT licensed. This page gives the version history and the pick-by-job rules. It prints the numbers that compare cleanly, and flags the ones that do not.
  • Depth Anything vs MoGe, Marigold, and ZoeDepth: the four-way depth pick — Depth Anything, MoGe, Marigold, and ZoeDepth answer four different depth questions, and the pick follows the question. Depth Anything is the breadth family, fastest at the small tier. MoGe returns a 3D point map, camera field of view, and normals in one pass. Marigold is a repurposed image generator, fine detail at boundaries, slowest per image. ZoeDepth shipped metric depth in 2023 and now sits unmaintained.
  • How to run Molmo 2 locally: the variant map, the hardware, the calls — Molmo 2 is the Allen Institute's open vision-language family released in December 2025. Running it locally takes one modern GPU, or a Mac through community ports, a 20 to 35 GB download, and Python 3.11 or newer. This guide maps the five public variants, the hardware each one needs, the install, the image and video calls, the pointing output format, the dtype choices, and the hosted lane for the embodied reasoning variant on this platform's metered API.
  • Molmo 72B API: no seller prices the 72B tier, so here is the dated census, the token facts, and the sibling lane that is served — There is no priced Molmo 72B API to buy. Checked on 28 October 2026, no marketplace or host publishes a rate for the 72B model of the 2024 Molmo family. The prices that surface in search belong to two other tiers. One is the 7B port on a single host. The other is the newer Molmo 2 base models. This page holds the dated census behind that gap. It gives the 72B facts from the official card and config. It works the token math that the tokens queries ask for. It covers what running the open weights yourself takes. And it names the one lane of this family tree that this platform does serve, molmo2-er, with its live rate.
  • Robot vision API alternatives: who serves what, at which meter — No vendor sells a product named a robot vision API. The perception layer is sold anyway, by six kinds of seller. Their meters differ more than their model lists. Roboflow bills credits per image on routes built for labeling. Replicate bills per run, and its SAM 2 page prints a 42 second typical run. fal bills a media API per request. Meta serves its own segmenter one noun phrase at a time. Open weights split between free downloads and gated requests, and license splits decide the choice as often as speed does. This page maps every row, dated October 28 2026, then names the fit for each robot job.
  • SAM 2.1 automatic mask generation: the exact call, every knob, and the real runtime — Automatic mask generation is the mode where SAM 2.1 masks every object in an image, with no prompt from you. One class in the official repository runs it: `SAM2AutomaticMaskGenerator`. One call does the work. The cost is arithmetic, not money. At the stock settings the class fires 1,024 point prompts per image. A model rated at 64.1 frames per second still takes seconds per image in this mode. This page walks the exact call, every knob with its stock value and its cost, the runtime receipts from named sources, and a hosted lane that runs the same sweep per image. Each source was read on 28 October 2026.
  • SAM 2 memory leak (sam2.utils.misc): the exact errors, causes, fixes, and prevention — The SAM 2 memory leak is not the model leaking. The model's own memory bank is bounded at seven frames. The growth you are watching is Python memory held around the model. It is every video frame preloaded by sam2/utils/misc.py, every per-frame tracking output kept in the inference state, and the GPU allocator's cache, which only looks like a leak. This page quotes the exact error strings. It names each retention layer from the repository's own code and orders the fixes by failure class. Every source was read on 28 October 2026.
  • Is SAM 2 thread safe? The answer per component, from the repository's own code — No single answer covers SAM 2, because SAM 2 is several surfaces, not one object. Sharing one image predictor, or one automatic mask generator, across threads is not safe, because both hold mutable state on the object itself. The video predictor keeps its state in a per-video dictionary, and the demo Meta ships wraps every model call in one lock. Underneath, the PyTorch model is safe to read from many threads and unsafe the moment something writes to it. This page maps each part, quotes the exact error strings, and names the pattern that fits each one. Each source on this page was read on 28 October 2026.
  • SAM 2 vs SAM 2.1: what changed, what did not, and the upgrade call — SAM 2.1 is SAM 2 retrained, not a new model. The four size tiers keep their parameter counts and their speed. Video scores move: up to 3.5 J&F points on SA-V test, at the one published protocol. The API surface does not change, and the license stays Apache 2.0. The upgrade is new checkpoint files plus four config lines, not a rewrite. This page carries the delta table, the upgrade mechanics, and the version decision, with every source read on 28 October 2026.
  • SAM 2 vs YOLO: masks or boxes, the real decision — SAM 2 and YOLO answer two different robot vision questions. YOLO is a detector trained on your classes. It draws labeled boxes, fast, on modest hardware. SAM 2 is a promptable mask maker. It traces any object you point at, pixel by pixel, with no training, at a higher compute cost. This page maps that boundary. It names the benchmark basis on every number. It shows the pipeline where a robot stack runs both.
  • The SAM 2 mask generator is not thread-safe: the crash we measured, the cause in the code, and the two fixes — The SAM 2 automatic mask generator is not thread-safe, and the crash has an exact shape. One generator owns one private image predictor. Every generate call rewrites that predictor's inner state, then reads it back. Two generate calls racing on one generator corrupt that state. In our wave of 26 requests on 2026-10-05, five died on the same line: TypeError, 'NoneType' object is not subscriptable, inside automatic_mask_generator._process_crop. Nineteen came back clean. Two were turned away by the queue. This page carries the receipts: the code that makes the generator unsafe, the lock that fixed it and what it cost, and the pool that replaced the lock one day later. Every source was read on 28 October 2026.
  • The SAM 2 predictor pool: two generators, one model, double the ceiling — A SAM 2 predictor pool is a fixed set of mask generators over one shared model. Each request borrows a generator, runs its generate call alone, and returns the generator to the pool. We have served this way since 2026-10-06 with a pool of two. Two requests at once finish in 2.228 seconds, against 1.502 seconds for one alone. The 26-request burst runs with zero failures. Weights and steady video memory stay at one model's cost. This page gives the design, the receipts, and the recipe. It also names the cases where a single lane still wins. Every source was read on 28 October 2026.
  • Video Depth Anything: from video file to depth, frame by frame — Video Depth Anything turns one video file into a depth value for every frame. This page walks the whole path: what the model takes, the exact call, how to read the outputs, and how to make it fast. The model reads clips in windows of 32 frames with a 10-frame overlap, runs in fp16 by default, and its small tier is 28.4M params under an Apache 2.0 license. On the hosted side, video depth becomes frames: you extract them, send them as image parts, and the bill is the frame count times the per-image rate.
  • VLM vs VLA for robot control: the two-tier answer — A VLM cannot drive your motors. A VLA can. That one line settles most of the VLM versus VLA question for robot control. Both model classes read the same camera frames and the same words. One answers in text, and the other answers in motion. The useful question is not which model is better. It is which tier does which job, at what rate, and on which meter. This page gives the two-tier answer with the papers' own numbers, maps the hybrid pattern that production stacks run, and shows both tiers served over one API, dated 28 October 2026.
  • What is a VLM in robotics: the definition, the parts, the VLA line — A VLM is a vision language model: a network that reads images and text together and writes text back. That last word carries the whole robotics story. A VLM can describe a bin, point at a part, or write the next step of a plan. It cannot command a motor, because its only output is words. This page defines the class from its three parts, traces the 2021 to 2023 lineage that named it, draws the exact line where a VLM becomes a VLA, and lists the VLM-class rows on this platform's public model list, dated 28 October 2026.

Guides: cost

  • How to avoid API bill shock: caps, alerts, and prepaid wallets — API bill shock is what happens when usage-based charges run ahead of you. A leaked key, a retry loop, or a swarm of agent calls spends money faster than you notice. The invoice arrives before the warning does. This guide breaks down the five ways bills blow up. It compares the spend controls the major API providers actually ship. And it shows how a prepaid wallet turns the worst case into a top-up instead of a debt.
  • How to avoid OpenAI bill shock: hard caps that hold — OpenAI has no control that stops a bill in real time. It has three that bound it. One is an opt-in hard spend limit that fails requests with a named 429 error. One is a prepaid credit balance with auto-reload turned off. One is a wallet-shaped account where the worst case is the balance itself. Each of the three has a delay, in OpenAI's own words. This page checks every control against OpenAI's docs today, works the worst-case math, and puts the documented cases next to the controls that would have stopped them.
  • Robot fine-tune and eval product math: the 2.08 loop — A packaged robot policy product has two legs. Train the policy, then prove it with a counted evaluation report. The measured loop cost 2.08 to produce in October 2026: 0.1497 to train a pi 0.5 class policy for 15,000 steps, and 1.9344 for the 500-episode LIBERO report. Both ran at 0.041 per card-hour on rented 24 GB cards. The written charge band for such a report is 15 to 40. The whole loop sits at 7.6 percent of that band's midpoint, and at 13.9 percent of its floor. No vendor publishes a price for the loop. Every public bill prices training alone. This page shows the full arithmetic in static tables you can check with a pencil.
  • The hobbyist robot compute budget: what a cheap robot brain really costs — A real hobby robot budget has three viable shapes in October 2026. Use the 12 GB card you already own, and the light policies train on it today. Buy a used 12 GB desktop card, about 295 in current eBay sold data, and add about 230 in parts for the leader and follower arm pair. Or rent by the hour from 0.015 per GPU-hour, which lands near 29 per month even if you ran a card nonstop. The famous 5,499 robot brain is real, but it is not where hobbyists start.
  • MoE models on consumer GPUs: the A3B lane, worked in the open — A 35B-A3B model stores about 35 billion parameters in memory but computes through only about 3 billion per token. Memory bills the total. Speed bills the active slice. That split is why this class of sparse model runs on one 24 GB consumer card. A dense model of similar reach cannot match its speed on the same silicon. Measured receipts put the class at 104 tokens per second on a 32 GB AMD card in our August 2026 runs. A tuned RTX 3090 reached 157.66 in an owner-run benchmark updated October 2026. A September 2026 one-card study prices the lane's break-even at 4.3 percent of a card's day.
  • What is a per-robot-hour? The pricing unit, defined — A per-robot-hour is one robot working for one hour, used as a unit of price. For hosted robot inference it is the honest unit. An hour of robot work converts, by pure arithmetic, into a known count of calls. Any per-call rate then turns into an hourly figure you can check. The same words also price other things. They price a wear counter on a used arm, a whole machine spread over its life, and a worker's replacement sold as a service. This page defines the unit, separates those senses, shows the conversion from hours to calls, and maps which vendors bill which unit today.
  • Robot evaluation cost: the 1.93 per 500-episode report — A 500-episode LIBERO evaluation cost 1.93 in compute and 47.18 hours of wall time on one rented 24 GB card. This page shows every input: the rate basis, the episode clock, the restarts, and the report it bought, 482 successes out of 500. The money query has no other answer in search today. Every ranking page is a how-to, a protocol paper, or a raw card price. The measurement record is ours, dated 2026-10-10, and the arithmetic below re-runs with a pencil.
  • Robot inference cost per robot-hour: the 6.48 derivation — Robot policy inference costs 6.48 per robot-hour on this platform's fully shown basis: 2,160 calls per robot hour at the written-record per-call rate for the pi05 model. Every input is named and dated below. The figures circulating elsewhere, from 2 to 35 per hour, price different things: whole robots, data factories, labor parity. None derives the inference slice. This page does the arithmetic in the open, in static tables you can re-run on your own loop.
  • Robot startup infrastructure cost: the real monthly ladder — A robotics startup can run its inference infrastructure for about 3 a month at the bottom of the ladder. At the top, the same five robots and the same workload cost about 2,300 a month. The rung decides the bill: community cloud card hours, on-demand pods, reserved contracts, an onboard computer bought once per robot, or a hosted robot route. Every rate below is named, dated, and worked in the open, as of October 2026. The pages ranking for this query price the office and the printers. This page prices the compute.
  • The robotics OEM compute decision: build, buy, and the edge-first law — No leading robotics OEM rents the brain it deploys. Figure runs every inference tier onboard its robots, and it buys training compute by the billion. 1X trains its models in the cloud. It ships a Jetson module on each robot. Tesla builds its own inference silicon. The build versus buy question at OEM scale is really three questions. The deployment brain is bought as silicon. It goes on the robot. The training compute is bought from cloud owners. Per call hosted routes serve the programs below this scale. The record, the prices, and the arithmetic follow.
  • RTX 3060 budget inference economics: the 12 GB card, measured — The RTX 3060 12 GB is the lowest-cost 12 GB entry into local model inference. This page prices its hours instead of its frame rates. A 3060-class hour rents from 0.015 at the lowest community tier to about 0.04 at the tier real work runs at. At the October 2026 used price of about 300, the card pays for itself in about 10 months of always-on rental. What fits in 12 GB, how fast it runs, and what a month of paid work covers. All of it sits below in dated tables.
  • RTX 3090 inference economics: the account-rate correction — An RTX 3090 rents for 0.041 per hour on our account at the community cloud batch tier. The published list floor for the same card read 0.090 per hour on 26 October 2026. That gap is the rate correction this page documents, with every input named and dated. The used 3090 is still the price-performance king of its class on the speed axis: 24 GB at 936 GB/s for hundreds, not thousands. But at the account rate, renting an hour costs less than the electricity one burns under your desk. Buy the card for control, privacy, and fit. Do not buy it to save rental money.
  • VLA API pricing: per call vs per robot hour, converted — Robot APIs price their work in two units. Per call is one request that returns a chunk of actions. Per robot hour is the cost of one robot working one hour. The two are not rivals. Your control loop converts one into the other by plain math. At the SO-arm convention of 30 frames per second with chunks of 50, one robot hour holds 2,160 calls, so any per-call rate times 2,160 is an hourly cost. Per-action meters ride 108,000 actions an hour. This page defines both units, works the conversion in the open, converts every dated market rate into robot hours, and shows one seller's price list in both units at once.
  • FLUX local vs API: the break-even in images per day — Running FLUX yourself and buying FLUX images cross at one daily volume. This page computes it. The inputs are dated: which FLUX weights you may run at home, what a card costs, what power it draws, and what hosted rates print per image. The answer lands in images per day.
  • Image generation cost calculator: renders, keepers, and your own GPU — Image generation API cost is three bills wearing one word. One is a flat rate per image. Another is a rate per megapixel that rounds up. The third is a rate per token, and you cannot divide it by hand. First-hand reads on this page are dated 28 October 2026. The cheap tier of the FLUX family bills 0.003 per image, and the pro tier bills 0.04. That is a factor of thirteen. The next multiplier is you. At a 25 percent acceptance rate you buy four renders per keeper, so a 0.003 draft tier really costs 0.012 per image you keep. Your own card is the last surprise. Local power is noise. But a 1,599 card needs over half a million images to pay back against the cheap tier. This page works all of it in static tables. Every input is named and dated. There is no widget and no JavaScript. You can check every number with a pencil.
  • Specialty-API unit economics: embeddings, rerank, OCR — Specialty APIs do not share a billing unit. Embeddings bill by the million tokens. Rerank bills by the search. OCR and classification bill by the page. Speech bills by the second, voices by the character, image routes by the image. A rate means nothing until you know the meter behind it. The pages ranking today compare rates inside one lane. None compares the meters across lanes. This page maps every unit this platform's specialty routes meter. It converts each shape into the others. It prints every competitor rate as a dated relation against the fenced rates below, never as a bare figure. Every read happened on 28 October 2026.

Guides: parsing & classification

  • Merged cell PDF table extraction: why tools fail — Merged cells are the part of PDF table extraction that open-source tools have declined to solve. pdfplumber returns None cells. PyMuPDF duplicates values and invents column names. Camelot recovers some merged headers and produces phantom columns elsewhere. And the feature requests have sat open for years. This guide shows each failure on a test table you can rebuild with one script, using outputs captured from the real tools. It then walks the routes that work. Those are the text-versus-scanned fork, the repair step and the values it silently fabricates, and the Excel conversion paths. The last leg is the per-page economics of repairing it yourself versus routing documents to a parsing service.
  • PDF to markdown for RAG: the parser showdown — The reliable way to turn a PDF corpus into RAG input is to convert to markdown first, then chunk the markdown by its headings. This guide shows that path with the artifacts intact. It runs a three-page test PDF through three local parsers, with every output quoted verbatim. It carries a comparison table with dated cost per page from official rate cards. It gives you a runnable retrieval check that scores each parsing choice against a fixed question set. And it draws a clear line for when running your own parsing stack stops paying.
  • IAB content taxonomy migration 2.x to 3.1, without the weeks — Migrating a corpus from IAB Content Taxonomy 2.x to 3.1 is a real project, not a relabel. Version 3.0 deleted parent categories and restructured the file. This guide walks the whole jump. It covers what changed between the official files. It shows where specific codes moved. It gives the honest timeline ladder: weeks by hand, minutes with the free local mapper, or one call at scale. And it lists the planning steps no tool runs for you.
  • Jev decision models explained: the open-weight class — A Jev decision model is a model you call for a typed decision. A state and a fixed-shape question go in. A chosen option, a probability of yes, or a level on a scale you defined comes back with calibrated confidence. No prose comes out. This guide defines the class. It tells the provenance story straight. It maps the three routes the open models take. It reads the benchmark record honestly, including the sealed-question gap. It gives the self-host and adapter paths. The spine is the provenance. A closed-weight original made the class visible in September 2026. An open-weight family answered within days. The three platform lanes named here belong to that family and serve today.
  • The best embedding models for RAG in 2026, ranked on dated evidence — The best embedding model for RAG in 2026 turns on one axis most lists bury. Can the weights run on your own hardware, or not? NVIDIA's Nemotron 3 Embed 8B, released 16 July 2026, leads the retrieval-focused RTEB board at 78.5 percent. Qwen3-Embedding-8B has held 70.58 on multilingual MTEB since June 2025. Gemini Embedding 2 posts 69.9 on its publisher's page. It also reads images, video, audio, and documents. This page ranks ten models on scores read at their sources on 28 October 2026. The ranking rules come first, then the table. Every row pairs with its local or hosted reality. This platform serves two rows, bge-m3 and wemm-embed. Both sit inside the field at the position their evidence supports.
  • bge-m3 vs OpenAI text-embedding-3: which embedding model, and why — Neither model sweeps this question. OpenAI's text-embedding-3 pair is the closed pick: no downloadable weights, official dimension shortening, one vendor. bge-m3 is the open pick: MIT weights, 100+ languages, three retrieval outputs from one pass, and it runs on your GPU or a hosted route. Cost does not break the tie. Control does.
  • Cross-encoder vs bi-encoder: the two retrieval architectures that divide search work — A bi-encoder turns a query and each document into separate vectors. Comparing them is cheap, so it owns first-stage search over large corpora. A cross-encoder reads the query and one document together and scores the pair in one pass. It is more precise and far slower. Real search systems use both, in turn.
  • Embedding API pricing, line by line: the units, the tiers, and the dimension bill — Every big embedding provider bills by the token, and every rate card looks comparable. It is not. Three things separate the bills. First, the unit each card counts. Second, the batch tier three providers hide in plain sight. Third, the dimension bill no rate card shows at all. This page re-read the providers' own pages on 28 October 2026. Each row prints as a dated relation, never a bare figure. One worked corpus gets priced twice, once for the API and once for storage. The young marketplace route class, which no ranking comparison prices, gets mapped too. This platform's embeddings route serves two rows: bge-m3 for text and wemm-embed for multimodal work. Both meter per token against a prepaid wallet.
  • Embedding dimensions and context length, model by model — Every embedding model carries two numbers you live with for years. One is the width of the vector. The other is the window of text it reads per call. Width sets your storage bill for the life of the index. The window sets how you chunk. This page holds both numbers in one table, read from each provider's own pages on 28 October 2026. Sixteen rows cover the two models this platform serves, the big hosted providers, the open Qwen3 family, and Mistral. Every cell is dated and sourced at the provider's own surface, and the log holds each attempt chain. Two decisions follow the table: which width to store at, and whether to chunk or read whole.
  • Embeddings local vs API: when your own GPU beats the per-token bill — An open embedding model on your own GPU and the same weights behind a metered API cost the same at one daily token volume. This page finds that point for bge-m3. The inputs are the platform's measured lane grid from 28 August 2026, plus October 2026 street prices for two used cards. Maker watt specs and the official United States power price finish the set. The answer lands in tokens per day, and in one number most guides skip: how busy the card must stay before its own power costs less than the rate.
  • GLiNER zero-shot NER or an LLM: which extractor, and when — GLiNER and an LLM solve two different jobs. GLiNER is a small encoder that types spans against any label list you pass at request time. One text is one flat metered unit. The answer is spans with positions, not prose. An LLM extraction is a writing job. It gives you free schemas and role-aware fields, and a token bill that scales with your prompt and its answer. The 2023 claim that GLiNER beats ChatGPT is real, dated, and narrower than the blogs repeat it. This page re-dates the evidence, prices 1,000 extractions on both sides, and maps the version line the search box keeps asking about.
  • IAB content classification: dedicated classifier or LLM prompt — A dedicated IAB classifier and an LLM prompt make the same thing, a code on a page. They get there by opposite means. The classifier answers from a closed label set, bills per page, and cannot invent a category. The LLM writes its answer, takes any instruction, and can label outside the taxonomy. That is flexibility and risk at once. The quality evidence runs both ways. Every number in this market sits on model judged labels. This page prints the two public head-to-heads with owners and dates. It prices both unit shapes. It ends with the decision table.
  • VLM vs OCR API: how to choose, document class by document class — Neither path wins this question outright. A traditional OCR API reads exactly what is printed, bills a fixed rate per page, and tops the tables on clean machine-printed forms. A VLM reads layouts and tables that zoning engines break on, and it can also invent text that is not on the page. The deciding variable is the page class in front of you, not the vendor.
  • Reranker API pricing, unit by unit, with the latency nobody prints — Reranker APIs do not share a pricing model. Some bill by the search. Some bill by the token. Some are free up to a rate limit, and some rent you an instance by the hour. So two rate cards can differ by a unit rule alone, and a page of prices without units cannot answer your question. This page fixes that. It re-read every vendor's own pricing surface on 28 October 2026. It pulls the billable unit rule from each. It states every competitor rate as a dated relation to a flat per-search rate, never as a number. And it gives you latency figures with their dates. This platform serves one reranker, bge-reranker-v2-m3, at a flat rule: one request is one metered search, whatever the document count.
  • Reranker vs embeddings retrieval: when the second stage pays for itself — Embeddings search a whole corpus fast, and their cost is mostly paid once at indexing. A reranker reads each candidate next to the query and orders the shortlist far better. It adds a serial hop to every request. Neither one replaces the other. The real decision is whether your pipeline needs the second stage. That turns on corpus size, precision need, latency budget, and one break-even sum.

API reference