Optional services and what each one costs

A CID222 package is the base appliance plus whatever your licence and your deployment add to it. Each addition carries its own requirement line. This page gives one section per component: what it is, when you need it, how it is switched on, what it costs at idle and under load, and what happens when you add it to a box that is already sized.

Figures marked measured come from the 2026-09-08 cgroup measurement of the development server. Figures marked declared are the compose memory limits, which are a ceiling the container is held to, not a prediction of what it uses. Where neither exists, the section says so and says what to measure.

The add-on table

Code Safety

What it is. A separate stack that audits source code and binaries: a PostgreSQL weakness catalogue, a read-only database API over it, the auditor itself, a binary-capability scanner, and two dataflow services that build a cross-file reachability graph. The gateway holds only a client.

When you need it. When developer traffic — the browser extension, the endpoint agent, or a tracked repository — has to be judged for insecure or malicious code rather than for PII and toxicity.

How it is enabled. The licence must carry the Enterprise key codesafety. On the gateway, set CODE_SAFETY_SERVICE_ENABLED=true and point CODE_SAFETY_SERVICE_URL at the auditor, which defaults to a routable name on port 8018 because the auditor is expected to be on other hardware. CODE_SAFETY_SERVICE_TOKEN must match what the auditor accepts. Repository tracking is a second, separate switch: REPO_TRACKING_ENABLED.

Its requirement line. A host of its own. The graph engine is the binding constraint: it is capped at 2.0 vCPU and 4 GB precisely because it will otherwise take the whole machine, and it keeps a graph cache of up to 10 GiB on disk. Budget 8 GB and 4 vCPU for the auditor stack as a whole and give the graph engine its 2 vCPU on top of whatever else the host does.

Idle against load. The catalogue database is read-heavy and quiet. The graph engine is the opposite: a 641-file TypeScript repository drove it to roughly 980 % CPU and 2 GiB for over fifteen minutes without finishing. That is the engine working as designed — the query is an all-pairs reachability search — and the cap turns a large audit into a slow one rather than a failed one.

GPU. The deep path's model is served over an OpenAI-compatible endpoint, so any engine will do. The intended quantisation ladder is a 16 GB card at roughly 4.7 GB plus KV cache, a 32 GB card at roughly 8.5 GB, and 8.5 to 15 GB where there is memory to spare. CPU-only serving works and is documented as degraded.

Adding it to an already-sized box. Do not. The catalogue is roughly 150 thousand rows of read-heavy data and the graph engine is a JVM that saturates cores for minutes at a time; put both beside the detectors and the detectors are what slows down. Code Safety is a second host by design.

LLM Risk Analyst

What it is. Two containers — the analyst and the MCP server it queries — plus a model endpoint that is not part of them. Repeated jailbreak and PII detections fill a sliding window, which opens one per-user review; the analyst reasons over the evidence through tool calls and returns a verdict.

When you need it. When you want a written, evidence-grounded judgement per user rather than a per-message decision.

How it is enabled. The licence must carry the Enterprise key risk.llm_review. Start the llm-analyst compose profile, which brings up both containers, and give the analyst a model endpoint through LLM_BASE_URL, LLM_MODEL, LLM_ENGINE and LLM_API_KEY. RISK_ANALYST_SERVICE_ENABLED is the gateway-side switch.

Its requirement line. The profile declares 4 GB — 3 GB for the analyst and 1 GB for the MCP server — and measured 1.5 GiB of anonymous memory added to the stack. Measured idle: 882 MiB for the analyst, 594 MiB for the MCP server. Neither needs a GPU. The engine does.

Choosing an engine

All three speak the same OpenAI-compatible surface, and tool calling is not optional: a review ends when the model emits a tool call, so an endpoint that cannot emit one produces no verdicts at all rather than worse ones.

Model, quantisation and memory

The 20 GB arithmetic, which is where the minimum comes from: int4 weights take about 10 GB; LLM_GPU_MEMORY_UTILIZATION at 0.90 of a 20 GB card leaves about 18 GB; activations and CUDA graphs take 1 to 2 GB; the key-value cache pool is therefore 6 to 7 GB. The model's cache costs about 160 KiB per token, so one full 32768-token sequence holds about 5 GiB. One full-length sequence is resident, not two.

What a bigger card buys. Seats, not speed. On 20 GB the settings are LLM_MAX_NUM_SEQS at 2 and LLM_MAX_BATCHED_TOKENS at 4096 — one review plus a short administrator question — paired with LLM_MAX_CONCURRENCY at 1 and ANALYST_REVIEW_CONCURRENCY at 2. A 48 GB card takes 8 and 8192, which is four times the reviews in flight at the same per-review latency. On the same 20 GB card, LLM_KV_CACHE_DTYPE set to fp8 roughly doubles the pool, if the acceptance probe still passes afterwards.

Measured on the reference card, 2026-09-05: an RTX 4000 SFF Ada reporting 20475 MiB, weights resident at 9.36 GiB, a 32768-token context accepted, and 26.7 tokens per second single-stream with tool calling parsed correctly.

Disk. The installer's preflight requires at least 40 GB free on both the runtime directory and the Docker root. The offline bundle that carries engine and weights is about 20 GB; the online release manifest is about 150 KB because it downloads the same bytes instead of carrying them.

Adding it to an already-sized box. The two analyst containers fit in 1.5 GiB of measured head-room. The engine does not fit anywhere on a CPU-only appliance sized at the minimum — a GGUF slice wants 16 GB of host RAM for itself, on top of the base stack's own 10 GiB idle. Put the engine on its own host, or raise the appliance to 64 GB before you consider the CPU slice.

MCP server

What it is. A read-only server over the CID222 database, and the only way the analyst reaches evidence. It fuses PostgreSQL full-text search with an in-process dense index over the reference knowledge tables.

When you need it. Whenever the LLM Risk Analyst runs. It is also licensed on its own from Professional upward, under the key mcp.server.

How it is enabled. The llm-analyst profile starts it. The analyst reaches it through MCP_SERVER_URL and is admitted by MCP_SHARED_TOKEN.

Its requirement line. 1 GB declared, 594 MiB measured idle. Peak resident memory with one loaded embedder is about 560 MiB, inside the 1 GB limit. The embedding model is about 112 MB and is baked into the image, so the container never reaches a model host.

Hallucination guard

What it is. A grounded-response check over the model's answer, in English and Turkish. It runs behind the response, not in front of it.

When you need it. Retrieval-augmented deployments, where the question is whether the answer is supported by the documents it cites.

How it is enabled. It starts with the base profile. HALLUCINATION_SERVICE_ENABLED is the kill switch.

Its requirement line. 4 GB declared, 474 MiB measured idle, CPU only — no GPU path exists. Its behaviour under load has not been measured. To size it, run a realistic grounded workload and read the container's anonymous memory before and after, the same way the ONNX detectors were measured.

GPU OCR

What it is. The same OCR service on CUDA instead of CPU: roughly 3 to 8 times faster per image.

When you need it. When the image and document path is the bottleneck. It is the only part of CID222 that a GPU makes faster — the PII, toxicity, jailbreak and injection detectors are ONNX on the CPU and do not change.

How it is enabled. Two independent paths, from one service definition:

Its requirement line. One NVIDIA card, driver 530 or later. The VRAM the CUDA build needs has not been measured. To size it, run the same three images — an A4 text page, an identity card and a sparse photograph — against the CUDA container and read the card's memory use at each step.

The cheaper answer first. Before buying a card, check which inference runtime the CPU service is using. The ONNX Runtime engine is the baked default and was measured 1.5 to 2.8 times faster than the alternative, at half the CPU seconds and 40 % less anonymous memory, with byte-identical output across 121 compared text boxes. Its memory arena must stay disabled: with the arena on, anonymous memory climbed to 2999.6 MiB over three images and was still rising inside a 4 GiB limit; with it off the same sequence ended at 423.9 MiB, at no latency cost.

Inline proxy and ICAP inspection

What it is. A forward proxy that decrypts client browser traffic and submits it to the gateway's ICAP listener, so traffic that never touches the API gateway is still inspected. The listener itself is part of the gateway, not a separate container.

When you need it. Browser-to-provider traffic — the shadow-AI case — where there is no API key to route through.

How it is enabled. The inline-proxy compose profile starts the proxy container. ICAP_ENABLED and ICAP_PUBLISH control the listener inside the gateway. A third-party secure web gateway can call the same listener instead of running the bundled proxy.

Its requirement line. The proxy container declares no memory limit and was not in the measured container set, so no figure exists for it. What it reliably costs is elsewhere: every inspected request lands on the same detectors, so budget the CPU in the requirement line of the base stack rather than in this one, and expect detection rows to grow faster than in gateway-only mode.

To size it, start the profile against your real browser population and read the proxy container's anonymous memory and CPU seconds over a working day.

User-ID agent

What it is. An agent that attributes traffic to Active Directory users, so an inspected request carries a person rather than an address.

When you need it. Inline inspection deployments where the detections must name a user.

How it is enabled. The userid-agent compose profile. The gateway consults it through USERID_AGENT_URL.

Its requirement line. A compiled Go service with no declared memory limit, not in the measured set. It needs reachability to a domain controller. No measured figure exists; read its cgroup after a day of real attribution traffic.

DeepTeam

What it is. The red-team testing service behind the filter-testing framework.

When you need it. Acceptance testing and periodic assurance, not steady-state operation.

How it is enabled. It starts with the base profile; DEEPTEAM_ENABLED is the kill switch.

Its requirement line. 2 GB declared, 103 MiB measured idle. Its own footprint is not the cost — a red-team run drives the detectors hard, and the guards are what you feel. Do not run one against a box that is simultaneously serving production traffic at its CPU ceiling.

Report renderer

What it is. The service that turns compliance and cost reports into PDF and HTML.

When you need it. Whenever a report is exported. It starts with the base profile.

How it is enabled. REPORT_RENDERER_ENABLED, and REPORT_RENDERER_URL if it is not the in-stack service.

Its requirement line. 512 MB declared, 62 MiB measured idle — the smallest declared limit in the stack. Rendering is bursty and short; no figure under load has been measured.

Document and image pipeline

What it is. Four services that turn files into text the detectors can read: OCR, the document parser, the document classifier and the redactor.

When you need it. Any deployment where users attach files. Switch the group off with OCR_SERVICE_ENABLED, DOCUMENT_PARSER_SERVICE_ENABLED and REDACTOR_SERVICE_ENABLED if they never do.

Its requirement line.

OCR is the one to plan around, and it is CPU-bound rather than memory-bound. Nothing is resident until the first request, so its idle line says nothing about what it costs to run; the first user after a restart pays about 4.5 seconds and 1.7 GiB to load the first language.

Prompt compression

What it is. Input-token reduction before the provider call, licensed from Professional upward under the key cost.token_reduction.

How it is enabled. It starts with the base profile; PROMPT_COMPRESSOR_ENABLED is the kill switch, and the licence key decides whether the gateway calls it.

Its requirement line. 3 GB declared, 633 MiB measured idle. No GPU. It pays for itself in provider tokens rather than costing anything unusual on the host.

Worked example: base, Code Safety and a local model

A single-box deployment carrying everything an Enterprise package can switch on. The arithmetic is anonymous memory, which is what must be backed by RAM:

That is 64 GB of RAM, 16 vCPU and 200 GB of disk, and it is not a comfortable 32 GB box: 24 GiB of anonymous memory on a 32 GB guest leaves nothing for the page cache the model files want, and a ballooned guest will start swapping before it runs out.

Add to that:

• 2 vCPU reserved for the code graph engine, which will use every core it is given, on top of the 8 the base stack wants and the whole machine one OCR page briefly takes.
• Disk: 100 GB for the appliance, 10 GiB for the graph cache, about 10 GB of model weights, and the catalogue database. 200 GB is the realistic floor.
• One 20 GB card for the analyst's model, which serves a 32768-token context with two engine seats. The Code Safety model, when it ships, wants its own memory on that card — roughly 4.7 GB plus its cache at the smallest quantisation — so a 16 GB card will not hold both. Plan a second card, or the second host the auditor is designed for.

Related

• Requirements and sizing — the base appliance, per deployment mode.
• Resource sizing — the measured per-container tables and the recipe for computing your own total.
• Services, ports and profiles — the generated per-service table.
• Compose profiles and CLI — how a profile is started.