Price the four separately
One: integration and reliability
Wiring up a few model APIs is straightforward. Channel failover, retry policy, converting between providers' billing units and adapting when a new model lands are not. This part is a one-off build plus steady small repairs.
Two: permissions and audit
This is the part that gets underestimated. Execution identity, permissions narrowed by project and action, confirmation before sensitive actions, credential custody, log masking and retention. It is a few lines as a requirement and a different thing as a system that survives an audit.
Three: usage attribution and reconciliation
Tie every call to a person, a project, a model and a task, set layered quota and alerts, then reconcile against the monthly invoice. Get the attribution rules wrong once and you correct them by hand every month after.
Four: keeping up
Models, agents, CLI tools and their interfaces change every month. Building means your team tracks all of it. Without someone assigned, the system stops at one version and quietly falls out of use.
When building holds up
- You have a platform team and can commit people to items two through four for the long run;
- your permission or compliance requirements really are beyond what existing products do, and you checked that item by item rather than by impression;
- the AI capability is part of your own product, so control has to stay in-house.
When buying costs less
- The goal is to get business teams using AI, not to build internal infrastructure;
- the urgent problems are permissions, audit and reconciliation rather than model routing;
- nobody can maintain it long term, so building produces a legacy system on day one;
- you need private deployment — which does not mean building, since a bought platform can run in your own environment.
The middle path
A common split: keep model routing in-house or on an existing gateway, and use a ready-made platform for projects, permissions, approval, handover and execution records. Existing models, knowledge bases and coding assistants stay; the platform manages them once they are connected.
Price it against one real task first — the method is in choosing, baselining and accepting a pilot.
Common questions
Where exactly does the cost of building sit?
In permissions and audit, usage attribution and keeping up with models — three continuing commitments, not the first few weeks of wiring APIs. Interfaces change monthly, and without someone assigned the system stops at one version.
If data cannot leave our environment, do we have to build?
No. Private deployment and building are different decisions; a bought platform can run inside your own environment with the boundary set by you.
We have already built part of it. Can it connect?
Usually. Keep model routing on what you built or on an existing gateway, and use a ready-made platform for projects, permissions, approval, handover and records. The scope is confirmed during a pilot.
How do we tell which case we are in?
Ask whether anyone can own permission audit, reconciliation rules and model upkeep for the long run. If yes and the requirements really are unusual, build. If no, building tends to produce a legacy system on day one.
Price one task first
Pick a frequent task and we will work through the integration, permission, reconciliation and upkeep effort with you before you decide.
Discuss a pilot