An on-premise deployment puts the model on hardware you own, on your network, behind your firewall. The reason it resolves so many conversations at once is simple: there is no egress path for the data to take, so a whole category of question stops needing an answer.
A hosted AI service is, in most configurations, a processor you have sent your data to. That is workable — the paperwork exists and is routine — but it puts a permanent set of obligations in place: a transfer assessment, a sub-processor list, a retention position, a deletion path, and an annual review of all of them. Each is a conversation, and each recurs.
On-premise removes the premise rather than the paperwork. If the model runs on a server in your building and the network has no route from it to the internet, then there is no transfer, no third-party processor in the AI path, no sub-processor list to maintain, and no retention question about somebody else's logs — for the AI component; the rest of your processing record is unchanged. The security review changes from can we trust this vendor with our data to is this server configured correctly, which is a question your team already knows how to answer.
The second change is economic and it compounds. A hosted API charges per token forever. Hardware is bought once and then costs electricity. That means a workload that is uneconomic to automate at API prices — reviewing every document rather than a sample, embedding an entire archive, running an agent over the whole backlog — frequently becomes economic the moment marginal cost approaches zero. In our experience the most valuable consequence of going on-premise is not the saving on existing usage. It is the work you start doing because it no longer costs anything per unit.
sized to model + concurrency
vLLM · batching · KV cache
pgvector on your DB
your systems, your auth
traces · cost · drift
optional, gated, redacted
If any of those describe you, the right recommendation is one of the other four deployment models, and we will make it. A client with the wrong infrastructure is a support problem for years.
It depends on the model size and how many people use it at once, and both are knowable in advance. A single well-specified GPU server handles a mid-size open model for a substantial number of internal users; larger models or higher concurrency need more memory rather than fundamentally different infrastructure. We size it from your workload before you procure anything — see GPU sizing and cost for the arithmetic.
Any open-weight family whose licence permits your use — DeepSeek, Llama, Mistral, Qwen and the small models; the licences differ per model, so read the one you intend to deploy. The leading closed models are generally not available for self-hosting, and where a vendor offers a private deployment it is under contract and at a price most organisations will not pay. For most production workloads the open families are close enough that the difference should be measured rather than assumed.
We scope four to ten weeks to a working pilot on your hardware, with the range driven mostly by procurement and network access rather than by the build. If the hardware already exists, the shorter end is realistic. That is a design target we plan to, not a measured client outcome.
Yes, and it is often the sensible order — prove the use case on an API, then move it in-house once the volume justifies the hardware. It only works if the system is built for it from the start, with the model behind an interface and no dependency on a provider-specific feature. We build that way by default because retrofitting it is genuinely painful.
Yes. The hardware and the code remain yours; we operate it under a support arrangement, or hand over with runbooks if you would rather your own team ran it. There is no component only we can maintain, which is the property that makes the choice reversible.
We size the hardware, build the stack and hand it over running. Or we run it for you.
30-minute technical call · no deck
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
