Glimpse vs Kolibri: Two Ways to Buy More Compute per Token

E​lorian G​limpse and K​olibri are two answers to the same economic question — how do you get more capability per unit of compute — and they sit at opposite ends of it. G​limpse, released by E​lorian on 16 October 2026, buys its capability at inference time: it runs a first pass over a clip at roughly 8 frames per second, then spends extra compute re-scanning a chosen nine-tenths of a second at around 14 frames per second before it answers. K​olibri, released by A​leph Alpha on 3 October 2026, buys its capability at architecture time: 78.1 billion total parameters of which only about 3.46 billion are active per token, so almost every parameter in the model is one you never pay to evaluate.

The two are not interchangeable, and the reason is not quality. One is a hosted preview with no weights, no published parameter count and no published context window. The other is an Apache 2.0 download whose model card names its expert count, its attention schedule, its numeric formats, its tokenizer's language coverage and the exact electricity bill of its training run. Comparing them is really a comparison of two strategies, and the interesting question is which strategy survives contact with your workload.

A 22-to-1 ratio against a ratio nobody published

K​olibri is a sparse mixture-of-experts model, and the sparsity is extreme even by current standards. Fifty layers, every one of them a mixture of experts, 384 experts per layer, of which one is shared and six are routed. That works out to a total-to-active ratio of roughly 22.6 to 1 — a model that carries 78 billion parameters but evaluates about 3.5 billion of them on any given token. A​leph Alpha alternates that in a 4-to-1 pattern against group-query attention blocks, which is what keeps the 262,144-token native context affordable: a million-token path is validated, and the KV cache is held in FP8 to make the long end of that window fit in memory rather than in a spreadsheet.

The numeric-format choices are disclosed to a degree that is unusual. Weights are FP8 in 128-by-128 blocks. The KV cache is FP8. Embeddings, the language-model head, the normalisation layers and the router stay in bfloat16 — the parts where quantisation damage would show up in routing decisions rather than in losses. Four effort levels are exposed. Tool calling follows the Hermes format with a vLLM parser, which means it slots into an existing agent stack rather than requiring a bespoke integration.

G​limpse publishes none of that. No parameter count. No expert structure to speak of, no context window, no quantisation scheme, no named base model — only the phrase "post-trained on an open-weights base model," which does not say which one. What it publishes instead is the trace: a first pass at roughly 8 frames per second, a tentative reading, a return to 0.9 seconds of the clip at around 14 frames per second, and in a second example a window edge tracked from about 2.2 seconds into a clip until it nearly stops at 5.13 seconds.

Both of those are disclosures about compute. K​olibri's is a statement about where the compute goes when the model loads. G​limpse's is a statement about where the compute goes while the model thinks. Only one of them comes with a number.

The published sheets, side by side

• Size — K​olibri: 78,103,074,560 total parameters, 3,457,573,120 active. G​limpse: not published, with "substantially smaller and cheaper than the frontier systems it benchmarks against" as the only size statement E​lorian makes.

• Access — Apache 2.0 weights for K​olibri, downloadable and self-hostable. None for G​limpse, which is API and chat only with a free sign-up.

• Context — 262,144 tokens native for K​olibri, with 1,048,576 validated. Not published for G​limpse, which is the more awkward blank because its headline capability is reading video.

• Languages — German and English for K​olibri, which A​leph Alpha presents as a design decision rather than a limitation. G​limpse publishes no language coverage at all.

• Price — $0.60 per million input tokens and $3.00 per million output for G​limpse — and the mechanism means output tokens are where the re-scan shows up, so the trace is the receipt. K​olibri has no rate card, because the cost is the hardware.

• Independent evaluation — effectively none for either. Neither has a third-party harness reproducing its numbers, and both sets of published figures are the vendor's own.

The training run A​leph Alpha published in full

This is where K​olibri diverges from almost every release of the year, and it is worth going through because it tells you what the sparsity cost to build.

The pre-training corpus was 20 trillion tokens, split roughly 62.5% English, 23.9% German and 13.6% code. Mid-training added 3.44 trillion more, and a long-context stage contributed 201 billion. The run used 768 N​VIDIA B200 accelerators across 96 HGX nodes, took 21 days and 511 hours of wall clock, and consumed about 392,000 GPU-hours — 6.4×10²³ floating-point operations, on an energy budget of roughly 9.5×10² megawatt-hours.

Those numbers are the honest price of a 3.46-billion-active model that behaves like something much larger. They are also unrepeatable for anyone outside a well-funded lab, and that is precisely the argument for open weights: the training cost is paid once by the company that publishes the card, and everyone downstream gets the artefact for the price of the download.

The predecessor is instructive. K​olibri Origin was 30.6 billion parameters with 3.27 billion active, a 65,536-token context and 7.51 trillion training tokens — and it was never released. The published model is not a first attempt; it is the second, and the gap between them is roughly the gap between a prototype and a product.

Nothing comparable exists for G​limpse. E​lorian says only that the model was post-trained by a small team with a few hundred GPUs. There is no base model named, no token count, no data description, no compute disclosure. That is a legitimate difference between publishing a checkpoint and shipping an endpoint — you disclose what you hand over — but it means the two releases cannot be compared on economics beyond the rate card, because only one of them published its costs.

The empty parameter-count cell

Here is the trap in this comparison, and it runs in G​limpse's direction.

It is easy to read K​olibri's 3.46 billion active parameters and conclude that G​limpse — hosted, cheap per token, aimed at a narrow capability — must be small, or must be cheap to run, or must be a fine-tune of something modest. None of that follows. G​limpse's parameter count has never been published. Its context window has never been published. Its base model has never been named. The only size claim in the launch post is comparative and unquantified. Where behaviour does not disclose size, and this model's behaviour is a sampling schedule rather than an architecture, the parameter count could be almost anything and nothing published would contradict it.

So the parameter-count cell stays empty, and any figure anyone quotes for G​limpse's size this month is an estimate dressed as a specification. The same is true in the other direction, incidentally: K​olibri's 22.6-to-1 ratio does not tell you its inference cost on your hardware, because FP8 weights in 128-by-128 blocks need specific accelerator support to be a win rather than a conversion step.

What each strategy fails at

K​olibri's constraint is language coverage, and it is deliberate. German and English, nothing else. For a European enterprise with German-language traffic that is a feature — the training mix is weighted toward a language most open models treat as a rounding error. For anyone else it is a hard no, and no amount of context window compensates.

Its second constraint is the long-context arithmetic. A million-token path is validated, which is genuinely large. But a validated path is not the same as an undegraded one; at these lengths almost every model's retrieval accuracy falls off long before the window ends, and no published evaluation says where K​olibri's curve bends. Treat the window as capacity you can allocate rather than accuracy you can assume.

G​limpse's constraint is the opposite shape: a narrow capability with nothing around it. If the question is what happened inside a fraction of a second of footage, G​limpse is aimed directly at it. If the question is what a scene implies rather than what it states, the rewind does not help — on Humanity's Sixth Sense, the benchmark E​lorian published with Scale AI nine days before the model shipped, G​limpse scores 46.36 against GPT-6 Astra's 53.6, and the benchmark's own failure analysis attributes 94% of labelled errors to seeing and inferring rather than to reasoning. More looking is not more understanding, and the vendor's own table is the evidence.

There is also a class of problem neither addresses: the one where the answer has to be a threshold. G​limpse writes prose. K​olibri reads and writes. Neither is built to return a calibrated number per option, and if that is what the pipeline needs, the instrument is a different shape of model entirely.

Where a routing layer earns its place — and where it does not

The two models sit on either side of a boundary that routing can move and one it cannot.

The boundary it moves is the cost and resilience of mixing lanes. A team running K​olibri on its own accelerators for German-language traffic and a hosted model for everything else has two code paths, two failure modes and two sets of credentials. OrcaRouter collapses that to one key in front of 200-plus models, with a routing DSL that decides which request goes to which lane and automatic failover that keeps a request alive when the self-hosted lane is saturated or down. Provider list prices are passed through with nothing added per token, so the hosted half of that mix costs what its vendor charges and follows that vendor's price the day it changes.

The boundary it does not move is custody, and here K​olibri has an advantage no routing layer can manufacture. Its weights are downloadable. If the corpus cannot leave the building, an Apache 2.0 checkpoint is the only one of these two that runs where the data lives, and no evaluation of either model changes that. Nor is either model on our catalogue — K​olibri is a download and G​limpse is E​lorian's own API and chat interface — so this is a statement about how we route, not a claim to serve them.

How to decide without a shared benchmark

There is no scoreboard that ranks these two, and it is not because one of them is new. E​lorian's table measures video and image perception against GPT-6 Astra; A​leph Alpha's card measures the usual academic spread plus long-context retrieval. They share no task, so the only comparison that matters is against your own workload.

Three questions settle it faster than any table.

Does the data have to stay on hardware you control? If yes, K​olibri is the only candidate here, the licence is Apache 2.0, and the German-English coverage either fits your deployment or rules it out immediately.

Is the failure mode temporal — object identity across an occlusion, a pan versus a cut, an event inside a sub-second window? If yes, G​limpse is the only model of the two whose stated mechanism addresses it, the free sign-up makes the trial cheap, and the trace tells you more than the score: run your own clips and check whether the model ever went back to the interval that decided the answer.

Is the workload long-context but not long-video — a document corpus, a filing set, an audit trail? If yes, K​olibri's 262,144-token native window with a validated million-token path is the relevant number, and neither model's published evaluation settles whether it survives the degradation curve at those lengths. That one has to be measured, on your data, before either decision is safe.

The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.