lab358 serves the open-weight model you already use exactly as its authors published it, and makes long context durable in the serving layer — index a document once, reuse it on every call. Run it managed on lab358 Cloud, or self-hosted in your own AWS account.
Inference, not training, is where AI budgets go: roughly 60–80% of total AI compute spend, in a market estimated at $106B in 2025 and projected to reach $255B by 2030. And the workloads growing fastest — contracts, case law, patient histories, filings, codebases — are exactly the ones a standard stack punishes, because every call re-reads the whole document from scratch and the cache it builds devours GPU memory.
The usual escape routes all give something up. State-space conversions compress history into a fixed-size state and lose long-range recall. Cache-eviction tricks discard context at inference time, trading quality for speed. Retraining a frontier model on a new architecture costs more than most companies will ever spend on inference.
And modifying the model has a tax of its own that rarely gets counted. The moment a checkpoint is converted or retrained, it stops being the model anyone else has benchmarked. Your evaluations don't transfer. The vendor's quality claims are the only ones available, and you have to take them. Every upstream release restarts the process.
So we took a different route: don't change the model — change how it's served.
What lab358 does
You bring an open-weight model you already use. We run it unmodified — the same weights, the same tokenizer, the same behaviour its authors published and the community measured. There is no conversion step, no retraining, and no fine-tune.
What we build is everything around it. A document is processed once into a stored form the model can read back later, and retrieved on demand with approximate nearest-neighbor search instead of being pushed through the prompt again on every call. That single change is what makes long context durable:
- The expensive part is paid once. Reading the document is the costly part of a long-document request. Index it once and every later call — the next turn, the next agent step, the next user tomorrow — skips it.
- The context stops being capped by one device. Stored context doesn't have to sit in GPU memory, so how much you can work with isn't decided by what fits alongside the model.
- Growing the corpus doesn't grow every request in lockstep. Retrieval reads the relevant parts, not all of them.
In practice, three steps:
- Bring a model. An open-weight model you already use — standard tokenizer, nothing to prepare.
- We serve it as published. No conversion, no retraining. The model you evaluated is the model you run.
- Index your documents once, then reuse them. Through the console, the API, or an integration. The endpoint is OpenAI-compatible, so pointing an existing app at it is a base-URL change, not a rewrite.
Why "unmodified" is the feature
It reads like a limitation and it is closer to the opposite:
- Quality is not ours to explain. The model's published evaluations are the model's evaluations. You can reproduce them, and you can compare against anyone else running the same checkpoint.
- Nothing to re-certify. Teams that have already reviewed and approved a model internally don't start that review over.
- New checkpoints are support, not a project. When a lab publishes a model you want, adding it is work on our side that doesn't involve a training run.
- No lock-in at the weights. If you leave, you keep a model anyone can download. What you'd be giving up is the serving stack — which is the honest description of what you're buying.
What we're measuring
Numbers here will be published measured, not projected, and we would rather be late than approximate. The serving-side quality and cost measurements are in progress; this section will carry them when they exist, with the method and eval set named so they're reproducible.
What can be said today without waiting: the model's own quality is a matter of public record, because it is the public model.
What it means for your workloads
The following are the intended effects of the design above; per-workload benchmarks are in progress and will be published when measured.
- Repeated work over the same documents gets cheaper the more you do it. The savings compound with reuse, not with a one-off.
- The context ceiling stops being the design constraint it is in a standard stack.
- Nothing about your stack changes. Same model, same tokenizer, OpenAI-compatible API.
Availability
lab358 ships two ways — the same model and the same OpenAI-compatible API either way — so you pick where it runs:
- lab358 Cloud. A fully managed, usage-based workspace hosted by lab358 and billed on tokens and storage: self-serve signup, nothing to operate. It's rolling out gradually — join the waitlist and we'll reach out as access expands.
- Self-hosted. The same stack as an AWS Marketplace container product — a Helm chart that deploys into your own Amazon EKS cluster, metered and procurement-friendly, running entirely inside your AWS account. Data residency is the default, not a premium tier: your prompts, completions, and documents never leave your VPC.
If you run long-context workloads, join the lab358 Cloud waitlist — or, to self-host in your own AWS account, or to ask about the model you want on the supported list, talk to us.
Investors: hello@lab358.ai.