Built for code that cannot leave the building.
Banks, exchanges, defence, healthcare, anyone shipping under NDA: the question is never whether the assistant is good, it is where the code goes. With twinny it goes to a server you run and nowhere else, and the answers a security review asks for are on one page.
- 01
Run a model server on your own hardware or a private inference endpoint, and twinny-server in front of it, inside the network.
- 02
Give each developer a key from the admin page. Set team policy: which providers may be used, which models, a system prompt before every chat.
- 03
Hand the auditor a read-only admin key and the export of the hash-chained audit log.
Where the code goes
To the server you configured, over your network, and to nothing else. No vendor account, no telemetry, no update check. Works with no internet at all.
Policy the extension enforces
Team-only providers, locked models, routing rules that keep a workspace on local backends, a team system prompt. Shown to every developer for consent before they connect.
Recording, if you need it
Keep prompts and replies on the gateway for review, audit and training data. Off by default, disclosed to every developer, deleted after a retention period you set.
Procurement-shaped billing
$6 a seat by card, or an invoice or purchase order from 50 seats with a named contact. One organisation licence covers any number of gateways.
- Is there a DPA, or a vendor to assess?
- There is no data to process: twinny receives nothing. The assessment is of software you run, and its source is public.
- Can we restrict which models developers use?
- Yes. Team policy can lock the defaults and forbid any provider other than the gateway.
- Who sees usage?
- Admins see requests, failures and tokens per developer and model on the admin page. Content is never recorded unless an admin switches recording on, and then every developer is told.
Everything else is on the home page: features, the team gateway, security and pricing.