AI for the code that cannot go to a public cloud.
Private coding assistance for engineering teams whose client contracts keep code off the public cloud, on the Azita fleet or on an installation in your building.
Prefer email? hello@azitalabs.com, subject “Coding workload evaluation”.
The job
The developer's day, and the pipeline's night.
Your engineers know what they are missing: completions that finish the line, a chat that has read the repository, a reviewer that reads the pull request before a person does, tests written for the code that has none. Security teams often block the cloud versions because a client's contract says where code may go. A deployment whose location is set in your agreement, on the Azita fleet or in your own building, gives that clause a specific answer.
- What you bring
- Your repositories, tickets and design notes, and the requests your developers make as they work.
- What comes back
- Completions, answers from the codebase, pull-request review comments, generated tests and overnight batch changes waiting for a person to accept.
By day
The assistant
Completions, chat over the codebase, pull-request review, unit-test generation and questions answered from the repository.
By night
The batch
Review of the day's merges, tests for the modules nobody covered, migration jobs across a legacy codebase, and a refreshed index of the repositories, with the diffs waiting for a person to accept.
What runs
What runs for the team.
Open-weight models of the classes below, pinned once they pass your own evaluation set. No vendor names here: the choice is made against your tests rather than a leaderboard, and it can change when your tests say so.
- A code model for completions and chat
- Trained on code and tuned for long context, so it can hold a module and its callers in view while it finishes the line or answers the question.
- A reviewing model
- Reads a pull request against the codebase and your conventions, comments where a person would, and proposes the tests the change forgot.
- An index of your repositories
- The retrieval layer that lets the assistant answer from your code rather than from its training, refreshed as commits land. Which retrieval stack is used is set out in your proposal.
- A batch runner for the night
- Migration jobs, coverage runs and repository-wide refactors queued at close of day, with the diffs waiting for a person to accept.
How it is delivered
Two ways it reaches the desk.
Both routes are scoped around your repositories and your team's tools, and how those tools connect is set out in your proposal.
Capacity from the Azita fleet
The work runs on capacity from Azita's installations, with the processing location set in your agreement. If a self-hosted coding tool already runs on your team's desks, how it connects to that capacity is scoped in the proposal.
An installation in your building
Azita designs, installs, commissions and operates an installation in a room of your own office, serving your engineers, and meters the work.
Boundaries
Agreed before any work runs.
For code the constraint is contractual: the client's MSA, the security questionnaire and the audit clause. Each of these is agreed in your proposal and set in your agreement before any work runs.
- Processing location
- Where the models, the index and the logs sit: on the Azita fleet, or on an installation in your building. Whether any work may use a public cloud is your rule, written into the agreement.
- Model choice
- Which open-weight models run, and the model version and index snapshot a review is pinned to, as agreed in the proposal.
- Access
- Who can reach the repositories, the index, the logs and the installation, and how that access is recorded for your client's auditor.
- Retention and exit
- How long the index and the logs are kept, and how they are erased when the agreement ends. Exit and erasure terms are set out in your agreement.
Evaluation
Judged on your own work.
Your own evaluation set decides. On the hardest agentic tasks the open models are a step behind the frontier tools, and your engineers will notice; the evaluation shows where that matters for your work.
- Representative input
- A repository you are cleared to share, with names redacted, and the evaluation set your team already trusts.
- Quality criteria
- Results on your evaluation set, the quality of review comments on real pull requests, and the conventions your engineers set.
- Volume
- The repositories, developers and requests in scope, agreed to represent your team's work.
- Turnaround
- Response time as developers work, and when overnight batch work is ready, agreed before the evaluation starts.
- Acceptance
- Your engineers grade the result against the criteria before anyone discusses switching. If it does not meet them, nothing moves.
Evaluation template. No measured results
Compare the same work.
Agree the workload, conditions and acceptance criteria before comparing a baseline with Azita.
- Agreed workload
- [Agree before evaluation]
- Same input and scope
- [Agree before evaluation]
- Acceptance criteria
- [Agree before evaluation]
| Comparison basis | Current baseline | Azita |
|---|---|---|
| Output qualityEvaluate against the agreed acceptance criteria. | To measure | To measure |
| Completion timeUse the same start and finish definitions. | To measure | To measure |
| VolumeRecord the amount of work in the agreed unit. | To measure | To measure |
| Data locationRecord the processing location and relevant boundaries. | To measure | To measure |
| Total costCompare the same scope and included cost items. | To measure | To measure |
Commercial basis
Proposal based on your workload and deployment.
There is no price list on this page. Your proposal sets out what is quoted, the commitment and what is included.
Named in your proposal where they apply
- Licences for the coding tools your team uses
- Integration with your editors, repositories and build pipeline
- Index and retrieval setup for your codebase
- Review time for your engineers
- The commitment, and what is included
Compare quality and total cost on your own workload before you decide.
Where this stands today.
Available to evaluate on your own workload. On the Azita fleet, or on an installation in your building.
Who it is for
Who this is for.
It suits the teams whose contracts already say no to the cloud, and whose engineers are already asking why.
- Mid-tier IT and engineering services firms with BFSI or healthcare contracts that bar third-party AI on client code
- Fintech and healthtech product companies whose security team blocked cloud coding tools
- Captive engineering centres holding a parent's source code under audit
- Platform and security teams asked to make an AI assistant pass the client questionnaire
Not your kind of work? See other workloads
Straight answers.
Is it as good as the cloud assistant our engineers use at home?
Your own evaluation set decides. On the hardest agentic tasks the open models are a step behind the frontier, and your engineers will notice if we pretend otherwise. Where a frontier tool earns its premium on work the contract allows, keep it for that work.
Does any code go to a public cloud?
Only if your agreement allows it. Where the models, the index and the logs sit is set in your agreement before any work runs: on the Azita fleet, or on an installation in your own office.
How does this answer our client's security questionnaire?
With the arrangements your agreement sets: where the code sits, who can reach it, which model versions run, and how it is erased at exit. Which certifications apply to your deployment, and their status, are set out in your proposal.
Which editors and tools does it work with?
The ones your team uses are named in the scope. How each editor plugin or self-hosted tool connects is confirmed during the evaluation and set out in your proposal, including any integration work.
How is it priced?
Proposal based on your workload and deployment. There is no price list on this page. We agree a representative job and the acceptance criteria, then set out what is included, the commitment and the total cost next to what you pay for coding tools today, before you decide.
What happens when the agreement ends?
Exit and erasure terms are set out in your agreement, including how the index and the logs are erased and, for an installation in your building, how it is removed.
Other workloads
Voice
Voice agents for BFSI floors
Indic voice agents and every-call quality review for collections and service floors, on the Azita fleet or on an installation in your building.
Read this one
Health
Hospitals and diagnostics
Consultation audio and imaging AI for hospitals and the vendors that serve them, on the Azita fleet or on an installation inside the hospital.
Read this one
Post
VFX assist for post houses
Overnight roto, cleanup and upscaling for pre-release content that your client's rules keep off public clouds, on the Azita fleet or on an installation in your building.
Read this one
Promo
Overnight promo and product clips
Promo and product-clip variants from approved stills, rendered on open models on the Azita fleet or on an installation in your building.
Read this one
Start with your own workload.
Send one repository and your evals
A repository you are cleared to share, names redacted, and the evaluation set your team already trusts. We agree the acceptance criteria with your engineers, then compare the output, turnaround and total cost with what you use today. We’ll review what you need to run and contact you to discuss the right setup.
Arrange a workload evaluation