Most inference providers compete on price or on model quality. This one competes on speed, and the reason to pay attention is that the speed difference is not marginal. We are talking about token generation fast enough that the experience of using an application changes character. A response that streams over eight seconds and a response that lands in under one are not the same product, even if the text is identical.
Once you have felt that difference you start reconsidering things you had written off. Multi-step agent chains where each step was previously a visible pause become usable. Speculative work, where you fire off three approaches and keep the best, becomes affordable in time as well as money. Interactive tools that re-run on every keystroke become possible.
The documentation does not really make this argument, and I think it should, because the strategic implication of the speed is more interesting than the number itself. What the documentation does well is get out of your way. It is short. The quickstart works.
The API surface is small and mostly familiar, because it deliberately mirrors an interface everyone already knows. There is no conceptual preamble about the philosophy of the platform, no lengthy architecture diagram, just what you need to make a request and what the parameters do. After reading a lot of vendor documentation, brevity is a real virtue and this has it. The OpenAI compatibility is worth more than it sounds.
It means every client library, every framework integration, every piece of code you have already written against that interface works here with a configuration change. That is the difference between an evaluation you can run this afternoon and one you schedule for next sprint. The free tier is genuinely useful rather than a tasting menu. You can build something and let people use it before you pay anything, which for prototyping and for personal projects is exactly right.
The cookbook material is decent, with worked examples covering tool use, structured output and streaming, and the examples run rather than being illustrative fragments. Now for the parts that need more honesty. The model catalogue is entirely open weight models, and the documentation is very comfortable telling you how fast they are and much less comfortable discussing where they sit relative to the strongest closed models. For plenty of tasks that gap does not matter, and for some it matters a great deal, and a developer reading these docs is not given the tools to tell which situation they are in.
The implied message is that speed is the axis that matters. Sometimes it is. Sometimes you have picked a model that is three times faster and meaningfully worse at the reasoning your application depends on, and you will find out from users rather than from documentation. Model deprecation is the practical operational complaint.
Models appear, models are retired, and the notice period has been shorter than teams running production systems would like. There is a deprecations page and the honest position is that building on a specific model here carries more churn risk than the documentation communicates. If you adopt this, abstract the model choice behind your own configuration and expect to change it. The rate limits on the free tier are fine for a single developer and become a wall the moment you do anything concurrent.
This is entirely reasonable commercially and it is worth knowing before you design a load test around it. The limits are documented, and the documentation could be clearer that the free tier is for building rather than for measuring throughput. What is missing conceptually is any explanation of why the offering has the shape it has. This runs on custom silicon with particular memory characteristics, and those characteristics are why the model menu looks the way it does, why very large models are harder to serve here, and why speed comes so cheaply on the models that do fit.
That is genuinely interesting engineering and understanding it would help a developer predict what will and will not be available in future. The documentation treats the hardware as an implementation detail, which is a missed opportunity for a company whose entire differentiation is the hardware. There is also nothing on the strategy question that any serious team should ask, which is whether you route different requests to different providers based on what each request needs. In practice the right architecture for many applications is a fast cheap model for the easy majority and something stronger for the hard minority, and no single vendor's documentation will ever tell you that.
Worth knowing that the gap exists. My three point eight is for a service that does one thing exceptionally well, documented briefly and clearly, with a compatible interface, a genuinely usable free tier and worked examples that run. Marked down for soft-pedalling the model quality question, for deprecation churn, and for skipping the hardware story that would actually help readers reason about the platform's future. If your bottleneck is latency, start here.