About
I'm a AI performance enthusiast, I cofounded oneinfer.ai. where we are striving for an optimized infra layer for AI workloads. We are building openbandwidth for leveraging instant optimized infra, my goal is accelerate the AI adoption in a massive scale. I feel, that cost and accuracy plays a major role in adoption, I have started with optimizing cost :)
Maker History
Forums
Feature Updates for oneinfer-edge
Hardware checks. Compatibility scans. Model deployment. Copilot routing. Local hosting. Multi-cloud instances. Cloud failover. Used to take a day. Now under 10 minutes.
AI moves fast. Deployment doesn't. 40% of teams take more than a week to get a single model into production. Data scientists spend over a quarter of their working day on setup, not science.
That's not an AI problem. That's an infrastructure problem.
oneinfer-edge fixes it. Not by reinventing the stack. By orchestrating what already exists into one open source control plane.
- Multiple serving libraries. One scan.
Ollama, llama.cpp, vLLM, SGLang, TensorRT-LLM, PyTorch, Dynamo. Instead of manually testing each one against your model and hardware, oneinfer-edge evaluates all five simultaneously and tells you exactly which one to use, for local, cloud, or both. Hours of trial and error eliminated before a single deployment.
- Traffic control panel for agentic harnesses. Zero code changes.
You can now leverage locally deployed models through the existing agentic copilots like codex, kilocode, opencode and openclaw and more upcoming.
-Model, serving library and hardware compatibility. Before you deploy.
Wrong serving library for your hardware. Wrong runtime for your model. These failures usually show up mid-deployment. oneinfer-edge runs a full compatibility scan across your model, your serving libraries, and your local hardware upfront. Complete picture. No surprises.
- Model and hardware resource checks. Local and cloud.
Paste any HuggingFace model ID. oneinfer-edge computes model weights, KV cache, and serving library overhead together and tells you whether it fits your machine or which cloud instance makes sense when local is not enough. No wasted downloads. No failed runs.
- Cloud instances marketplace. One API for everything.
Spin up instances across any cloud provider from the same control plane using a single OpenAI-compatible API. No switching between platforms. No managing separate configurations per provider. One place to create, manage, and monitor, regardless of which cloud you choose.
- Hybrid routing. Local, cloud, or both. Optimised automatically.
Local handles volume. Cloud handles complexity. When local capacity is exceeded, traffic fails over automatically. Routine tasks stay local. Complex reasoning goes to the cloud only when needed. Inference already accounts for 80 to 90% of the lifetime cost of a production AI system. Intelligent routing alone cuts that by 30 to 60%. Local-first hybrid orchestration pushes further.
We are just getting started. More coming in the next few days. Stay tuned!!!
Repo: https://github.com/oneinfer/onei...
Star it. Fork it. Consider contributing to the community.
New Feature: Connect your locally hosted AI models to coding copilots with a click in oneinfer-edge
We shipped a new feature in oneinfer-edge (fully open source) to connect your locally deployed model to coding copilots like codex, OpenClaw, OpenCode and kilo code etc....
No plugin. No config file. No IDE restart. You click ONEINFER, a local proxy intercepts your copilot's requests, translates the format, routes to your self hosted model, and returns the response.
Your IDE doesn't know anything changed.
The proxy handles the ugly parts, model name rewriting, response format translation, streaming, so you don't have to spend an afternoon debugging why Codex expects an OpenAI messages format and your local model returns something else.
Switch back to original models in one click, mid-session, no restart. For when you actually need it.
This is just the start. Support for more agentic harnesses and copilots is already in the works, we're expanding the list based on what the community actually uses. So please voice out what you need in the github issues.
oneinfer-edge is the proxy, the hardware compatibility scanner, the inference routing, it's all in the repo. We'd rather you read the code than take our word for it.
An intro about oneinfer-edge
We just shipped the first feature for oneinfer-edge and it's open source.
Ever copy a Hugging Face model ID, spend 2 hours setting things up, and then watch it fail because your VRAM was off by a few GB? Yeah. We've all been there.
oneinfer-edge now tells you if your machine can run any Hugging Face model before you deploy.
Paste a model ID, it scans your GPU, VRAM, OS, and serving libraries, gives you a Hardware Ready verdict and full memory breakdown (weights + KV cache + serving overhead).
No surprises at runtime.
Supports Apple Silicon (M1 to M5), NVIDIA (CUDA), AMD (ROCm), and serving libraries including Ollama, llama.cpp, SGLang, TensorRT-LLM, PyTorch and many more coming.
It tells you why something won't work, not just that it won't.
CPU support is something we're actively working through and feedback and contributions on that front are very welcome.
oneinfer-edge is part of the broader oneinfer.ai inference control plane, a platform built for teams shipping multimodal AI products at scale.
oneinfer-edge brings that same infrastructure intelligence to your local machine so self-hosting is a genuine alternative to managed cloud inference, not a debugging exercise.
We built this in the open because self-hosted AI infrastructure should belong to the community that runs it.
Star the repo: https://github.com/oneinfer/onei...
Report issues or request features: https://github.com/oneinfer/onei...
Learn more: https://oneinfer.ai/platform/one...
Drop us a star if this looks useful and PRs are wide open. We're just getting started.





