International access: https://4sapi.com
Domestic access: https://4sapi.org
DeepAudit becomes useful when it can send the right code context to a suitable large language model and return findings that a developer can verify.
Installing the application is only part of that process.
You also need to configure model access, confirm that the selected API protocol works, control the scope of the first audit, and decide what counts as a useful result.
This guide focuses on that model connection. It explains how to configure DeepAudit with an OpenAI-compatible API gateway such as 4SAPI, choose an available DeepSeek or GPT route, and evaluate a small audit before scanning a larger repository.
The configuration names below follow DeepAudit’s versioned v3.0.0 documentation. Check the documentation matching your installation if you use a different release.
The goal is a repeatable workflow: one application, a documented model route, a controlled repository sample, and an audit report you can review.
Understand where DeepAudit ends and the model API begins
Think of the setup as three cooperating components.
DeepAudit manages the code-audit workflow. The model provides language understanding and analysis. The API service receives requests and returns model responses.
Running DeepAudit on your own computer does not automatically mean the model also runs locally.
If you configure a remote gateway, code included in requests travels to that service and potentially its upstream provider. Choose repository material that your organization permits you to send through that route.
For a first experiment, a synthetic project is ideal. It removes uncertainty about sensitive code and gives you a small enough scope to inspect manually.
DeepAudit documents support for multiple model providers and custom API endpoints. Its versioned configuration guide includes a specific OpenAI-compatible relay configuration.
That provides the integration mechanism. Your test determines whether the selected model route is suitable for your workload.
Select a model route that matches the adapter
A model family name is not enough to choose a configuration.
“DeepSeek” and “GPT” each refer to multiple models and versions. Available endpoints and supported features can differ between them.
For the gateway configuration in this tutorial, choose a route documented to work with the OpenAI-compatible Chat Completions interface used by your DeepAudit setup.
Do not assume that every GPT model works with every OpenAI-style adapter. Confirm the endpoint required by the exact model and the capabilities exposed by the gateway.
Similarly, a DeepSeek route offered through a gateway may use the gateway’s OpenAI-compatible interface rather than DeepSeek’s direct-service configuration.
The practical selection order is:
- Confirm that the model is available to your account.
- Confirm the request protocol.
- Check whether your intended audit mode needs additional capabilities.
- Run a small compatibility test.
- Evaluate the findings on code you understand.
This sequence avoids choosing a model solely because its name appears in a benchmark or article.
Prepare the account and installation
You need a working DeepAudit installation, access to its backend configuration or administration interface, and an API key for the selected gateway.
If DeepAudit is not installed yet, use the deployment instructions for your chosen release. The project’s versioned deployment guide describes the backend environment file and Docker Compose deployment workflow.
For 4SAPI, inspect the model information and select a group that includes your intended model. Copy the exact model identifier rather than reconstructing it from a display name.
Create a development key specifically for this audit experiment. Name it clearly so usage is easier to identify later.
Choose a small initial budget. A repository audit may involve several model requests, so the cost of a complete run can exceed the cost of one prompt.
Keep your first repository sample small enough that you can review both its code and the resulting report in one sitting.
Configure the gateway connection
For the documented backend configuration method, edit the relevant LLM settings in backend/.env.
A minimal example is:
The placeholders are intentional. Use a model ID confirmed in your account and the endpoint documented for your selected route.
Here, openai selects the compatible adapter. It does not mean that every request necessarily goes to an OpenAI-hosted model.
DeepAudit’s documentation also supports runtime configuration through /admin; those saved settings take precedence over backend environment values. Check that interface if an environment-file change appears to have no effect.
Apply environment changes using the restart or container-recreation procedure appropriate to your deployment. Avoid assuming that editing a file changes a process that is already running.
Store the API key only in the intended secret configuration. Do not put it into a frontend bundle, public repository, screenshot, or shared audit report.
Confirm connectivity before submitting a repository
Your first check should be a short text request using the same endpoint, credential, and model identifier.
For example, ask the model to explain a small function in two sentences.
If that request fails outside DeepAudit, resolve the API configuration first. A larger audit will not make an invalid credential or unsupported model route work.
If the simple request succeeds but DeepAudit fails, compare the requests.
Look for differences in the actual model ID, endpoint, parameters, message format, or enabled tools. Also check whether a saved application setting is selecting a different configuration.
A basic text response establishes only basic connectivity.
Agent-based auditing may require additional services and model features. DeepAudit’s deployment documentation treats agent auditing, embeddings, and supporting services as additional configuration concerns.
Test those dependencies separately before interpreting an incomplete agent run as poor model reasoning.
Build a small audit sample with known expectations
A useful first audit sample should contain both a problem and a correct implementation.
For example, create a small synthetic project with two versions of a data-access helper:
- One version constructs a database query by directly combining user input with query text.
- Another version uses the database library’s parameter-binding mechanism.
Include the surrounding call site and the library information needed to understand how the helper is used.
The expected result is not simply “find something suspicious.” The audit should distinguish the unsafe construction from the correctly parameterized version and explain the relevant evidence.
You can add another small example involving an authorization check, provided the intended access rule is documented in the fixture.
Keep the examples local and synthetic. The purpose is to evaluate reasoning about code you control.
Write down the expected findings before running the audit. Otherwise, it is easy to accept an impressive explanation without checking whether it identified the actual issue.
Define what a useful finding must contain
A finding should help a developer make a decision.
For the first evaluation, require a clear file location, a description of the relevant code behavior, the conditions under which the problem matters, and a proposed direction for remediation.
Separate evidence from assumptions.
For example, a model might correctly notice that a helper does not perform an authorization check. Whether that creates an application vulnerability may depend on checks elsewhere in the request path.
A useful report identifies that dependency.
A weak report turns an incomplete observation into a confident severity claim.
Review each finding using a simple set of questions:
- Does the cited code exist?
- Does the explanation match what the code does?
- Is the claimed execution path possible in the sample?
- Has the report overlooked an existing safeguard?
- Would the proposed correction address the issue without breaking expected behavior?
These questions turn model output into reviewable engineering evidence.
Compare DeepSeek and GPT on the same audit task
After one route works, you can evaluate a second supported model.
Keep the repository revision, audit scope, instructions, and application configuration consistent. Change only the model-related configuration needed for the second route.
If you also change the audit mode or tool configuration, record that difference. You are then comparing complete workflows rather than isolating model behavior.
Do not judge the models by report length.
A shorter report that identifies the real issue and avoids false alarms may be more useful than a long report containing speculative findings.
Track confirmed findings, missed expected findings, unsupported claims, and reviewer effort.
For a small fixture, count these directly. For a real repository, make clear that you do not know the complete set of vulnerabilities, so the number of reported findings is not a reliable measure of total coverage.
Avoid selecting a permanent winner from one run. Repeat the evaluation across several representative examples before adopting a default model.
Measure the cost of a usable audit
An audit can contain several stages: reading code, selecting context, analyzing a candidate issue, checking evidence, and producing a report.
The total API bill depends on the requests generated by the workflow, not just the size of the repository.
Measure expenditure for the complete run.
Then consider the human effort required to review it. Ten low-quality findings can consume more developer time than one well-supported finding.
A practical comparison record includes:
| Metric | Why it matters |
|---|---|
| Completed audit runs | Shows whether the workflow reliably finishes |
| Confirmed findings | Measures useful discoveries |
| Unsupported findings | Reveals review burden |
| Missed fixture issues | Tests performance against known expectations |
| Total API cost | Captures the complete run |
| Review time | Connects model output to developer effort |
You can also calculate cost per confirmed finding, but interpret it carefully. A clean repository may produce no confirmed findings even when the audit is useful.
Use multiple measures instead of optimizing a single number.
Troubleshoot the failing layer
When an audit stops, identify the stage that failed.
If no model request succeeds, investigate authentication, endpoint configuration, account permissions, or the selected model route.
If small prompts work but larger audits fail, inspect request size, timeouts, concurrency, and any feature-specific errors.
If the audit reaches a tool or retrieval stage and then stops, inspect that component’s configuration and logs.
Increasing a timeout may help a slow request complete. It will not correct an invalid model identifier or a missing dependency.
Likewise, switching models may change the symptom without fixing a configuration problem.
Keep a short troubleshooting record containing the application version, repository sample, selected model, sanitized error, and the last completed stage.
This makes support requests more useful and helps you avoid repeating experiments that have already failed for a known reason.
Expand the audit gradually
Once the small sample works, move to one bounded module in a repository you are authorized to review.
Choose a module with a clear purpose, such as request validation, file handling, or account permissions. Include enough related code to understand the relevant execution paths.
Exclude generated files, large dependencies, and unrelated assets when they add no useful context.
Review the report before expanding the scope.
If results are noisy, improve the audit instructions or context selection before increasing the number of files. Larger inputs can make an unclear workflow more expensive without making it more effective.
Preserve the model configuration and repository revision for each evaluation. That gives you a basis for comparing future model updates or changes to the audit process.
Frequently asked questions
Can DeepAudit use DeepSeek through an API gateway?
It can use a compatible gateway configuration, provided the gateway exposes the required model and interface and your selected audit mode works with that route.
Does `LLM_PROVIDER=openai` mean I must select a GPT model?
In the relay configuration, it selects the compatible adapter. The gateway’s documented model identifier determines the requested model.
Why does changing the environment file not change the active model?
Check saved runtime settings, deployment configuration, and whether the backend process has actually loaded the new values.
Does a completed report prove that the repository is secure?
No. Treat it as evidence to review alongside your existing testing, code review, and security processes.
Connect a model and evaluate one real workflow
Start with a small audit that you can verify manually.
Register with 4SAPI, select a supported DeepSeek or GPT route, and create a dedicated development API key. Configure DeepAudit, confirm a short request, and then audit your synthetic sample.
That first run should answer a practical question: can this model connection produce findings your developers can use?
