We Added Qwen3.8-Max to Our OpenAI-Compatible API — What Would Make You Actually Try It?
Hey Indie Hackers,
We’ve added Qwen3.8-Max to AIMOWAY’s OpenAI-compatible API.
For indie builders working on AI products, the practical appeal is straightforward: the model can be tested through the same API key and /v1 endpoint used for the rest of the AIMOWAY catalog, without adopting another provider-specific SDK.
Current AIMOWAY pricing per 1M tokens:
• Input: $1.90
• Output: $5.70
• Cached input: $0.239
Model ID:
Qwen3.8-Max
We’re especially interested in how indie builders evaluate a newer API provider.
Before you would test one in a real project, which evidence matters most?
• Latency by region
• Tool-calling reliability
• Long-context performance
• Uptime and failure handling
• Data-handling policies
• Reproducible cost and quality comparisons
Pricing:
https://aimoway.com/pricing
Documentation:
https://aimoway.com/docs
Disclosure: I’m building AIMOWAY. This post is a product update, but I’d genuinely value feedback on what technical proof would make the service worth evaluating.
I tried to verify the announcement against the public docs before testing it, and found two gaps. Qwen3.8-Max does not appear in the current model catalog, which lists Qwen3.6 and 3.7 variants, and the API reference does not document tools, tool_choice, or streamed tool_calls even though tool-calling reliability is one of the evidence options in your post.
For a new provider, I'd value a versioned capability matrix more than another headline benchmark: exact model ID, upstream/version, context limit, supported parameters, tool/streaming semantics, known incompatibilities, and deprecation policy. A small public contract-test suite for invalid tool arguments, 429/5xx responses, and interrupted streams would make that evidence reproducible.
Is the catalog lagging the rollout, or is Qwen3.8-Max currently limited to selected accounts?
AI-assisted draft, reviewed and verified against the public documentation.
Thanks for checking this against the public docs so carefully. This is exactly the kind of feedback we were hoping to get.
The model-catalog gap you found has since been addressed: Qwen3.8-Max is now listed in the public model catalog with its current pricing and description.
Your broader point is more important, though. A versioned capability matrix covering model IDs, context limits, supported parameters, tool/streaming behavior, known incompatibilities, and deprecation status would make evaluation much more concrete. The same is true for reproducible contract tests around failure cases and interrupted streams.
I don't want to claim that those documentation gaps are solved before we've actually verified them, but this is very useful input for what technical evidence a new provider needs to expose publicly.
I prefer trying out the reliability of an API as it’s what matters more to me than a model list.
If I am thinking of leaving my service provider, I would want to know the request failure rate, the consistency of the latency and how it performs if something goes wrong. When you run a real product, those things become more important than benchmark numbers.
I would be eager to see how it performs over a few weeks and not just on day one.
That's a fair standard, and I think we should be transparent about where we are today.
Our upstream model service comes from a substantial high-performance computing provider in China, with authorized access arrangements for the models it serves. The underlying service is already used across software services, academic research, and commercial workloads, so we have a solid upstream foundation to build on.
At the same time, I don't want to turn that into an AIMOWAY reliability claim that we haven't measured long enough ourselves.
AIMOWAY has only recently started operating in the North American market, so we don't yet have enough long-running production data to publish failure-rate, P95/P99 latency, or uptime figures that I would consider statistically meaningful.
There is also a regional tradeoff worth being explicit about: the serving infrastructure is not located in North America, so we don't expect to match the lowest latency of providers serving from local North American regions, particularly for latency-sensitive interactive workloads.
What we do want to build toward is exactly the kind of evidence you mentioned: measured failure rates, latency consistency over time, behavior under concurrency, and clear reporting of what happens when the upstream service or network has a problem.
I'd rather publish those numbers once we have enough real operating history than put out an impressive-looking benchmark from a short test window.
Adding a new model is exciting, but I think the bigger challenge for API providers is reducing the “risk” feeling for developers.
Most builders aren’t only asking:
“Is this model powerful?”
They’re also asking:
“Will it be reliable when my users depend on it?”
Things like transparent benchmarks, real latency examples, failure handling, and clear documentation can often build more confidence than just announcing another model.
The technical proof is what turns curiosity into someone actually integrating it into a product.
how AIMOWAY approaches developer trust as the catalog grows.
I agree. For a new provider, I think reducing that sense of risk requires being very clear about both what is already solid and what still needs to be demonstrated.
Our upstream model service comes from a substantial high-performance computing provider in China, operating under authorized arrangements for the models it serves. The underlying service already supports software providers, academic research teams, and commercial workloads, so there is a real production foundation behind the model access. Where appropriate, we can also provide supporting information about that background and authorization.
But AIMOWAY itself is still new in the North American market, and I don't think it would be responsible to turn that upstream foundation into claims about AIMOWAY's own long-term reliability before we have enough operating history.
We also want to be transparent about geography: the serving infrastructure is not located in North America, so ultra-low regional latency is not something we should pretend is our strongest advantage.
What I think we need to make increasingly visible is the evidence developers can inspect themselves: model capabilities, tool and streaming behavior, regional latency over time, failure handling, concurrency behavior, data-handling policies, and eventually meaningful uptime and incident history.
That kind of evidence seems much more useful for building trust than simply saying that a provider is reliable.
One thing I’d watch here is the gap between “we’re being transparent” and “the buyer can quickly understand what that transparency means for their decision.”
You’ve actually got several strong trust signals in this post — infrastructure background, geographic limitations, what you can and can’t claim yet, and the evidence you plan to expose.
But they’re competing for attention.
I’d turn those into a simple decision path for the developer:
What can I trust today? → What still needs proving? → What evidence can I inspect? → What would make me comfortable running a real workload?
That distinction matters because technical buyers don't necessarily need more information. They need the information organized around the risk they’re trying to eliminate.
For an API provider, the strongest copy may ultimately be less about “here’s what we offer” and more about “here’s how you can verify whether we're safe to depend on.”
That’s the kind of positioning I’d test before adding more claims or features to the page.
The interesting part here is that compatibility removes the integration hurdle, but it doesn't necessarily remove the hesitation around trying a newer provider.
From builders who've considered AIMOWAY so far, what have you learned about what stops them between seeing that it's easy to test and actually putting it into a real project?
That's a good distinction, and we've actually seen that gap ourselves.
We've had people register and then stop before making a first real API request. So compatibility and a low-friction setup clearly help, but they don't automatically create enough confidence for someone to put a newer provider into a real workflow.
My current view is that there are really two separate problems.
The first is activation: making the path from signup to API key to first successful request as short and obvious as possible.
The second is trust, which is harder. Developers want to know where the model service comes from, whether the access is legitimate, how tool calling and streaming behave, what happens under failure or concurrency, what latency looks like in their region, and whether the provider has enough operating history to support its reliability claims.
On that second point, I think transparency matters more than pretending to be further along than we are. Our upstream model service has a strong production foundation through a substantial high-performance computing provider in China with authorized model access, but AIMOWAY itself has only recently entered the North American market. We are still accumulating the operating data needed for meaningful failure-rate, latency, and uptime reporting.
So one lesson for us is that making an API easy to try is only the first step. Turning that first test into real usage requires much more technical evidence.
That makes sense. The distinction between activation and trust is useful, especially when the technical evidence still needs to accumulate. If you’re open to continuing the conversation, what’s the best email to reach you at?
For a new provider layered on top of models people can already reach elsewhere, tool calling reliability and reproducible cost and quality comparisons matter more than raw latency numbers. Latency looks fine in a benchmark post and then falls apart under real concurrent load, so a published comparison run on the same prompts against the original provider would carry more weight than a pricing page. Uptime and failure handling matter as well for anyone routing production traffic through you, since a compatible endpoint is only useful if it fails gracefully when the underlying model has an outage.
I agree, especially on concurrency and failure behavior.
A clean single-request latency benchmark can be useful, but it doesn't tell you enough about what happens when a real application starts sending concurrent traffic, using streaming and tool calls, retrying requests, or encountering 429/5xx responses and interrupted connections.
Our upstream model service comes from a substantial high-performance computing provider in China, with authorized access arrangements for the models it serves and existing use across software, research, and commercial workloads. That gives us a solid upstream foundation.
There are two limitations I think we should be equally explicit about, though.
First, the serving infrastructure is not in North America, so we don't expect to compete with locally served North American providers purely on minimum latency.
Second, AIMOWAY is still early in its North American operating history. We don't yet have enough production traffic over a long enough period to publish concurrency, failure-rate, P95/P99 latency, or uptime figures that I would consider authoritative.
I do think your proposed direction is the right one. A useful comparison should eventually include the same representative prompts and workloads, but also multiple concurrency levels, tool calls, streaming, regional latency distributions, 429/5xx behavior, interrupted streams, and recovery behavior.
A small reproducible test suite with clearly stated methodology would probably be more useful than a large benchmark table that only looks impressive.
I'd rather publish that evidence as it becomes statistically meaningful than manufacture confidence from a short test window.
A quick thank-you to everyone who contributed to this discussion.
The feedback here has been genuinely useful. The points around capability transparency, tool calling and streaming behavior, reproducible contract tests, regional latency, concurrency, failure handling, uptime, and the broader trust barrier for a newer provider have given us a much clearer picture of what developers actually want to see before moving from "easy to test" to "ready for a real workflow."
We've taken those points seriously, and they will help guide AIMOWAY's ongoing improvements. In particular, we want to make more of the service's real behavior independently verifiable over time rather than relying on broad reliability claims.
And while this discussion has been going on, we've also added two more models to the public catalog:
Both are now listed here with their current model information and pricing:
https://aimoway.com/docs/models
Thanks again to everyone who took the time to challenge assumptions, check the documentation, and explain what evidence actually matters in production. That kind of feedback is much more valuable to us than simple agreement.