PentAGI

Penetration testing Artificial General Intelligence

Join the Community! Connect with security researchers, AI enthusiasts, and fellow ethical hackers. Get support, share insights, and stay updated with the latest PentAGI developments.

⠀

Table of Contents

• Overview
• Features
• Architecture
  • Agent Supervision
• Quick Start
  • Agent Docker Access
  • Running Several Instances
• How to Use PentAGI After Login
• API Access
  • LLM Provider Configuration
    • Azure OpenAI
    • Ollama
    • OpenAI
    • Anthropic
    • Google AI (Gemini)
    • AWS Bedrock
    • DeepSeek
    • GLM
    • Kimi
    • Qwen
    • MiniMax
    • Mistral
    • xAI (Grok)
• Advanced Setup
  • Langfuse Integration
  • Monitoring and Observability
  • Knowledge Graph (Graphiti)
  • OAuth Integration
  • Docker Image Configuration
• Development
• Testing LLM Agents
• Embedding Configuration and Testing
• Function Testing with ftester
• Building
• Credits
• License

Overview

PentAGI is an innovative tool for automated security testing that leverages cutting-edge artificial intelligence technologies. The project is designed for information security professionals, researchers, and enthusiasts who need a powerful and flexible solution for conducting penetration tests.

You can watch the video PentAGI overview:

Features

• Secure & Isolated. All operations are performed in a sandboxed Docker environment with complete isolation.
• Fully Autonomous. AI-powered agent that automatically determines and executes penetration testing steps with optional execution monitoring and intelligent task planning for enhanced reliability.
• Professional Pentesting Tools. Built-in suite of 20+ professional security tools including nmap, metasploit, sqlmap, and more.
• Smart Memory System. Long-term storage of research results and successful approaches for future use.
• Optional Knowledge Graph Integration. Graphiti-powered knowledge graph using Neo4j for semantic relationship tracking and advanced context understanding.
• Web Intelligence. Built-in browser via scraper for gathering latest information from web sources.
• External Search Systems. Integration with advanced search APIs including Tavily, Firecrawl, Traversaal, Perplexity, DuckDuckGo, Google Custom Search, Sploitus Search and Searxng for comprehensive information gathering.
• Team of Specialists. Delegation system with specialized AI agents for research, development, and infrastructure tasks, enhanced with optional execution monitoring and intelligent task planning for optimal performance with smaller models.
• Comprehensive Monitoring. Detailed logging and integration with Grafana/Prometheus for real-time system observation.
• Detailed Reporting. Generation of thorough vulnerability reports with exploitation guides.
• Smart Container Management. Automatic Docker image selection based on specific task requirements.
• Modern Interface. Clean and intuitive web UI for system management and monitoring.
• Comprehensive APIs. Full-featured REST and GraphQL APIs with Bearer token authentication for automation and integration.
• Persistent Storage. All commands and outputs are stored in PostgreSQL with pgvector extension.
• Scalable Architecture. Microservices-based design supporting horizontal scaling.
• Self-Hosted Solution. Complete control over your deployment and data.
• Flexible Authentication. Support for 10+ LLM providers (OpenAI, Anthropic, Google AI/Gemini, AWS Bedrock, Ollama, DeepSeek, GLM, Kimi, Qwen, MiniMax, Mistral, xAI, Custom for any OpenAI-compatible endpoint including Azure OpenAI) plus aggregators (OpenRouter, DeepInfra, Atlas Cloud, OpenCode Go plan). For production local deployments, see our vLLM + Qwen3.5-27B-FP8 guide.
• API Token Authentication. Secure Bearer token system for programmatic access to REST and GraphQL APIs.
• Quick Deployment. Easy setup through Docker Compose with comprehensive environment configuration.

Current Capability Boundaries

• PentAGI today is an autonomous and assistant-guided penetration testing platform, not a CALDERA-style Breach and Attack Simulation (BAS) or adversary emulation product with predefined campaigns or attack plans.
• BAS-like agent-authored attack scripts should be treated as conceptual or future work, not as a feature that is implemented today.
• The current flow report UI supports web view, copy to clipboard, Markdown download, and PDF download. JSON flow-report export is not documented as a supported output format today.
• Provider flexibility is available today through built-in providers and custom/OpenAI-compatible endpoints. See Custom LLM Provider Configuration and the vLLM + Qwen3.5-27B-FP8 guide.

Architecture

System Context

flowchart TB
    classDef person fill:#08427B,stroke:#073B6F,color:#fff
    classDef system fill:#1168BD,stroke:#0B4884,color:#fff
    classDef external fill:#666666,stroke:#0B4884,color:#fff

    pentester["👤 Security Engineer
    (User of the system)"]

    pentagi["✨ PentAGI
    (Autonomous penetration testing system)"]

    target["🎯 target-system
    (System under test)"]
    llm["🧠 llm-provider
    (OpenAI/Anthropic/Ollama/Bedrock/Gemini/Custom)"]
    search["🔍 search-systems
    (Google/DuckDuckGo/Tavily/Firecrawl/Traversaal/Perplexity/Sploitus/Searxng)"]
    langfuse["📊 langfuse-ui
    (LLM Observability Dashboard)"]
    grafana["📈 grafana
    (System Monitoring Dashboard)"]

    pentester --> |Uses HTTPS| pentagi
    pentester --> |Monitors AI HTTPS| langfuse
    pentester --> |Monitors System HTTPS| grafana
    pentagi --> |Tests Various protocols| target
    pentagi --> |Queries HTTPS| llm
    pentagi --> |Searches HTTPS| search
    pentagi --> |Reports HTTPS| langfuse
    pentagi --> |Reports HTTPS| grafana

    class pentester person
    class pentagi system
    class target,llm,search,langfuse,grafana external

    linkStyle default stroke:#ffffff,color:#ffffff

Container Architecture (click to expand)

graph TB
    subgraph Core Services
        UI[Frontend UI<br/>React + TypeScript]
        API[Backend API<br/>Go + GraphQL]
        DB[(Vector Store<br/>PostgreSQL + pgvector)]
        MQ[Task Queue<br/>Async Processing]
        Agent[AI Agents<br/>Multi-Agent System]
    end

    subgraph Knowledge Graph
        Graphiti[Graphiti<br/>Knowledge Graph API]
        Neo4j[(Neo4j<br/>Graph Database)]
    end

    subgraph Monitoring
        Grafana[Grafana<br/>Dashboards]
        VictoriaMetrics[VictoriaMetrics<br/>Time-series DB]
        Jaeger[Jaeger<br/>Distributed Tracing]
        Loki[Loki<br/>Log Aggregation]
        OTEL[OpenTelemetry<br/>Data Collection]
    end

    subgraph Analytics
        Langfuse[Langfuse<br/>LLM Analytics]
        ClickHouse[ClickHouse<br/>Analytics DB]
        Redis[Redis<br/>Cache + Rate Limiter]
        MinIO[MinIO<br/>S3 Storage]
    end

    subgraph Security Tools
        Scraper[Web Scraper<br/>Isolated Browser]
        PenTest[Security Tools<br/>20+ Pro Tools<br/>Sandboxed Execution]
    end

    UI --> |HTTP/WS| API
    API --> |SQL| DB
    API --> |Events| MQ
    MQ --> |Tasks| Agent
    Agent --> |Commands| PenTest
    Agent --> |Queries| DB
    Agent --> |Knowledge| Graphiti
    Graphiti --> |Graph| Neo4j

    API --> |Telemetry| OTEL
    OTEL --> |Metrics| VictoriaMetrics
    OTEL --> |Traces| Jaeger
    OTEL --> |Logs| Loki

    Grafana --> |Query| VictoriaMetrics
    Grafana --> |Query| Jaeger
    Grafana --> |Query| Loki

    API --> |Analytics| Langfuse
    Langfuse --> |Store| ClickHouse
    Langfuse --> |Cache| Redis
    Langfuse --> |Files| MinIO

    classDef core fill:#f9f,stroke:#333,stroke-width:2px,color:#000
    classDef knowledge fill:#ffa,stroke:#333,stroke-width:2px,color:#000
    classDef monitoring fill:#bbf,stroke:#333,stroke-width:2px,color:#000
    classDef analytics fill:#bfb,stroke:#333,stroke-width:2px,color:#000
    classDef tools fill:#fbb,stroke:#333,stroke-width:2px,color:#000

    class UI,API,DB,MQ,Agent core
    class Graphiti,Neo4j knowledge
    class Grafana,VictoriaMetrics,Jaeger,Loki,OTEL monitoring
    class Langfuse,ClickHouse,Redis,MinIO analytics
    class Scraper,PenTest tools

Entity Relationship (click to expand)

erDiagram
    Flow ||--o{ Task : contains
    Task ||--o{ SubTask : contains
    SubTask ||--o{ Action : contains
    Action ||--o{ Artifact : produces
    Action ||--o{ Memory : stores

    Flow {
        string id PK
        string name "Flow name"
        string description "Flow description"
        string status "active/completed/failed"
        json parameters "Flow parameters"
        timestamp created_at
        timestamp updated_at
    }

    Task {
        string id PK
        string flow_id FK
        string name "Task name"
        string description "Task description"
        string status "pending/running/done/failed"
        json result "Task results"
        timestamp created_at
        timestamp updated_at
    }

    SubTask {
        string id PK
        string task_id FK
        string name "Subtask name"
        string description "Subtask description"
        string status "queued/running/completed/failed"
        string agent_type "researcher/developer/executor"
        json context "Agent context"
        timestamp created_at
        timestamp updated_at
    }

    Action {
        string id PK
        string subtask_id FK
        string type "command/search/analyze/etc"
        string status "success/failure"
        json parameters "Action parameters"
        json result "Action results"
        timestamp created_at
    }

    Artifact {
        string id PK
        string action_id FK
        string type "file/report/log"
        string path "Storage path"
        json metadata "Additional info"
        timestamp created_at
    }

    Memory {
        string id PK
        string action_id FK
        string type "observation/conclusion"
        vector embedding "Vector representation"
        text content "Memory content"
        timestamp created_at
    }

Agent Interaction (click to expand)

sequenceDiagram
    participant O as Orchestrator
    participant R as Researcher
    participant D as Developer
    participant E as Executor
    participant VS as Vector Store
    participant KB as Knowledge Base

    Note over O,KB: Flow Initialization
    O->>VS: Query similar tasks
    VS-->>O: Return experiences
    O->>KB: Load relevant knowledge
    KB-->>O: Return context

    Note over O,R: Research Phase
    O->>R: Analyze target
    R->>VS: Search similar cases
    VS-->>R: Return patterns
    R->>KB: Query vulnerabilities
    KB-->>R: Return known issues
    R->>VS: Store findings
    R-->>O: Research results

    Note over O,D: Planning Phase
    O->>D: Plan attack
    D->>VS: Query exploits
    VS-->>D: Return techniques
    D->>KB: Load tools info
    KB-->>D: Return capabilities
    D-->>O: Attack plan

    Note over O,E: Execution Phase
    O->>E: Execute plan
    E->>KB: Load tool guides
    KB-->>E: Return procedures
    E->>VS: Store results
    E-->>O: Execution status

Memory System (click to expand)

graph TB
    subgraph "Long-term Memory"
        VS[(Vector Store<br/>Embeddings DB)]
        KB[Knowledge Base<br/>Domain Expertise]
        Tools[Tools Knowledge<br/>Usage Patterns]
    end

    subgraph "Working Memory"
        Context[Current Context<br/>Task State]
        Goals[Active Goals<br/>Objectives]
        State[System State<br/>Resources]
    end

    subgraph "Episodic Memory"
        Actions[Past Actions<br/>Commands History]
        Results[Action Results<br/>Outcomes]
        Patterns[Success Patterns<br/>Best Practices]
    end

    Context --> |Query| VS
    VS --> |Retrieve| Context

    Goals --> |Consult| KB
    KB --> |Guide| Goals

    State --> |Record| Actions
    Actions --> |Learn| Patterns
    Patterns --> |Store| VS

    Tools --> |Inform| State
    Results --> |Update| Tools

    VS --> |Enhance| KB
    KB --> |Index| VS

    classDef ltm fill:#f9f,stroke:#333,stroke-width:2px,color:#000
    classDef wm fill:#bbf,stroke:#333,stroke-width:2px,color:#000
    classDef em fill:#bfb,stroke:#333,stroke-width:2px,color:#000

    class VS,KB,Tools ltm
    class Context,Goals,State wm
    class Actions,Results,Patterns em

Chain Summarization (click to expand)

The chain summarization system manages conversation context growth by selectively summarizing older messages. This is critical for preventing token limits from being exceeded while maintaining conversation coherence.

flowchart TD
    A[Input Chain] --> B{Needs Summarization?}
    B -->|No| C[Return Original Chain]
    B -->|Yes| D[Convert to ChainAST]
    D --> E[Apply Section Summarization]
    E --> F[Process Oversized Pairs]
    F --> G[Manage Last Section Size]
    G --> H[Apply QA Summarization]
    H --> I[Rebuild Chain with Summaries]
    I --> J{Is New Chain Smaller?}
    J -->|Yes| K[Return Optimized Chain]
    J -->|No| C

    classDef process fill:#bbf,stroke:#333,stroke-width:2px,color:#000
    classDef decision fill:#bfb,stroke:#333,stroke-width:2px,color:#000
    classDef output fill:#fbb,stroke:#333,stroke-width:2px,color:#000

    class A,D,E,F,G,H,I process
    class B,J decision
    class C,K output

The algorithm operates on a structured representation of conversation chains (ChainAST) that preserves message types including tool calls and their responses. All summarization operations maintain critical conversation flow while reducing context size.

Global Summarizer Configuration Options

Parameter	Environment Variable	Default	Description
Preserve Last	SUMMARIZER_PRESERVE_LAST	true	Whether to keep all messages in the last section intact
Use QA Pairs	SUMMARIZER_USE_QA	true	Whether to use QA pair summarization strategy
Summarize Human in QA	SUMMARIZER_SUM_MSG_HUMAN_IN_QA	false	Whether to summarize human messages in QA pairs
Last Section Size	SUMMARIZER_LAST_SEC_BYTES	51200	Maximum byte size for last section (50KB)
Max Body Pair Size	SUMMARIZER_MAX_BP_BYTES	16384	Maximum byte size for a single body pair (16KB)
Max QA Sections	SUMMARIZER_MAX_QA_SECTIONS	10	Maximum QA pair sections to preserve
Max QA Size	SUMMARIZER_MAX_QA_BYTES	65536	Maximum byte size for QA pair sections (64KB)
Keep QA Sections	SUMMARIZER_KEEP_QA_SECTIONS	1	Number of recent QA sections to keep without summarization

Assistant Summarizer Configuration Options

Assistant instances can use customized summarization settings to fine-tune context management behavior:

Parameter	Environment Variable	Default	Description
Preserve Last	ASSISTANT_SUMMARIZER_PRESERVE_LAST	true	Whether to preserve all messages in the assistant's last section
Last Section Size	ASSISTANT_SUMMARIZER_LAST_SEC_BYTES	76800	Maximum byte size for assistant's last section (75KB)
Max Body Pair Size	ASSISTANT_SUMMARIZER_MAX_BP_BYTES	16384	Maximum byte size for a single body pair in assistant context (16KB)
Max QA Sections	ASSISTANT_SUMMARIZER_MAX_QA_SECTIONS	7	Maximum QA sections to preserve in assistant context
Max QA Size	ASSISTANT_SUMMARIZER_MAX_QA_BYTES	76800	Maximum byte size for assistant's QA sections (75KB)
Keep QA Sections	ASSISTANT_SUMMARIZER_KEEP_QA_SECTIONS	3	Number of recent QA sections to preserve without summarization

The assistant summarizer configuration provides more memory for context retention compared to the global settings, preserving more recent conversation history while still ensuring efficient token usage.

Summarizer Environment Configuration

# Default values for global summarizer logic
SUMMARIZER_PRESERVE_LAST=true
SUMMARIZER_USE_QA=true
SUMMARIZER_SUM_MSG_HUMAN_IN_QA=false
SUMMARIZER_LAST_SEC_BYTES=51200
SUMMARIZER_MAX_BP_BYTES=16384
SUMMARIZER_MAX_QA_SECTIONS=10
SUMMARIZER_MAX_QA_BYTES=65536
SUMMARIZER_KEEP_QA_SECTIONS=1

# Default values for assistant summarizer logic
ASSISTANT_SUMMARIZER_PRESERVE_LAST=true
ASSISTANT_SUMMARIZER_LAST_SEC_BYTES=76800
ASSISTANT_SUMMARIZER_MAX_BP_BYTES=16384
ASSISTANT_SUMMARIZER_MAX_QA_SECTIONS=7
ASSISTANT_SUMMARIZER_MAX_QA_BYTES=76800
ASSISTANT_SUMMARIZER_KEEP_QA_SECTIONS=3

Advanced Agent Supervision (click to expand)

PentAGI includes sophisticated multi-layered agent supervision mechanisms to ensure efficient task execution, prevent infinite loops, and provide intelligent recovery from stuck states:

Execution Monitoring (Beta)

• Automatic Mentor Intervention: Adviser agent (mentor) is automatically invoked when execution patterns indicate potential issues
• Pattern Detection: Monitors identical tool calls (threshold: 5, configurable) and total tool calls (threshold: 10, configurable)
• Progress Analysis: Evaluates whether agent advances toward subtask objective, detects loops and inefficiencies
• Alternative Strategies: Recommends different approaches when current strategy fails
• Information Retrieval Guidance: Suggests searching for established solutions instead of reinventing
• Enhanced Response Format: Tool responses include both <original_result> and <mentor_analysis> sections
• Configurable: Enable via EXECUTION_MONITOR_ENABLED (default: false), customize thresholds with EXECUTION_MONITOR_SAME_TOOL_LIMIT and EXECUTION_MONITOR_TOTAL_TOOL_LIMIT

Best for: Smaller models (< 32B parameters), complex attack scenarios requiring continuous guidance, preventing agents from getting stuck on single approach

Performance Impact: 2-3x increase in execution time and token usage, but delivers 2x improvement in result quality based on testing with Qwen3.5-27B-FP8

Intelligent Task Planning (Beta)

• Automated Decomposition: Planner (adviser in planning mode) generates 3-7 specific, actionable steps before specialist agents begin work
• Context-Aware Plans: Analyzes full execution context via enricher agent to create informed plans
• Structured Assignment: Original request wrapped in <task_assignment> structure with execution plan and instructions
• Scope Management: Prevents scope creep by keeping agents focused on current subtask only
• Enriched Instructions: Plans highlight critical actions, potential pitfalls, and verification points
• Configurable: Enable via AGENT_PLANNING_STEP_ENABLED (default: false)

Best for: Models < 32B parameters, complex penetration testing workflows, improving success rates on sophisticated tasks

Enhanced Adviser Configuration: Works exceptionally well when adviser agent uses stronger model or enhanced settings. Example: using same base model with maximum reasoning mode for adviser (see vllm-qwen3.5-27b-fp8.provider.yml) enables comprehensive task analysis and strategic planning from identical model architecture.

Performance Impact: Adds planning overhead but significantly improves completion rates and reduces redundant work

Tool Call Limits (Always Active)

• Hard Limits: Prevent runaway executions regardless of supervision mode status
• Differentiated by Agent Type:
  • General agents (Assistant, Primary Agent, Pentester, Coder, Installer): MAX_GENERAL_AGENT_TOOL_CALLS (default: 100)
  • Limited agents (Searcher, Enricher, Memorist, Generator, Reporter, Adviser, Reflector, Planner): MAX_LIMITED_AGENT_TOOL_CALLS (default: 20)
• Graceful Termination: Reflector guides agents to proper completion when approaching limits
• Resource Protection: Ensures system stability and prevents resource exhaustion

Reflector Integration (Always Active)

• Automatic Correction: Invoked when LLM fails to generate tool calls after 3 attempts
• Strategic Guidance: Analyzes failures and guides agents toward proper tool usage or barrier tools (done, ask)
• Recovery Mechanism: Provides contextual guidance based on specific failure patterns
• Limit Enforcement: Coordinates graceful termination when tool call limits are reached

Recommendations for Open Source Models

Must-Have for Models < 32B Parameters: Testing with Qwen3.5-27B-FP8 demonstrates that enabling both Execution Monitoring and Task Planning is essential for smaller open source models:

• Quality Improvement: 2x better results compared to baseline execution without supervision
• Loop Prevention: Significantly reduces infinite loops and redundant work
• Attack Diversity: Encourages exploration of multiple attack vectors instead of fixating on single approach
• Air-Gapped Deployments: Enables production-grade autonomous pentesting in closed network environments with local LLM inference

Trade-offs:

• Token consumption: 2-3x increase due to mentor/planner invocations
• Execution time: 2-3x longer due to analysis and planning steps
• Result quality: 2x improvement in completeness, accuracy, and attack coverage
• Model requirements: Works best when adviser uses enhanced configuration (higher reasoning parameters, stronger model variant, or different model)

Configuration Strategy: For optimal performance with smaller models, configure adviser agent with enhanced settings:

• Use same model with maximum reasoning mode (example: vllm-qwen3.5-27b-fp8.provider.yml)
• Or use stronger model for adviser while keeping base model for other agents
• Adjust monitoring thresholds based on task complexity and model capabilities

The architecture of PentAGI is designed to be modular, scalable, and secure. Here are the key components:

1. Core Services

   • Frontend UI: React-based web interface with TypeScript for type safety
   • Backend API: Go-based REST and GraphQL APIs with Bearer token authentication for programmatic access
   • Vector Store: PostgreSQL with pgvector for semantic search and memory storage
   • Task Queue: Async task processing system for reliable operation
   • AI Agent: Multi-agent system with specialized roles for efficient testing

2. Optional Knowledge Graph

   • Graphiti: Knowledge graph API for semantic relationship tracking and contextual understanding
   • Neo4j: Graph database for storing and querying relationships between entities, actions, and outcomes
   • When enabled, automatically captures agent responses and tool executions for a flow-scoped knowledge base

3. Monitoring Stack

   • OpenTelemetry: Unified observability data collection and correlation
   • Grafana: Real-time visualization and alerting dashboards
   • VictoriaMetrics: High-performance time-series metrics storage
   • Jaeger: End-to-end distributed tracing for debugging
   • Loki: Scalable log aggregation and analysis

4. Analytics Platform

   • Langfuse: Advanced LLM observability and performance analytics
   • ClickHouse: Column-oriented analytics data warehouse
   • Redis: High-speed caching and rate limiting
   • MinIO: S3-compatible object storage for artifacts

5. Security Tools

   • Web Scraper: Isolated browser environment for safe web interaction
   • Pentesting Tools: Comprehensive suite of 20+ professional security tools
   • Sandboxed Execution: All operations run in isolated containers

6. Memory Systems

   • Long-term Memory: Persistent storage of knowledge and experiences
   • Working Memory: Active context and goals for current operations
   • Episodic Memory: Historical actions and success patterns
   • Knowledge Base: Structured domain expertise and tool capabilities
   • Context Management: Intelligently manages growing LLM context windows using chain summarization

The system uses Docker containers for isolation and easy deployment, with separate networks for core services, monitoring, and analytics to ensure proper security boundaries. Each component is designed to scale horizontally and can be configured for high availability in production environments.

Quick Start

For a step-by-step walkthrough that connects installation, configuration, LLM and embedding provider testing, and your first login, see the Installing and Configuring PentAGI guide. The sections below remain the detailed reference for each step.

System Requirements

• Docker and Docker Compose (or Podman - see Podman configuration)
• Minimum 2 vCPU
• Minimum 4GB RAM
• 20GB free disk space
• Internet access for downloading images and updates

Using Installer (Recommended)

PentAGI provides an interactive installer with a terminal-based UI for streamlined configuration and deployment. The installer guides you through system checks, LLM provider setup, search engine configuration, and security hardening.

Supported Platforms:

• Linux: amd64 download | arm64 download
• Windows: amd64 download
• macOS: amd64 (Intel) download | arm64 (M-series) download

macOS security warning: If macOS flags a downloaded installer, use only the official PentAGI links above, choose the archive that matches your CPU architecture, verify the source before continuing, and follow the installer troubleshooting guide before allowing the app to run.

Quick Installation (Linux amd64):

# Create installation directory
mkdir -p pentagi && cd pentagi

# Download installer
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip

# Extract
unzip installer.zip

# Run interactive installer
./installer

Prerequisites & Permissions:

The installer requires appropriate privileges to interact with the Docker API for proper operation. By default, it uses the Docker socket (/var/run/docker.sock) which requires either:

• Option 1 (Recommended for production): Run the installer as root:

  sudo ./installer
  

• Option 2 (Development environments): Grant your user access to the Docker socket by adding them to the docker group:

  # Add your user to the docker group
  sudo usermod -aG docker $USER
  
  # Log out and log back in, or activate the group immediately
  newgrp docker
  
  # Verify Docker access (should run without sudo)
  docker ps
  

  ⚠️ Security Note: Adding a user to the docker group grants root-equivalent privileges. Only do this for trusted users in controlled environments. For production deployments, consider using rootless Docker mode or running the installer with sudo.

The installer will:

1. System Checks: Verify Docker, network connectivity, and system requirements
2. Environment Setup: Create and configure .env file with optimal defaults
3. Provider Configuration: Set up LLM providers (OpenAI, Anthropic, Gemini, Bedrock, Ollama, DeepSeek, GLM, Kimi, Qwen, MiniMax, Mistral, xAI, Custom)
4. Search Engines: Configure DuckDuckGo, Google, Tavily, Firecrawl, Traversaal, Perplexity, Sploitus, Searxng, and the optional internal browser-analytics fallback engine
5. Security Hardening: Generate secure credentials and configure SSL certificates
6. Deployment: Start PentAGI with docker-compose

Current Web Settings Coverage

The PentAGI web console already manages several settings areas after the server is up and running:

• Settings -> Providers: Create, edit, delete, and test user-defined provider profiles for supported provider types. These profiles control per-agent model selection, runtime parameters, reasoning options, and pricing metadata.
• Settings -> Prompts: Manage system, human, and tool prompt templates.
• Settings -> PentAGI API: Create and manage PentAGI Bearer tokens for REST and GraphQL access.
• Other UI-managed preferences: Favorite flows are stored as user preferences, and theme selection is handled from the main sidebar/profile controls rather than the Settings pages.

Still Server-Managed

The following configuration areas still need to be set on the server through environment variables, compose files, or mounted config files:

• LLM credentials and connection details: API keys, endpoints, auth modes, and provider-specific connection settings for OpenAI, Anthropic, Bedrock, Ollama, custom providers, and similar backends; config-path settings apply only where supported, such as OLLAMA_SERVER_CONFIG_PATH and LLM_SERVER_CONFIG_PATH.
• Search provider credentials and options: Settings such as DUCKDUCKGO_*, GOOGLE_*, TAVILY_API_KEY, FIRECRAWL_API_*, TRAVERSAAL_API_KEY, PERPLEXITY_*, SEARXNG_*, SPLOITUS_ENABLED, and the optional WEB_SEARCH_INTERNAL_* browser-analytics fallback settings.
• Third-party integrations: Langfuse, Graphiti, and similar external services remain server-side configuration.
• MCP server management: MCP settings pages are not currently exposed as a live web-console feature.

For Production & Enhanced Security:

For production deployments or security-sensitive environments, we strongly recommend using a distributed two-node architecture where worker operations are isolated on a separate server. This prevents untrusted code execution and network access issues on your main system.

See detailed guide: Worker Node Setup

The two-node setup provides:

• Isolated Execution: Worker containers run on dedicated hardware
• Network Isolation: Separate network boundaries for penetration testing
• Security Boundaries: Docker-in-Docker with TLS authentication
• OOB Attack Support: Dedicated port ranges for out-of-band techniques

Giving Agents Docker Without Giving Away the Host

Many pentest workflows need docker inside the agent's sandbox. There are two ways to provide it, and they differ sharply in risk.

Recommended — point sandboxes at a hardened dind daemon over TLS. Set DOCKER_INSIDE=true, leave DOCKER_SOCKET empty, and configure the daemon the sandbox may talk to:

DOCKER_INSIDE=true
DOCKER_SOCKET=                                          # mount no socket
DOCKER_INSIDE_HOST=tcp://10.0.0.5:3376                  # hardened dind endpoint
DOCKER_INSIDE_TLS_VERIFY=1
DOCKER_INSIDE_CERT_PATH=/etc/docker/dind/certs/client   # path on the worker node
DOCKER_INSIDE_POLICY_TESTS=true                         # prove it on every worker; off by default

PentAGI injects these into every worker container as DOCKER_HOST, DOCKER_TLS_VERIFY and DOCKER_CERT_PATH (the _INSIDE_ segment is dropped) and bind-mounts the certificate directory read-only at the same path, so docker works inside the sandbox with no further setup.

Not recommended — bind-mounting a Docker socket (DOCKER_SOCKET). This has two failure modes:

• Boot-order race: a bind-mount source that does not exist yet is created by Docker as a directory. After a worker-node reboot, a worker container can start before dind has recreated its socket — Docker then puts a directory where the socket belongs, and dind cannot start until it is removed by hand.
• Blast radius: the race is only reliably avoided when the mounted socket is the host daemon's, since that one always exists first. But that grants an autonomous agent the host Docker API: it can start a privileged container, mount /, and compromise the entire node — PentAGI included.

Use DOCKER_SOCKET only on single-node development setups where the host daemon is already trusted.

See: Worker Node Setup for the full dind hardening and TLS configuration, and Worker Docker Access for the exact resolution algorithm.

Running Several Instances (TENANT_ID)

A single PentAGI installation needs none of this — leave TENANT_ID empty (the default) and nothing changes.

Set it when several PentAGI installations share external resources: one PostgreSQL server, one worker node, one Neo4j/Graphiti, one Langfuse. The typical case is a management backend per server with a common worker node and database. Because every instance numbers its flows from 1, they would otherwise collide on container names, database rows, knowledge-graph namespaces and session cookies. TENANT_ID namespaces all of it:

Area	Effect when TENANT_ID=acme
PostgreSQL	The instance creates and works inside schema acme instead of public; extensions stay shared in DATABASE_EXTENSIONS_SCHEMA (default public, extensions on Supabase)
Worker containers	acme-pentagi-terminal-<flow> instead of pentagi-terminal-<flow>; volumes and hostnames follow, and both carry a pentagi.tenant label
Knowledge graph	Graphiti/Neo4j group ids become acme-flow-<id>
Auth	Cookie and API token keys are derived from COOKIE_SIGNING_SALT plus the tenant, and the session cookie is renamed
Telemetry	Langfuse traces carry the tenant as their environment and a tenant:acme tag; OTel resources gain tenant_id

The value must match ^[a-z][a-z0-9_]{0,31}$ — an invalid one aborts startup rather than being silently normalised.

Some things stay yours to set per instance, because they are host resources rather than names: DATA_DIR (two instances sharing it will overwrite each other's flow data), DOCKER_PORTS_BASE, the published ports, and INSTALLATION_ID. The effective values are printed at startup under Instance identity.

The installer provisions one instance per server. Running several on one server is possible — for example behind a shared nginx — but the stock docker-compose.yml uses fixed container and network names, so it has to be adapted to your own network layout first.

See: Multi-Instance Deployment for validation rules, upgrade notes and the full list of operator responsibilities.

Manual Installation

1. Create a working directory or clone the repository:

mkdir pentagi && cd pentagi

2. Copy .env.example to .env or download it:

curl -o .env https://raw.githubusercontent.com/vxcontrol/pentagi/master/.env.example

3. Touch examples files (example.custom.provider.yml, example.ollama.provider.yml) or download it:

curl -o example.custom.provider.yml https://raw.githubusercontent.com/vxcontrol/pentagi/master/examples/configs/custom-openai.provider.yml
curl -o example.ollama.provider.yml https://raw.githubusercontent.com/vxcontrol/pentagi/master/examples/configs/ollama-llama318b.provider.yml

4. Fill in the required API keys in .env file.

# Required: At least one of these LLM providers
OPEN_AI_KEY=your_openai_key
ANTHROPIC_API_KEY=your_anthropic_key
GEMINI_API_KEY=your_gemini_key

# Optional: AWS Bedrock provider (enterprise-grade models)
BEDROCK_REGION=us-east-1
# Choose one authentication method:
BEDROCK_DEFAULT_AUTH=true                        # Option 1: Use AWS SDK default credential chain (recommended for EC2/ECS)
# BEDROCK_BEARER_TOKEN=your_bearer_token         # Option 2: Bearer token authentication
# BEDROCK_ACCESS_KEY_ID=your_aws_access_key      # Option 3: Static credentials
# BEDROCK_SECRET_ACCESS_KEY=your_aws_secret_key

# Optional: Ollama provider (local or cloud)
# OLLAMA_SERVER_URL=http://ollama-server:11434   # Local server
# OLLAMA_SERVER_URL=https://ollama.com           # Cloud service
# OLLAMA_SERVER_API_KEY=your_ollama_cloud_key    # Required for cloud, empty for local

# Optional: Chinese AI providers
# DEEPSEEK_API_KEY=your_deepseek_key             # DeepSeek (strong reasoning)
# GLM_API_KEY=your_glm_key                       # GLM (Zhipu AI)
# KIMI_API_KEY=your_kimi_key                     # Kimi (Moonshot AI, ultra-long context)
# QWEN_API_KEY=your_qwen_key                     # Qwen (Alibaba Cloud, multimodal)
# MINIMAX_API_KEY=your_minimax_key               # MiniMax

# Optional: European and US providers
# MISTRAL_API_KEY=your_mistral_key               # Mistral
# XAI_API_KEY=your_xai_key                       # xAI (Grok)

# Optional: Local LLM provider (zero-cost inference)
OLLAMA_SERVER_URL=http://localhost:11434
OLLAMA_SERVER_MODEL=your_model_name

# Optional: Additional search capabilities
DUCKDUCKGO_ENABLED=true
DUCKDUCKGO_REGION=us-en
DUCKDUCKGO_SAFESEARCH=
DUCKDUCKGO_TIME_RANGE=
SPLOITUS_ENABLED=true
GOOGLE_API_KEY=your_google_key
GOOGLE_CX_KEY=your_google_cx
TAVILY_API_KEY=your_tavily_key
FIRECRAWL_API_KEY=your_firecrawl_key
FIRECRAWL_API_URL=
TRAVERSAAL_API_KEY=your_traversaal_key
PERPLEXITY_API_KEY=your_perplexity_key
PERPLEXITY_MODEL=
PERPLEXITY_CONTEXT_SIZE=medium

# Searxng meta search engine (aggregates results from multiple sources)
SEARXNG_URL=http://your-searxng-instance:8080
SEARXNG_CATEGORIES=general
SEARXNG_LANGUAGE=
SEARXNG_SAFESEARCH=0
SEARXNG_TIME_RANGE=
SEARXNG_TIMEOUT=

# Optional: internal browser-analytics fallback engine for web_search (off by default;
# scrapes and summarizes pages instead of calling a paid analytic API)
WEB_SEARCH_INTERNAL_ENABLED=false
WEB_SEARCH_INTERNAL_MAX_SITES=5
WEB_SEARCH_INTERNAL_MAX_SITE_BYTES=10240

## Graphiti knowledge graph settings
GRAPHITI_ENABLED=false
GRAPHITI_TIMEOUT=30
GRAPHITI_URL=

# Neo4j settings (used by Graphiti stack)
NEO4J_USER=neo4j
NEO4J_DATABASE=neo4j
NEO4J_PASSWORD=devpassword
NEO4J_URI=bolt://neo4j:7687

# Assistant configuration
ASSISTANT_USE_AGENTS=false         # Default value for agent usage when creating new assistants

5. Change all security related environment variables in .env file to improve security.

Security related environment variables

Main Security Settings

• COOKIE_SIGNING_SALT - Salt for cookie signing, change to random value
• PUBLIC_URL - Public URL of your server (eg. https://pentagi.example.com)
• SERVER_SSL_CRT and SERVER_SSL_KEY - Custom paths to your existing SSL certificate and key for HTTPS (these paths should be used in the docker-compose.yml file to mount as volumes)
• TENANT_ID - Leave empty unless this instance shares external resources with another PentAGI installation. When set, it is mixed into the cookie and API token signing keys and renames the session cookie, so a session minted by one instance is rejected by the others even though they share the same COOKIE_SIGNING_SALT. See Running Several Instances

Scraper Access

• SCRAPER_PUBLIC_URL - Public URL for scraper if you want to use different scraper server for public URLs
• SCRAPER_PRIVATE_URL - Private URL for scraper (local scraper server in docker-compose.yml file to access it to local URLs)

Access Credentials

• PENTAGI_POSTGRES_USER and PENTAGI_POSTGRES_PASSWORD - PostgreSQL credentials
• NEO4J_USER and NEO4J_PASSWORD - Neo4j credentials (for Graphiti knowledge graph)

6. Remove all inline comments from .env file if you want to use it in VSCode or other IDEs as a envFile option:

perl -i -pe 's/\s+#.*$//' .env

7. Run the PentAGI stack:

curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose.yml
docker compose up -d

Visit localhost:8443 to access PentAGI Web UI (default is admin@pentagi.com / admin)

Web UI Accounts

PentAGI does not expose public self-service sign-up from the login page. A fresh installation creates the default local administrator account:

• Email: admin@pentagi.com
• Password: admin

On first login, change the default password before using the instance for real work. If the administrator password is lost later, use the installer maintenance menu to reset the default admin@pentagi.com account password.

For multi-user setups, an authenticated administrator can manage local users through the Users REST API (/api/v1/users/). The OpenAPI UI is available at https://localhost:8443/api/v1/swagger/index.html after the instance is running.

Note

If you caught an error about pentagi-network or observability-network or langfuse-network you need to run docker-compose.yml firstly to create these networks and after that run docker-compose-langfuse.yml, docker-compose-graphiti.yml, and docker-compose-observability.yml to use Langfuse, Graphiti, and Observability services.

You have to set at least one Language Model provider (OpenAI, Anthropic, Gemini, AWS Bedrock, or Ollama) to use PentAGI. AWS Bedrock provides enterprise-grade access to multiple foundation models from leading AI companies, while Ollama provides zero-cost local inference if you have sufficient computational resources. Additional API keys for search engines are optional but recommended for better results.

For fully local deployment with advanced models: See our comprehensive guide on Running PentAGI with vLLM and Qwen3.5-27B-FP8 for a production-grade local LLM setup. This configuration achieves ~13,000 TPS for prompt processing and ~650 TPS for completion on 4× RTX 5090 GPUs, supporting 12+ concurrent flows with complete independence from cloud providers.

LLM_SERVER_* environment variables are experimental feature and will be changed in the future. Right now you can use them to specify custom LLM server URL and one model for all agent types.

PROXY_URL is a global proxy URL for all LLM providers and external search systems. You can use it for isolation from external networks.

The docker-compose.yml file runs the PentAGI service as root user because it needs access to docker.sock for container management. If you're using TCP/IP network connection to Docker instead of socket file, you can remove root privileges and use the default pentagi user for better security.

Accessing PentAGI from External Networks

By default, PentAGI binds to 127.0.0.1 (localhost only) for security. To access PentAGI from other machines on your network, you need to configure external access.

Configuration Steps

1. Update .env file with your server's IP address:

# Network binding - allow external connections
PENTAGI_LISTEN_IP=0.0.0.0
PENTAGI_LISTEN_PORT=8443

# Public URL - use your actual server IP or hostname
# Replace 192.168.1.100 with your server's IP address
PUBLIC_URL=https://192.168.1.100:8443

# CORS origins - list all URLs that will access PentAGI
# Include localhost for local access AND your server IP for external access
CORS_ORIGINS=https://localhost:8443,https://192.168.1.100:8443

Important

• Replace 192.168.1.100 with your actual server's IP address
• Do NOT use 0.0.0.0 in PUBLIC_URL or CORS_ORIGINS - use the actual IP address
• Include both localhost and your server IP in CORS_ORIGINS for flexibility

2. Recreate containers to apply the changes:

docker compose down
docker compose up -d --force-recreate

3. Verify port binding:

docker ps | grep pentagi

You should see 0.0.0.0:8443->8443/tcp or :::8443->8443/tcp.

If you see 127.0.0.1:8443->8443/tcp, the environment variable wasn't picked up. In this case, directly edit docker-compose.yml line 31:

ports:
  - "0.0.0.0:8443:8443"

Then recreate containers again.

4. Configure firewall to allow incoming connections on port 8443:

# Ubuntu/Debian with UFW
sudo ufw allow 8443/tcp
sudo ufw reload

# CentOS/RHEL with firewalld
sudo firewall-cmd --permanent --add-port=8443/tcp
sudo firewall-cmd --reload

5. Access PentAGI:

• Local access: https://localhost:8443
• Network access: https://your-server-ip:8443

Note

You'll need to accept the self-signed SSL certificate warning in your browser when accessing via IP address.

---

Running PentAGI with Podman

PentAGI fully supports Podman as a Docker alternative. However, when using Podman in rootless mode, the scraper service requires special configuration because rootless containers cannot bind privileged ports (ports below 1024).

Podman Rootless Configuration

The default scraper configuration uses port 443 (HTTPS), which is a privileged port. For Podman rootless, reconfigure the scraper to use a non-privileged port:

1. Edit docker-compose.yml - modify the scraper service (around line 199):

scraper:
  image: vxcontrol/scraper:latest
  restart: unless-stopped
  container_name: scraper
  hostname: scraper
  expose:
    - 3000/tcp  # Changed from 443 to 3000
  ports:
    - "${SCRAPER_LISTEN_IP:-127.0.0.1}:${SCRAPER_LISTEN_PORT:-9443}:3000"  # Map to port 3000
  environment:
    - MAX_CONCURRENT_SESSIONS=${LOCAL_SCRAPER_MAX_CONCURRENT_SESSIONS:-10}
    - USERNAME=${LOCAL_SCRAPER_USERNAME:-someuser}
    - PASSWORD=${LOCAL_SCRAPER_PASSWORD:-somepass}
  logging:
    options:
      max-size: 50m
      max-file: "7"
  volumes:
    - scraper-ssl:/usr/src/app/ssl
  networks:
    - pentagi-network
  shm_size: 2g

2. Update .env file - change the scraper URL to use HTTP and port 3000:

# Scraper configuration for Podman rootless
SCRAPER_PRIVATE_URL=http://someuser:somepass@scraper:3000/
LOCAL_SCRAPER_USERNAME=someuser
LOCAL_SCRAPER_PASSWORD=somepass

Important

Key changes for Podman:

• Use HTTP instead of HTTPS for SCRAPER_PRIVATE_URL
• Use port 3000 instead of 443
• Change internal expose to 3000/tcp
• Update port mapping to target 3000 instead of 443

3. Recreate containers:

podman-compose down
podman-compose up -d --force-recreate

4. Test scraper connectivity:

# Test from within the pentagi container
podman exec -it pentagi wget -O- "http://someuser:somepass@scraper:3000/html?url=http://example.com"

If you see HTML output, the scraper is working correctly.

Podman Rootful Mode

If you're running Podman in rootful mode (with sudo), you can use the default configuration without modifications. The scraper will work on port 443 as intended.

Docker Compatibility

All Podman configurations remain fully compatible with Docker. The non-privileged port approach works identically on both container runtimes.

Assistant Configuration

PentAGI allows you to configure default behavior for assistants:

Variable	Default	Description
ASSISTANT_USE_AGENTS	false	Controls the default value for agent usage when creating new assistants

The ASSISTANT_USE_AGENTS setting affects the initial state of the "Use Agents" toggle when creating a new assistant in the UI:

• false (default): New assistants are created with agent delegation disabled by default
• true: New assistants are created with agent delegation enabled by default

Note that users can always override this setting by toggling the "Use Agents" button in the UI when creating or editing an assistant. This environment variable only controls the initial default state.

How to Use PentAGI After Login

Once the stack is running and you can sign in to the web UI, the fastest way to start is through the Flows workflow.

1. Create your first flow

1. Open Flows in the sidebar.
2. Click New Flow.
3. Choose the mode that fits your goal:
   • Automation: fully autonomous execution for a testing goal you want PentAGI to carry out end-to-end
   • Assistant: interactive back-and-forth help when you want to steer the investigation step by step. In this mode you can also enable the Use Agents toggle to let PentAGI delegate subtasks to specialized sub-agents for more complex investigations.
4. Select the LLM provider you want to use for this flow.
5. Describe the target and the objective in natural language in the message box.

Good first prompts usually include:

• the target system or URL
• the type of assessment you want
• any scope limitations or rules of engagement
• the result you expect, such as a vulnerability report or validation of a hypothesis

Example:

Assess https://target.example for common web application vulnerabilities. Focus on authentication, file handling, and injection issues. Stay within the provided target only and summarize confirmed findings with reproduction steps.

Only test systems you own or are explicitly authorized to assess. See EULA.md for the acceptable use requirements.

2. Use templates for repeatable workflows

The new flow form includes a template picker, which can prefill the message box with a saved flow template. This is useful when you run similar assessments repeatedly.

• Use an existing template if you already have one saved in Templates
• Start from the example prompt in examples/prompts/base_web_pentest.md if you need a practical baseline for web testing
• Adjust the target, scope, and constraints before starting the flow

Templates are starting points. You do not need special syntax to use PentAGI: plain natural-language instructions work well as long as the target and goal are clear.

3. Monitor execution and review output

After submitting the flow, PentAGI opens the flow page automatically.

• Use the main flow view to follow messages, agent activity, and task progress
• Inspect tool activity and terminal output as the flow runs
• Review generated tasks and subtasks to understand what PentAGI is doing

Once the flow has enough results, use the Report menu on the flow page to:

• open the report in a web view
• copy the generated report to the clipboard
• download the report as Markdown
• download the report as PDF

4. Use the Assistant view to steer an active flow

Each flow also includes an Assistant view for interactive guidance. This is useful when the autonomous run uncovers something that needs human direction instead of a hard restart.

• Open the Assistant view for the same flow when you want to inspect the current state before changing anything.
• Use the assistant to check flow status, stop the current task, submit follow-up instructions, or patch the remaining planned subtasks before the next step runs.
• Treat this as an explicit control path for the current flow, not as an invisible background queue. If you want to change direction, say so clearly and keep the new instruction tied to the current engagement scope.
• This works best for clarifying scope, redirecting priorities after intermediate findings, or answering an automation checkpoint without losing the rest of the flow context.

5. Manage flow-scoped files

Each flow has its own Files tab in the flow page. Files are scoped to the parent flow: they live in {dataDir}/flow-{id}-data/ on the host and never leak into other flows.

The tab exposes three sources of files:

• Uploads (uploads/): files you provide from the web UI. Use the Upload files action, or drag and drop directly onto the Files tab. While the agent container is running, uploaded files are also pushed into it at /work/uploads/ so the agent can read them with normal shell tools.
• Resources (resources/): files attached from your saved user resources library via Attach resources from library. Attached resources are copied into the flow and pushed into the running container at /work/resources/.
• Container (container/): snapshots pulled from the running agent container via Pull file or directory from container. These are read-only on the flow side and are never sent back to the container.

Per-file actions in the Files tab include Download, Copy path, Save as resource (promote a flow file into your reusable resources library), and Delete. The Pull action is disabled when the container is not running, with the tooltip "Container is not running".

Uploaded files and attached resources are listed automatically in the agent's system prompts via the {{.UserFiles}} template variable, which renders a compact <task_files> XML block (with nested <uploads> and <resources> sections), so the assistant and automation agents can reference them by path without you pasting the contents into chat. Container snapshots are visible in the UI only and are not auto-injected back into the prompt.

Current limits and limitations to be aware of:

• Maximum upload file size is 300 MB; per upload request up to 1000 files and 2 GB total. File names are capped at 255 bytes (roughly 255 ASCII characters; non-ASCII names use multiple bytes per character).
• Uploads and resources are mirrored into the running container at the fixed paths /work/uploads/ and /work/resources/; files written to other container paths are not auto-mirrored back into the flow file model. Container snapshots can originate from any container path you pull (for example /etc/...) and are cached on the flow side under container/; they are not pushed back into the container.
• Container snapshots are point-in-time pulls. Editing a snapshot in the UI does not write back into the running container.
• Deleting a flow today removes the flow record and its long-term memory entries, but does not yet archive or remove the flow's flow-{id}-data/ directory on disk. Operators are still expected to clean up the data directory manually if they want to reclaim the space.

For early testing, start with a narrow target and a single clear objective. This makes the output easier to review and helps you refine your prompts before running larger assessments.

API Access

PentAGI provides comprehensive programmatic access through both REST and GraphQL APIs, allowing you to integrate penetration testing workflows into your automation pipelines, CI/CD processes, and custom applications.

Generating API Tokens

API tokens are managed through the PentAGI web interface:

1. Navigate to Settings → API Tokens in the web UI
2. Click Create Token to generate a new API token
3. Configure token properties:
   • Name (optional): A descriptive name for the token
   • Expiration Date: When the token will expire (minimum 1 minute, maximum 3 years)
4. Click Create and copy the token immediately - it will only be shown once for security reasons
5. Use the token as a Bearer token in your API requests

Each token is associated with your user account and inherits your role's permissions.

Using API Tokens

Include the API token in the Authorization header of your HTTP requests:

# GraphQL API example
curl -X POST https://your-pentagi-instance:8443/api/v1/graphql \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ flows { id title status } }"}'

# REST API example
curl https://your-pentagi-instance:8443/api/v1/flows \
  -H "Authorization: Bearer YOUR_API_TOKEN"

API Exploration and Testing

PentAGI provides interactive documentation for exploring and testing API endpoints:

GraphQL Playground

Access the GraphQL Playground at https://your-pentagi-instance:8443/api/v1/graphql/playground

1. Click the HTTP Headers tab at the bottom
2. Add your authorization header:

   {
     "Authorization": "Bearer YOUR_API_TOKEN"
   }
   

3. Explore the schema, run queries, and test mutations interactively

Swagger UI

Access the REST API documentation at https://your-pentagi-instance:8443/api/v1/swagger/index.html

1. Click the Authorize button
2. Enter your token in the format: Bearer YOUR_API_TOKEN
3. Click Authorize to apply
4. Test endpoints directly from the Swagger UI

Generating API Clients

You can generate type-safe API clients for your preferred programming language using the schema files included with PentAGI:

GraphQL Clients

The GraphQL schema is available at:

• Web UI: Navigate to Settings to download schema.graphqls
• Direct file: backend/pkg/graph/schema.graphqls in the repository

Generate clients using tools like:

• GraphQL Code Generator (JavaScript/TypeScript): https://the-guild.dev/graphql/codegen
• genqlient (Go): https://github.com/Khan/genqlient
• Apollo iOS (Swift): https://www.apollographql.com/docs/ios

REST API Clients

The OpenAPI specification is available at:

• Swagger JSON: https://your-pentagi-instance:8443/api/v1/swagger/doc.json
• Swagger YAML: Available in backend/pkg/server/docs/swagger.yaml

Generate clients using:

• OpenAPI Generator: https://openapi-generator.tech

  openapi-generator-cli generate \
    -i https://your-pentagi-instance:8443/api/v1/swagger/doc.json \
    -g python \
    -o ./pentagi-client
  

• Swagger Codegen: https://github.com/swagger-api/swagger-codegen

  swagger-codegen generate \
    -i https://your-pentagi-instance:8443/api/v1/swagger/doc.json \
    -l typescript-axios \
    -o ./pentagi-client
  

• swagger-typescript-api (TypeScript): https://github.com/acacode/swagger-typescript-api

  npx swagger-typescript-api \
    -p https://your-pentagi-instance:8443/api/v1/swagger/doc.json \
    -o ./src/api \
    -n pentagi-api.ts
  

API Usage Examples

Creating a New Flow (GraphQL)

mutation CreateFlow {
  createFlow(
    modelProvider: "openai"
    input: "Test the security of https://example.com"
  ) {
    id
    title
    status
    createdAt
  }
}

Listing Flows (REST API)

curl https://your-pentagi-instance:8443/api/v1/flows \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  | jq '.flows[] | {id, title, status}'

Python Client Example

import requests

class PentAGIClient:
    def __init__(self, base_url, api_token):
        self.base_url = base_url
        self.headers = {
            "Authorization": f"Bearer {api_token}",
            "Content-Type": "application/json"
        }
    
    def create_flow(self, provider, target):
        query = """
        mutation CreateFlow($provider: String!, $input: String!) {
          createFlow(modelProvider: $provider, input: $input) {
            id
            title
            status
          }
        }
        """
        response = requests.post(
            f"{self.base_url}/api/v1/graphql",
            json={
                "query": query,
                "variables": {
                    "provider": provider,
                    "input": target
                }
            },
            headers=self.headers
        )
        return response.json()
    
    def get_flows(self):
        response = requests.get(
            f"{self.base_url}/api/v1/flows",
            headers=self.headers
        )
        return response.json()

# Usage
client = PentAGIClient(
    "https://your-pentagi-instance:8443",
    "your_api_token_here"
)

# Create a new flow
flow = client.create_flow("openai", "Scan https://example.com for vulnerabilities")
print(f"Created flow: {flow}")

# List all flows
flows = client.get_flows()
print(f"Total flows: {len(flows['flows'])}")

TypeScript Client Example

import axios, { AxiosInstance } from 'axios';

interface Flow {
  id: string;
  title: string;
  status: string;
  createdAt: string;
}

class PentAGIClient {
  private client: AxiosInstance;

  constructor(baseURL: string, apiToken: string) {
    this.client = axios.create({
      baseURL: `${baseURL}/api/v1`,
      headers: {
        'Authorization': `Bearer ${apiToken}`,
        'Content-Type': 'application/json',
      },
    });
  }

  async createFlow(provider: string, input: string): Promise<Flow> {
    const query = `
      mutation CreateFlow($provider: String!, $input: String!) {
        createFlow(modelProvider: $provider, input: $input) {
          id
          title
          status
          createdAt
        }
      }
    `;

    const response = await this.client.post('/graphql', {
      query,
      variables: { provider, input },
    });

    return response.data.data.createFlow;
  }

  async getFlows(): Promise<Flow[]> {
    const response = await this.client.get('/flows');
    return response.data.flows;
  }

  async getFlow(flowId: string): Promise<Flow> {
    const response = await this.client.get(`/flows/${flowId}`);
    return response.data;
  }
}

// Usage
const client = new PentAGIClient(
  'https://your-pentagi-instance:8443',
  'your_api_token_here'
);

// Create a new flow
const flow = await client.createFlow(
  'openai',
  'Perform penetration test on https://example.com'
);
console.log('Created flow:', flow);

// List all flows
const flows = await client.getFlows();
console.log(`Total flows: ${flows.length}`);

Security Best Practices

When working with API tokens:

• Never commit tokens to version control - use environment variables or secrets management
• Rotate tokens regularly - set appropriate expiration dates and create new tokens periodically
• Use separate tokens for different applications - makes it easier to revoke access if needed
• Monitor token usage - review API token activity in the Settings page
• Revoke unused tokens - disable or delete tokens that are no longer needed
• Use HTTPS only - never send API tokens over unencrypted connections

Token Management

• View tokens: See all your active tokens in Settings → API Tokens
• Edit tokens: Update token names or revoke tokens
• Delete tokens: Permanently remove tokens (this action cannot be undone)
• Token ID: Each token has a unique ID that can be copied for reference

The token list shows:

• Token name (if provided)
• Token ID (unique identifier)
• Status (active/revoked/expired)
• Creation date
• Expiration date

Custom LLM Provider Configuration

When using custom LLM providers with the LLM_SERVER_* variables, you can fine-tune the reasoning format used in requests.

Tip

For production-grade local deployments, consider using vLLM with Qwen3.5-27B-FP8 for optimal performance. See our comprehensive deployment guide which includes hardware requirements, configuration templates (thinking mode and non-thinking mode), and performance benchmarks showing 13K TPS prompt processing on 4× RTX 5090 GPUs.

Variable	Default	Description
LLM_SERVER_URL		Base URL for the custom LLM API endpoint
LLM_SERVER_KEY		API key for the custom LLM provider
LLM_SERVER_MODEL		Default model to use (can be overridden in provider config)
LLM_SERVER_CONFIG_PATH		Path to the YAML configuration file for agent-specific models
LLM_SERVER_PROVIDER		Provider name prefix for model names (e.g., openrouter, deepseek for LiteLLM proxy)
LLM_SERVER_PRESERVE_REASONING	false	Preserve reasoning content in multi-turn conversations (required by some providers)
LLM_SERVER_API_TYPE		azure or azure_ad for an Azure OpenAI deployment, empty for a plain endpoint; see Using Azure OpenAI
LLM_SERVER_API_VERSION	2024-10-21	The api-version Azure requires; ignored by a plain endpoint

The LLM_SERVER_PROVIDER setting is particularly useful when using LiteLLM proxy, which adds a provider prefix to model names. For example, when connecting to Moonshot API through LiteLLM, models like kimi-2.5 become moonshot/kimi-2.5. By setting LLM_SERVER_PROVIDER=moonshot, you can use the same provider configuration file for both direct API access and LiteLLM proxy access without modifications.

The LLM_SERVER_PRESERVE_REASONING setting controls whether reasoning content is preserved in multi-turn conversations:

• false (default): Reasoning content is not preserved in conversation history
• true: Reasoning content is preserved and sent in subsequent API calls

This setting is required by some LLM providers (e.g., Moonshot) that return errors like "thinking is enabled but reasoning_content is missing in assistant tool call message" when reasoning content is not included in multi-turn conversations. Enable this setting if your provider requires reasoning content to be preserved.

Using Azure OpenAI

The custom provider calls Azure OpenAI deployments directly:

LLM_SERVER_URL=https://<resource>.openai.azure.com  # the Endpoint from the resource's Keys and Endpoint page, without an /openai path
LLM_SERVER_KEY=your_azure_openai_api_key            # KEY 1 or KEY 2 from the same page
LLM_SERVER_API_TYPE=azure                           # the api-key header and deployment URLs
LLM_SERVER_API_VERSION=2024-10-21                   # the default; a newer version works as well
LLM_SERVER_MODEL=                                   # Leave empty, models are specified in the config
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/azure-openai.provider.yml

Azure addresses a deployment, not a model: PentAGI calls <LLM_SERVER_URL>/openai/deployments/<model>/chat/completions?api-version=<version>, so every model: in the provider config must be the name of a deployment in your resource, and LLM_SERVER_PROVIDER must stay empty, because its prefix would become part of the deployment name. The bundled azure-openai.provider.yml expects deployments named after their models: gpt-4.1, gpt-4.1-mini and o4-mini. If yours are named differently, copy the file, change the model: values, and mount your copy:

PENTAGI_LLM_SERVER_CONFIG_PATH=/path/on/host/my-azure.provider.yml  # mounted at /opt/pentagi/conf/custom.provider.yml
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/custom.provider.yml

After docker compose up -d, check the deployments before running a flow. Without -config, ctester tests the file LLM_SERVER_CONFIG_PATH names, the bundled one or your copy; the bundled configuration's own run is in examples/tests/azure-openai-report.md:

docker exec -it pentagi /opt/pentagi/bin/ctester

• PentAGI does not read a model catalogue from Azure, so it knows no context window for a deployment and does not compact agent chains to fit one.
• LLM_SERVER_API_TYPE=azure_ad sends LLM_SERVER_KEY as a Microsoft Entra ID bearer token instead of an API key. PentAGI does not refresh it, and Entra tokens expire after about an hour, so use an API key for anything longer.
• Azure's OpenAI-compatible v1 API works as a plain endpoint too: set LLM_SERVER_URL=https://<resource>.openai.azure.com/openai/v1 and leave LLM_SERVER_API_TYPE empty; model: is still the deployment name.
• The installer's custom provider form has API Type and API Version fields for the same two settings.
• Embeddings are configured separately through EMBEDDING_* and have no Azure mode; LLM_SERVER_API_TYPE does not apply to them.

Troubleshooting: tool-call (function-call) parser errors

PentAGI drives its agents with tool calls (also called function calls), so any custom OpenAI-compatible backend configured through LLM_SERVER_* must return valid tool-call JSON in the format the OpenAI Chat Completions API defines. When the backend emits malformed, truncated, or non-conforming tool-call arguments, the agent chain cannot continue.

Self-hosted engines such as llama.cpp, SGLang, and vLLM usually require a specific tool-call parser and a matching chat template to produce correct tool-call output. If the parser is missing or mismatched for the model you are serving, tool-call arguments can come back corrupted. Compatibility therefore depends on the backend's tool-call/function-call behavior and configuration, not on PentAGI alone; not every llama.cpp or SGLang setup produces valid tool calls out of the box.

Typical symptoms:

• Backend or proxy errors such as Failed to parse tool call arguments as JSON (often surfaced through a LiteLLM proxy as an HTTP 500), or other unexpected 5xx/4xx responses from the LLM endpoint.
• A flow that runs for a few steps and then stops responding to new input in the UI.
• Repeated or looping tool calls that never converge.
• A flow that fails right at the start with failed to select primary docker image via llm call, because the first action in a flow is an LLM tool call to choose the container image; a backend that cannot return a valid tool call fails at this step too.

How to investigate:

1. Check both sides of the connection: the PentAGI logs (docker compose logs -f pentagi) and the inference backend or proxy logs (llama.cpp, SGLang, vLLM, or LiteLLM). The backend log usually shows the same parse error when it produced the malformed tool call.
2. Validate the provider before running a full flow with the ctester utility, which exercises tool-calling agent types directly. See Testing LLM Agents.
3. Confirm the backend's tool-call parser and chat template are the ones recommended for the model you are serving, and that the model itself supports tool calling.
4. Update PentAGI to the latest build. Recent versions sanitize malformed function-call arguments returned by the model so a single bad response no longer stalls the whole flow; older builds forwarded the corrupted arguments and could get stuck.

Ollama Provider Configuration

PentAGI supports Ollama for both local LLM inference (zero-cost, enhanced privacy) and Ollama Cloud (managed service with free tier).

Configuration Variables

Variable	Default	Description
OLLAMA_SERVER_URL		URL of your Ollama server or Ollama Cloud
OLLAMA_SERVER_API_KEY		API key for Ollama Cloud authentication
OLLAMA_SERVER_MODEL		Default model for inference
OLLAMA_SERVER_CONFIG_PATH		Path to custom agent configuration file
OLLAMA_SERVER_PULL_MODELS_TIMEOUT	600	Timeout for model downloads (seconds)
OLLAMA_SERVER_PULL_MODELS_ENABLED	false	Auto-download models on startup
OLLAMA_SERVER_LOAD_MODELS_ENABLED	false	Query server for available models

Ollama Cloud Configuration

Ollama Cloud provides managed inference with a free tier and paid plans. Paid usage is billed from included or purchased credits at each model's published per-token rate; off-peak discounts apply to selected DeepSeek models.

Free Tier Setup (Single Model)

# Free tier allows one model at a time
OLLAMA_SERVER_URL=https://ollama.com
OLLAMA_SERVER_API_KEY=your_ollama_cloud_api_key
OLLAMA_SERVER_MODEL=gpt-oss:120b  # Example: OpenAI OSS 120B model

Paid Tier Setup (Multi-Model with Pre-built Configuration)

For paid tiers supporting concurrent requests and pay-as-you-go credits, use the pre-built Ollama Cloud configuration:

# Using pre-built Ollama Cloud configuration (included in Docker image)
OLLAMA_SERVER_URL=https://ollama.com
OLLAMA_SERVER_API_KEY=your_ollama_cloud_api_key
OLLAMA_SERVER_CONFIG_PATH=/opt/pentagi/conf/ollama-cloud.provider.yml

The pre-built ollama-cloud.provider.yml configuration includes optimized model assignments for all agent types:

• Simple/Reflector/Enricher: minimax-m2.7:cloud - Reliable low-latency utility model
• Simple JSON/Primary Agent/Assistant/Pentester/Searcher: deepseek-v4.1-flash:cloud - Efficient long-context model at the same input/output rate as MiniMax M2.7
• Generator/Adviser: kimi-k3:cloud - Flagship long-horizon planning and knowledge-work model
• Refiner: glm-5.3:cloud - Flagship coding and agentic model
• Coder/Installer: kimi-k2.7-code:cloud - Coding-specialized long-context model

Custom Configuration (Advanced)

To create your own agent configuration, mount a custom file from your host filesystem:

# Using custom provider configuration
OLLAMA_SERVER_URL=https://ollama.com
OLLAMA_SERVER_API_KEY=your_ollama_cloud_api_key
OLLAMA_SERVER_CONFIG_PATH=/opt/pentagi/conf/ollama.provider.yml

# Mount custom configuration from host filesystem (in .env or docker-compose override)
PENTAGI_OLLAMA_SERVER_CONFIG_PATH=/path/on/host/my-ollama-config.yml

The PENTAGI_OLLAMA_SERVER_CONFIG_PATH environment variable maps your host configuration file to /opt/pentagi/conf/ollama.provider.yml inside the container.

Example custom configuration (my-ollama-config.yml):

primary_agent:
  model: "deepseek-v4-flash:cloud"
  temperature: 1.0
  top_p: 0.95
  max_tokens: 32768

coder:
  model: "kimi-k2.7-code:cloud"
  temperature: 1.0
  max_tokens: 20480

Local Ollama Configuration

For self-hosted Ollama instances:

# Basic local Ollama setup
OLLAMA_SERVER_URL=http://localhost:11434
OLLAMA_SERVER_MODEL=llama3.1:8b-instruct-q8_0

# Production setup with auto-pull and model discovery
OLLAMA_SERVER_URL=http://ollama-server:11434
OLLAMA_SERVER_PULL_MODELS_ENABLED=true
OLLAMA_SERVER_PULL_MODELS_TIMEOUT=900
OLLAMA_SERVER_LOAD_MODELS_ENABLED=true

# Using pre-built configurations from Docker image
OLLAMA_SERVER_CONFIG_PATH=/opt/pentagi/conf/ollama-llama318b.provider.yml
# or
OLLAMA_SERVER_CONFIG_PATH=/opt/pentagi/conf/ollama-qwen332b-fp16-tc.provider.yml
# or
OLLAMA_SERVER_CONFIG_PATH=/opt/pentagi/conf/ollama-qwq32b-fp16-tc.provider.yml

Performance Considerations:

• Model Discovery (OLLAMA_SERVER_LOAD_MODELS_ENABLED=true): Adds 1-2s startup latency querying Ollama API
• Auto-pull (OLLAMA_SERVER_PULL_MODELS_ENABLED=true): First startup may take several minutes downloading models
• Pull timeout (OLLAMA_SERVER_PULL_MODELS_TIMEOUT=900): 15 minutes in seconds
• Static Config: Disable both flags and specify models in config file for fastest startup

Creating Custom Ollama Models with Extended Context

PentAGI requires models with larger context windows than the default Ollama configurations. You need to create custom models with increased num_ctx parameter through Modelfiles. While typical agent workflows consume around 64K tokens, PentAGI uses 110K context size for safety margin and handling complex penetration testing scenarios.

Important: The num_ctx parameter can only be set during model creation via Modelfile - it cannot be changed after model creation or overridden at runtime.

Example: Qwen3 32B FP16 with Extended Context

Create a Modelfile named Modelfile_qwen3_32b_fp16_tc:

FROM qwen3:32b-fp16
PARAMETER num_ctx 110000
PARAMETER temperature 0.3
PARAMETER top_p 0.8
PARAMETER min_p 0.0
PARAMETER top_k 20
PARAMETER repeat_penalty 1.1

Build the custom model:

ollama create qwen3:32b-fp16-tc -f Modelfile_qwen3_32b_fp16_tc

Example: QwQ 32B FP16 with Extended Context

Create a Modelfile named Modelfile_qwq_32b_fp16_tc:

FROM qwq:32b-fp16
PARAMETER num_ctx 110000
PARAMETER temperature 0.2
PARAMETER top_p 0.7
PARAMETER min_p 0.0
PARAMETER top_k 40
PARAMETER repeat_penalty 1.2

Build the custom model:

ollama create qwq:32b-fp16-tc -f Modelfile_qwq_32b_fp16_tc

Note

: The QwQ 32B FP16 model requires approximately 71.3 GB VRAM for inference. Ensure your system has sufficient GPU memory before attempting to use this model.

These custom models are referenced in the pre-built provider configuration files (ollama-qwen332b-fp16-tc.provider.yml and ollama-qwq32b-fp16-tc.provider.yml) that are included in the Docker image at /opt/pentagi/conf/.

OpenAI Provider Configuration

PentAGI integrates with OpenAI's comprehensive model lineup, featuring advanced reasoning capabilities with extended chain-of-thought, agentic models with enhanced tool integration, and specialized code models for security engineering.

Configuration Variables

Variable	Default	Description
OPEN_AI_KEY		API key for OpenAI services
OPEN_AI_SERVER_URL	https://api.openai.com/v1	OpenAI API endpoint

Configuration Examples

# Basic OpenAI setup
OPEN_AI_KEY=your_openai_api_key
OPEN_AI_SERVER_URL=https://api.openai.com/v1

# Using with proxy for enhanced security
OPEN_AI_KEY=your_openai_api_key
PROXY_URL=http://your-proxy:8080

Supported Models

PentAGI supports 32 OpenAI models with tool calling, streaming, reasoning modes, and prompt caching. Models marked with * are used in default configuration. Models marked ⚠️ are deprecated by OpenAI and kept only for backward compatibility with agent configs already pinned to those names — avoid them for new assignments.

GPT-5.6 Series - Latest Frontier (Feb 2026 knowledge cutoff, 1.05M context, 128K max output)

Model ID	Thinking	Reasoning Effort	Price (Input/Output/Cache)	Use Case
gpt-5.6-sol	✅	low/medium/high/xhigh	$5.00/$30.00/$0.50	Frontier model for complex professional work, most demanding autonomous pentesting, sophisticated exploit chain development, deep multi-stage attack simulation
gpt-5.6-terra*	✅	low/medium/high/xhigh	$2.50/$15.00/$0.25	Balances intelligence and cost; multi-phase security assessments, coordinated multi-tool pentesting (generator/refiner/adviser/coder default)
gpt-5.6-luna	✅	low/medium/high/xhigh	$1.00/$6.00/$0.10	Optimized for cost-sensitive, high-volume workloads; rapid reconnaissance, bulk vulnerability scanning, real-time monitoring

GPT-5.5 Series - Frontier (Dec 2025 knowledge cutoff, 1.05M context, 128K max output)

Model ID	Thinking	Reasoning Effort	Price (Input/Output/Cache)	Use Case
gpt-5.5	✅	none/low/medium/high/xhigh	$5.00/$30.00/$0.50	New class of intelligence for coding and professional work; complex security research, advanced autonomous pentesting
gpt-5.5-pro	✅	medium/high/xhigh	$30.00/$180.00/$0.00	Uses more compute for smarter, more precise responses; no cached-input discount; mission-critical security research, zero-day discovery

GPT-5.4 Series - Advanced Reasoning at Scale (1M context)

Model ID	Thinking	Reasoning Effort	Price (Input/Output/Cache)	Use Case
gpt-5.4	✅	low/medium/high/xhigh	$2.50/$15.00/$0.25	Best intelligence at scale for agentic, coding, and professional workflows; maximum cognitive depth for pentesting
gpt-5.4-mini*	✅	low/medium/high/xhigh	$0.75/$4.50/$0.075	Strongest mini model for coding, computer use, subagents (primary_agent/assistant/reflector/installer/pentester default)
gpt-5.4-nano*	✅	low/medium/high/xhigh	$0.20/$1.25/$0.02	Cheapest GPT-5.4-class model for simple, high-volume tasks (simple/simple_json/searcher/enricher default)

GPT-5.2 Series - Previous Flagship Agentic

Model ID	Thinking	Reasoning Effort	Price (Input/Output/Cache)	Use Case
gpt-5.2	✅	low/medium/high/xhigh	$1.75/$14.00/$0.175	Superseded by 5.4/5.6; autonomous security research, complex exploit chain development
gpt-5.2-pro	✅	medium/high/xhigh	$21.00/$168.00/$0.00	Superior agentic coding and long-context performance, mission-critical security research, zero-day discovery

GPT-5/5.1 Series - Advanced Agentic Models

Model ID	Thinking	Price (Input/Output/Cache)	Use Case
gpt-5	✅	$1.25/$10.00/$0.125	Autonomous security research, exploit chain development, coordinating multi-tool pentesting workflows
gpt-5.1	✅	$1.25/$10.00/$0.125	Bridges GPT-5 and GPT-5.2 with faster responses; balanced penetration testing with strong tool coordination
gpt-5-pro	✅ (high)	$15.00/$120.00/$0.00	Reduced hallucinations, exceptional accuracy, critical security operations
gpt-5-mini	✅	$0.25/$2.00/$0.025	Automated vulnerability analysis, exploit generation with strong function calling
gpt-5-nano	✅	$0.05/$0.40/$0.005	High-throughput security scanning, reconnaissance, real-time monitoring

GPT-4.1 Series - Enhanced Intelligence (Non-Reasoning)

Model ID	Thinking	Price (Input/Output/Cache)	Use Case
gpt-4.1	❌	$2.00/$8.00/$0.50	Superior function calling, complex threat analysis, sophisticated exploit development
gpt-4.1-mini	❌	$0.40/$1.60/$0.10	Routine security assessments, automated code analysis (no longer used in default configuration)

GPT-4o Series - Multimodal (Non-Reasoning)

Model ID	Thinking	Price (Input/Output/Cache)	Use Case
gpt-4o-mini	❌	$0.15/$0.60/$0.075	Compact multimodal with strong function calling, high-frequency scanning, cost-effective bulk operations

o-Series - Advanced Reasoning Models (Current)

Model ID	Thinking	Price (Input/Output/Cache)	Use Case
o3	✅	$2.00/$8.00/$0.50	Succeeded by GPT-5; multi-stage attack chains, deep vulnerability analysis
o3-pro	✅	$20.00/$80.00/$0.00	More compute for better responses; zero-day research, critical security investigations

Deprecated Models - Kept for Backward Compatibility ⚠️

These models were marked deprecated by OpenAI. PentAGI keeps them defined only so that pre-existing agent configs pinned to these names keep working; do not assign them to new agents.

Model ID	Thinking	Price (Input/Output/Cache)	Notes
gpt-5.2-codex	✅	$1.75/$14.00/$0.175	Superseded code-specialized model; use gpt-5.6-terra/gpt-5.4-mini instead
gpt-5.1-codex-max	✅	$1.25/$10.00/$0.125	Superseded; enhanced reasoning for coding workflows
gpt-5.1-codex	✅	$1.25/$10.00/$0.125	Superseded standard code-optimized model
gpt-5-codex	✅	$1.25/$10.00/$0.125	Superseded foundational code-specialized model
gpt-5.1-codex-mini	✅	$0.25/$2.00/$0.025	Superseded compact code model
codex-mini-latest	✅	$1.50/$6.00/$0.375	Superseded compact code model
gpt-4o	❌	$2.50/$10.00/$1.25	Superseded by GPT-5.x/5.6 series multimodal flagship
gpt-4.1-nano	❌	$0.10/$0.40/$0.025	Superseded ultra-fast lightweight model
o3-mini	✅	$1.10/$4.40/$0.55	Superseded compact reasoning model
o4-mini	✅	$1.10/$4.40/$0.275	Succeeded by gpt-5-mini
o1	✅	$15.00/$60.00/$7.50	Superseded premier reasoning model
o1-pro	✅	$150.00/$600.00/$0.00	Superseded, highest cost point of the o-series

Prices: Per 1M tokens. Reasoning models include thinking tokens in output pricing.

Warning

GPT-5/5.1/5.2 Models - Trusted Access Required

The original GPT-5, GPT-5.1, and GPT-5.2 models (gpt-5, gpt-5.1, gpt-5.2, gpt-5-pro, gpt-5.2-pro, and all deprecated Codex variants) work unstably with PentAGI and may trigger OpenAI's cybersecurity safety mechanisms without verified access. This does not affect the newer GPT-5.4/5.5/5.6 series used in PentAGI's default configuration below.

To use these models reliably:

1. Individual users: Verify your identity at chatgpt.com/cyber
2. Enterprise teams: Request trusted access through your OpenAI representative
3. Security researchers: Apply for the Cybersecurity Grant Program (includes $10M in API credits)

Recommended alternatives without verification:

• Use PentAGI's defaults — gpt-5.4-mini/gpt-5.4-nano/gpt-5.6-terra — which work out of the box
• Use o3/o3-pro for reasoning tasks
• Use gpt-4.1 series for general intelligence and function calling without reasoning

Reasoning Configuration:

• Reasoning forced off by default: every default agent assigned gpt-5.4-mini or gpt-5.6-terra (primary_agent, assistant, generator, refiner, adviser, reflector, coder, installer, pentester) sets reasoning: {mode: off} — this genuinely disables reasoning, it is not simply "low effort". PentAGI calls OpenAI exclusively through /v1/chat/completions (never /v1/responses), and this endpoint rejects requests that combine function tools with these models' default-on thinking; forcing thinking off is required for tool calls to work reliably (see the investigation notes in backend/pkg/providers/openai/config.yml).
• No override needed for gpt-5.4-nano: used for simple, simple_json, searcher, and enricher, this tier does not default to thinking on, so tools attach without conflict and no reasoning override is required.
• Manual tuning available: outside the default assignments, GPT-5.6/5.5/5.4/5.2 series models expose explicit reasoning effort levels (low/medium/high/xhigh, plus none on GPT-5.5) for custom agent configs that need variable reasoning depth with tool calling disabled or via /v1/responses.

Key Features:

• Extended Reasoning: GPT-5.4/5.5/5.6 and o-series models with chain-of-thought for complex security analysis
• Agentic Intelligence: GPT-5.4/5.5/5.6 series with enhanced tool integration, million-token context windows, and autonomous capabilities
• Prompt Caching: Cost reduction on repeated context (10-50% of input price)
• Code Specialization: Legacy Codex models remain available (deprecated) for vulnerability discovery and exploit development in pinned configs
• Multimodal Support: gpt-4o-mini for vision-based security assessments
• Tool Calling: Robust function calling across all models for pentesting tool orchestration
• Streaming: Real-time response streaming for interactive workflows
• Proven Track Record: Industry-leading models with CVE discoveries and real-world security applications

Anthropic Provider Configuration

PentAGI integrates with Anthropic's Claude models, featuring advanced extended thinking capabilities, exceptional safety mechanisms, and sophisticated understanding of complex security contexts with prompt caching.

Configuration Variables

Variable	Default	Description
ANTHROPIC_API_KEY		API key for Anthropic services
ANTHROPIC_SERVER_URL	https://api.anthropic.com/v1	Anthropic API endpoint

Configuration Examples

# Basic Anthropic setup
ANTHROPIC_API_KEY=your_anthropic_api_key
ANTHROPIC_SERVER_URL=https://api.anthropic.com/v1

# Using with proxy for secure environments
ANTHROPIC_API_KEY=your_anthropic_api_key
PROXY_URL=http://your-proxy:8080

# Workload Identity Federation instead of a long-lived key (leave ANTHROPIC_API_KEY empty)
ANTHROPIC_FEDERATION_RULE_ID=fdrl_...
ANTHROPIC_ORGANIZATION_ID=00000000-0000-0000-0000-000000000000
ANTHROPIC_SERVICE_ACCOUNT_ID=svac_...
ANTHROPIC_WORKSPACE_ID=wrkspc_...
ANTHROPIC_IDENTITY_TOKEN_FILE=/var/run/secrets/anthropic.com/token

With Workload Identity Federation, PentAGI exchanges the identity token your platform issues (Kubernetes, GitHub Actions, cloud IAM, any OIDC issuer) for a short-lived Claude API token and refreshes it on its own. The token file is re-read on every exchange and must be mounted into the pentagi container. A token carrying a jti claim, as Kubernetes and GitHub Actions tokens do, can be exchanged only once, so the file must hold a new token before each refresh: rotate it well within the lifetime of the minted token. ANTHROPIC_IDENTITY_TOKEN takes the token itself where the platform injects it as a variable, but it is read once and cannot be rotated, so it suits only runs shorter than the identity token's lifetime. A set ANTHROPIC_API_KEY wins over federation. See backend/docs/config.md for every variable.

Note

Google Vertex AI for Claude models

PentAGI does not currently expose a dedicated Google Vertex AI configuration path for Anthropic Claude in .env. There is no separate Vertex AI API key field at this time, and the existing Anthropic variables (ANTHROPIC_API_KEY, ANTHROPIC_SERVER_URL) target the direct Anthropic API. Supported routes for Claude are:

• Direct Anthropic API: ANTHROPIC_API_KEY and ANTHROPIC_SERVER_URL (see above).
• AWS Bedrock: BEDROCK_* variables (see AWS Bedrock Provider Configuration).

If you need to use Vertex AI today, the safest supported workaround is to expose Vertex AI through an OpenAI-compatible proxy or gateway that translates Vertex AI calls into the Chat Completions format while preserving the chat and tool-call behavior PentAGI relies on, then point the Custom LLM provider at that gateway via LLM_SERVER_URL, LLM_SERVER_KEY, and LLM_SERVER_MODEL. This path is only as reliable as the gateway you choose.

Supported Models

PentAGI supports 9 Claude models with tool calling, streaming, extended thinking, adaptive thinking, and prompt caching. Models marked with * are used in default configuration.

Claude 5 Series - Newest Models (2026)

Model ID	Thinking	Release Date	Price (Input/Output/Cache R/W)	Use Case
claude-sonnet-5*	✅	Jul 2026	$3.00/$15.00/$0.30/$3.75	Best combination of speed and intelligence for coding, agents, and professional work at scale. Adaptive thinking only (manual budget thinking rejected); sampling parameters not supported. Default model for primary agent, assistant, coder, adviser, installer, pentester
claude-fable-5	✅	Jun 2026	$10.00/$50.00/$1.00/$12.50	Anthropic's most capable widely released model for long-running agents and the most demanding reasoning workloads. Adaptive thinking always on (budget thinking and an explicit disable are rejected); sampling parameters not supported

Claude 4 Series

Model ID	Thinking	Release Date	Price (Input/Output/Cache R/W)	Use Case
claude-opus-4-8*	✅	May 2026	$5.00/$25.00/$0.50/$6.25	Flagship for coding, agents, and deep reasoning in enterprise security workflows. Adaptive thinking only — budget thinking and sampling params (temperature/top_p/top_k) are rejected. Default model for generator and refiner; most demanding exploit development and multi-stage attack simulation
claude-opus-4-7	✅	Apr 2026	$5.00/$25.00/$0.50/$6.25	Advanced software engineering and long-running agentic security analysis. Adaptive thinking only (manual budget thinking rejected)
claude-sonnet-4-6	✅	Feb 2026	$3.00/$15.00/$0.30/$3.75	Best speed/intelligence balance with adaptive thinking. Multi-phase security assessments, intelligent vulnerability analysis, real-time threat hunting
claude-opus-4-6	✅	Feb 2026	$5.00/$25.00/$0.50/$6.25	Most intelligent model for autonomous agents and coding. Extended + adaptive thinking for complex exploit development, multi-stage attack simulation
claude-haiku-4-5*	❌	Oct 2025	$1.00/$5.00/$0.10/$1.25	Fast and efficient model with exceptional function calling and low latency, no thinking support. Default model for simple, simple_json, reflector, searcher, enricher; high-frequency scanning, real-time monitoring, bulk automated testing

Legacy Models - Still Supported

Model ID	Thinking	Release Date	Price (Input/Output/Cache R/W)	Use Case
claude-sonnet-4-5	✅	Sep 2025	$3.00/$15.00/$0.30/$3.75	State-of-the-art reasoning (superseded by sonnet-4-6/sonnet-5). Sophisticated penetration testing, advanced threat analysis
claude-opus-4-5	✅	Nov 2025	$5.00/$25.00/$0.50/$6.25	Ultimate reasoning (superseded by opus-4-6/4-7/4-8). Critical security research, zero-day discovery, red team operations

Prices: Per 1M tokens. Cache pricing includes both Read and Write costs.

Extended Thinking Configuration (default agent config, see backend/pkg/providers/anthropic/config.yml):

• Generator / Refiner (claude-opus-4-8): adaptive reasoning at xhigh/high effort for maximum reasoning depth on complex exploit development
• Primary agent, assistant, coder, adviser, installer, pentester (claude-sonnet-5): adaptive reasoning (adviser at xhigh effort) for balanced code analysis and vulnerability research
• Reflector, searcher (claude-haiku-4-5): fixed reasoning budget of 1024 tokens for focused reasoning on specific tasks
• Simple, simple_json, enricher (claude-haiku-4-5): no thinking, optimized for speed

Key Features:

• Extended Thinking: All Claude 4.5+ models support configurable chain-of-thought reasoning depths for complex security analysis
• Adaptive Thinking: Claude 4.6 series (Opus/Sonnet) dynamically adjusts reasoning depth based on task complexity; Claude Opus 4.7/4.8 and the Claude 5 series (Sonnet/Fable) are adaptive-thinking-only (manual budget thinking and sampling parameters are rejected with HTTP 400)
• Prompt Caching: Significant cost reduction with separate read/write pricing (10% read, 125% write of input)
• Extended Context Window: 200K tokens standard, up to 1M tokens (beta) for Claude Opus/Sonnet 4.6 for comprehensive codebase analysis
• Tool Calling: Robust function calling with exceptional accuracy for security tool orchestration
• Streaming: Real-time response streaming for interactive penetration testing workflows
• Safety-First Design: Built-in safety mechanisms ensuring responsible security testing practices
• Multimodal Support: Vision capabilities in latest models for screenshot analysis and UI security assessment
• Constitutional AI: Advanced safety training providing reliable and ethical security guidance

Google AI (Gemini) Provider Configuration

PentAGI integrates with Google's Gemini models through the Google AI API, offering state-of-the-art multimodal reasoning capabilities with extended thinking and context caching.

Configuration Variables

Variable	Default	Description
GEMINI_API_KEY		API key for Google AI services
GEMINI_SERVER_URL	https://generativelanguage.googleapis.com	Google AI API endpoint

Configuration Examples

# Basic Gemini setup
GEMINI_API_KEY=your_gemini_api_key
GEMINI_SERVER_URL=https://generativelanguage.googleapis.com

# Using with proxy
GEMINI_API_KEY=your_gemini_api_key
PROXY_URL=http://your-proxy:8080

Supported Models

PentAGI lists 14 Gemini model IDs that responded through the tested API endpoint. Availability in the catalogue does not mean a model is suitable for every agent role: the saved-chain results below determine the bundled defaults. Models marked with * are used in config.yml; the full replay matrix describes role and outcome limits.

Model ID	Thinking	Context	Price (Input/Output/Cache)	Saved-chain result
gemini-3.8-flash	✅	1M	$0.75/$3.75/$0.075	API responds; 10/10 saved generator calls were content-filtered
gemini-3.7-flash	✅	1M	$0.75/$3.75/$0.075	API responds; 10/10 saved generator calls were content-filtered; former default
gemini-3.6-flash	✅	1M	$0.75/$3.75/$0.075	API responds; 10/10 saved generator calls returned text without a tool
gemini-3.5-flash	✅	1M	$1.5/$9/$0.15	API responds; 10/10 saved generator calls returned text without a tool
gemini-3.5-flash-lite*	✅	1M	$0.3/$2.5/$0.03	Complex-role default; eight direct plans and two after a safe memorist continuation
gemini-3.1-pro-preview	✅	1M	$2/$12/$0.2	API responds; 10/10 saved generator calls returned text without a tool
gemini-3.1-pro-preview-customtools	✅	1M	$2/$12/$0.2	API responds; 10/10 saved generator calls returned text without a tool
gemini-3.1-flash-lite*	✅	1M	$0.25/$1.5/$0.025	Simple-role default; direct plan on all ten saved generator chains
gemini-3-flash-preview	✅	1M	$0.5/$3/$0.05	API responds; three direct plans and five generator timeouts
gemini-2.5-pro	✅	1M	$1.25/$10/$0.125	API responds; ten direct plans, but four role-smoke provider errors
gemini-2.5-flash	✅	1M	$0.3/$2.5/$0.03	Ten direct plans; access is limited for new API projects
gemini-2.5-flash-lite	✅	1M	$0.1/$0.4/$0.01	API responds; five of ten generator answers were empty
gemma-4-31b-it	✅	256K	Free/Free/Free	API responds; seven direct plans and three generator timeouts
gemma-4-26b-a4b-it	✅	256K	Free/Free/Free	Direct plan on all ten saved generator chains

Prices: Per 1M tokens. Google limits Gemini 2.5 access for new projects, so PentAGI uses the tested 3.1 Flash-Lite as its fallback and simple-role default. Existing custom 2.5 configurations remain usable where the project has access.

Default Model Assignments (config.yml):

• gemini-3.1-flash-lite - simple, simple_json, reflector, searcher, enricher
• gemini-3.5-flash-lite - primary_agent, assistant, generator, refiner, adviser, coder, installer, pentester

Both default models passed a basic API/configuration smoke for every role. Google reports stronger agentic and coding performance for 3.5 Flash-Lite than 3.1 Flash-Lite; PentAGI's saved production chains cover generator and reflector only, so the smoke does not establish semantic quality or multi-turn reliability for other roles. On two saved generator chains, 3.5 Flash-Lite first chose the allowed memorist tool and called subtask_list after a synthetic tool response; no real tool was executed in that continuation.

Reasoning Effort Levels:

• High: Deeper reasoning for planning and review (primary_agent, generator, refiner, adviser)
• Medium: Balanced reasoning for execution roles (assistant, coder, installer, pentester)
• Not set: No thinking setting is sent and the model's own default applies (simple, simple_json, reflector, searcher, enricher)

AWS Bedrock Provider Configuration

PentAGI integrates with Amazon Bedrock, offering access to 20+ foundation models from leading AI companies including Anthropic, Amazon, Cohere, DeepSeek, OpenAI, Qwen, Mistral, and Moonshot.

Configuration Variables

Variable	Default	Description
BEDROCK_REGION	us-east-1	AWS region for Bedrock service
BEDROCK_DEFAULT_AUTH	false	Use AWS SDK default credential chain (environment, EC2 role, ~/.aws/credentials) - highest priority
BEDROCK_BEARER_TOKEN		Bearer token authentication - priority over static credentials
BEDROCK_ACCESS_KEY_ID		AWS access key ID for static credentials
BEDROCK_SECRET_ACCESS_KEY		AWS secret access key for static credentials
BEDROCK_SESSION_TOKEN		AWS session token for temporary credentials (optional, used with static credentials)
BEDROCK_SERVER_URL		Custom Bedrock endpoint (VPC endpoints, local testing)
BEDROCK_CONFIG_PATH		Path to a custom YAML provider config file (overrides the built-in default config for model/pricing definitions)

Authentication Priority: BEDROCK_DEFAULT_AUTH → BEDROCK_BEARER_TOKEN → BEDROCK_ACCESS_KEY_ID+BEDROCK_SECRET_ACCESS_KEY

Configuration Examples

# Recommended: Default AWS SDK authentication (EC2/ECS/Lambda roles)
BEDROCK_REGION=us-east-1
BEDROCK_DEFAULT_AUTH=true

# Bearer token authentication (AWS STS, custom auth)
BEDROCK_REGION=us-east-1
BEDROCK_BEARER_TOKEN=your_bearer_token

# Static credentials (development, testing)
BEDROCK_REGION=us-east-1
BEDROCK_ACCESS_KEY_ID=your_aws_access_key
BEDROCK_SECRET_ACCESS_KEY=your_aws_secret_key

# With proxy and custom endpoint
BEDROCK_REGION=us-east-1
BEDROCK_DEFAULT_AUTH=true
BEDROCK_SERVER_URL=https://bedrock-runtime.us-east-1.vpce-xxx.amazonaws.com
PROXY_URL=http://your-proxy:8080

Custom Provider Config and Models (advanced)

By default the Bedrock provider uses a per-agent config and model catalog compiled into the binary. One optional path overrides them without rebuilding:

• BEDROCK_CONFIG_PATH — a YAML file (same shape as the other provider configs) that replaces the built-in per-agent model/price assignments. See examples/configs/bedrock-glm-flash.provider.yml.

This is useful to expose a Bedrock model newer than the compiled-in catalog — for example Z.AI's zai.glm-4.7-flash. Use the exact Model ID from the model's AWS Bedrock detail page; add a us./eu./apac. inference-profile prefix only when that page marks the model as requiring cross-region inference (zai.glm-4.7-flash is In-Region, so it is used as-is, with no prefix).

With Docker Compose, set the host-side mount source and the in-container path together:

# host file mounted into the container at /opt/pentagi/conf/bedrock.provider.yml
PENTAGI_BEDROCK_CONFIG_PATH=./examples/configs/bedrock-glm-flash.provider.yml
# tell the backend to read the mounted file
BEDROCK_CONFIG_PATH=/opt/pentagi/conf/bedrock.provider.yml

Supported Models

PentAGI supports 24 AWS Bedrock models with tool calling, streaming, and multimodal capabilities. Models marked with * are used in default configuration.

Model ID	Provider	Thinking	Multimodal	Price (Input/Output)	Use Case
us.amazon.nova-2-lite-v1:0	Amazon Nova	❌	✅	$0.33/$2.75	Adaptive reasoning, efficient thinking
us.amazon.nova-premier-v1:0	Amazon Nova	❌	✅	$2.50/$12.50	Complex reasoning, advanced analysis
us.amazon.nova-pro-v1:0	Amazon Nova	❌	✅	$0.80/$3.20	Balanced accuracy, speed, cost
us.amazon.nova-lite-v1:0	Amazon Nova	❌	✅	$0.06/$0.24	Fast processing, high-volume operations
us.amazon.nova-micro-v1:0	Amazon Nova	❌	❌	$0.035/$0.14	Ultra-low latency, real-time monitoring
us.anthropic.claude-opus-4-8	Anthropic	✅	✅	$5.00/$25.00	Flagship coding/agents/deep reasoning; adaptive thinking only (sampling params rejected)
us.anthropic.claude-opus-4-7	Anthropic	✅	✅	$5.00/$25.00	Advanced engineering, long-running agents; adaptive thinking only
us.anthropic.claude-opus-4-6-v1*	Anthropic	✅	✅	$5.00/$25.00	World-class coding, enterprise agents
us.anthropic.claude-sonnet-4-6	Anthropic	✅	✅	$3.00/$15.00	Frontier intelligence, enterprise scale
us.anthropic.claude-opus-4-5-20251101-v1:0	Anthropic	✅	✅	$5.00/$25.00	Multi-day software development
us.anthropic.claude-haiku-4-5-20251001-v1:0*	Anthropic	✅	✅	$1.00/$5.00	Near-frontier performance, high speed
us.anthropic.claude-sonnet-4-5-20250929-v1:0*	Anthropic	✅	✅	$3.00/$15.00	Real-world agents, coding excellence
us.anthropic.claude-sonnet-4-20250514-v1:0	Anthropic	✅	✅	$3.00/$15.00	Balanced performance, production-ready
us.anthropic.claude-3-5-haiku-20241022-v1:0	Anthropic	❌	❌	$0.80/$4.00	Fastest model, cost-effective scanning
cohere.command-r-plus-v1:0	Cohere	❌	❌	$3.00/$15.00	Large-scale operations, superior RAG
deepseek.v3.2	DeepSeek	❌	❌	$0.58/$1.68	Long-context reasoning, efficiency
openai.gpt-oss-120b-1:0*	OpenAI (OSS)	✅	❌	$0.15/$0.60	Strong reasoning, scientific analysis
openai.gpt-oss-20b-1:0	OpenAI (OSS)	✅	❌	$0.07/$0.30	Efficient coding, software development
qwen.qwen3-next-80b-a3b	Qwen	❌	❌	$0.15/$1.20	Ultra-long context, flagship reasoning
qwen.qwen3-32b-v1:0	Qwen	❌	❌	$0.15/$0.60	Balanced reasoning, research use cases
qwen.qwen3-coder-30b-a3b-v1:0	Qwen	❌	❌	$0.15/$0.60	Vibe coding, natural-language first
qwen.qwen3-coder-next	Qwen	❌	❌	$0.45/$1.80	Tool use, function calling optimized
mistral.mistral-large-3-675b-instruct	Mistral	❌	✅	$4.00/$12.00	Advanced multimodal, long-context
moonshotai.kimi-k2.5	Moonshot	❌	✅	$0.60/$3.00	Vision, language, code in one model

Prices: Per 1M tokens. Models with thinking/reasoning support additional compute costs during reasoning phase.

Tested but Incompatible Models

Some AWS Bedrock models were tested but are not supported due to technical limitations:

Model Family	Reason for Incompatibility
GLM (Z.AI)	Tool calling format incompatible with Converse API (expects string instead of JSON)
AI21 Jamba	Severe rate limits (1-2 req/min) prevent reliable testing and production use
Meta Llama 3.3/3.1	Unstable tool call result processing, causes unexpected failures in multi-turn workflows
Mistral Magistral	Tool calling not supported by the model
Moonshot K2-Thinking	Unstable streaming behavior with tool calls, unreliable in production
Qwen3-VL	Unstable streaming with tool calling, multimodal + tools combination fails intermittently

Important

Rate Limits & Quota Management

Default AWS Bedrock quotas for Claude models are extremely restrictive (2-20 requests/minute for new accounts). For production penetration testing:

1. Request quota increases through AWS Service Quotas console for models you plan to use
2. Use Amazon Nova models - higher default quotas and excellent performance
3. Enable provisioned throughput for consistent high-volume testing
4. Monitor usage - AWS throttles aggressively at quota limits

Without quota increases, expect frequent delays and workflow interruptions.

Warning

Converse API Requirements

PentAGI uses Amazon Bedrock Converse API for unified model access. All supported models require:

• ✅ Converse/ConverseStream API support
• ✅ Tool use (function calling) for penetration testing workflows
• ✅ Streaming tool use for real-time feedback

Verify model capabilities at: AWS Bedrock Model Features

Key Features:

• Automatic Prompt Caching: 40-70% cost reduction on repeated context (Claude 4.x models)
• Extended Thinking: Step-by-step reasoning for complex security analysis (Claude, DeepSeek R1, OpenAI GPT)
• Multimodal Analysis: Process screenshots, diagrams, video for comprehensive testing (Nova, Claude, Mistral, Kimi)
• Tool Calling: Seamless integration with 20+ pentesting tools via function calling
• Streaming: Real-time response streaming for interactive security assessment workflows

DeepSeek Provider Configuration

PentAGI integrates with DeepSeek, providing access to advanced AI models with strong reasoning, coding capabilities, and context caching at competitive prices.

Configuration Variables

Variable	Default Value	Description
DEEPSEEK_API_KEY		DeepSeek API key for authentication
DEEPSEEK_SERVER_URL	https://api.deepseek.com	DeepSeek API endpoint URL
DEEPSEEK_PROVIDER		Provider prefix for LiteLLM integration (optional)

Configuration Examples

# Direct API usage
DEEPSEEK_API_KEY=your_deepseek_api_key
DEEPSEEK_SERVER_URL=https://api.deepseek.com

# With LiteLLM proxy
DEEPSEEK_API_KEY=your_litellm_key
DEEPSEEK_SERVER_URL=http://litellm-proxy:4000
DEEPSEEK_PROVIDER=deepseek  # Adds prefix to model names (deepseek/deepseek-v4-flash) for LiteLLM

Supported Models

PentAGI supports 2 DeepSeek V4 models with tool calling, streaming, hybrid thinking/non-thinking modes, and context caching. Both models think by default and switch to non-thinking mode with reasoning.mode: off. Models marked with * are used in default configuration.

Model ID	Thinking	Max Output	Context	Price (Input/Output/Cache)	Use Case
deepseek-v4-flash*	✅ hybrid	384K	1M	$0.14/$0.28/$0.0028	Utility agents, general dialogue, fast tool calling
deepseek-v4-pro*	✅ hybrid	384K	1M	$1.74/$3.48/$0.0145	Advanced reasoning, complex logic, security analysis

Prices: Per 1M tokens. Cache pricing applies to prompt tokens served from cache (input cache hit, reduced to 1/10 of launch price since 2026-04-26). Both models support hybrid thinking — thinking mode is enabled by default; set reasoning.mode: off (Reasoning Mode Off in the UI) to switch to non-thinking mode for faster/cheaper responses.

Pricing Note (deepseek-v4-pro): The 75% promotional discount on deepseek-v4-pro officially ended on 2026-05-31 15:59 UTC. The prices above reflect the standard post-promotional pricing. If you have legacy configurations using the discounted prices ($0.435/$0.87/$0.003625), update them to the current rates for accurate cost tracking.

The legacy model names deepseek-chat and deepseek-reasoner are scheduled for deprecation by DeepSeek on 2026-07-24. Existing user configurations referencing the legacy names continue to work until then; the defaults above use the current V4 names. deepseek-chat maps to deepseek-v4-flash non-thinking mode; deepseek-reasoner maps to deepseek-v4-flash thinking mode.

Default Agent Configuration:

Strategy: prefer deepseek-v4-flash (12x cheaper input, 12x cheaper output) as the workhorse for utility/lightweight agents; reserve deepseek-v4-pro for complex multi-step reasoning. The installer agent runs on Flash with thinking enabled because environment setup tasks (shell commands, config edits) rarely require pro-level reasoning. Run A/B tests on your own workloads before promoting more agents to Pro.

Agent Role	Default Model	Thinking	Reasoning Effort	Max Output	Temperature	Top P
Generator / Refiner	deepseek-v4-pro	Enabled	High	32768	(auto)	(auto)
Coder	deepseek-v4-pro	Enabled	High	20480	(auto)	(auto)
Primary Agent / Assistant / Pentester	deepseek-v4-pro	Enabled	High	16384	(auto)	(auto)
Adviser (mentor/planner)	deepseek-v4-pro	Enabled	High	8192	(auto)	(auto)
Installer	deepseek-v4-flash	Enabled	High	12288	(auto)	(auto)
Reflector / Searcher / Enricher	deepseek-v4-flash	Disabled	—	4096	0.5	0.9
Simple / Simple JSON	deepseek-v4-flash	Disabled	—	2048	0.3	0.9

Note

: DeepSeek ignores presence_penalty and frequency_penalty on both models. While thinking runs, temperature has no effect and langchaingo drops it, but top_p is sent and applied (values below 0.95 are raised to 0.95); in non-thinking mode top_p is fixed at 1.0, so langchaingo drops it and sends temperature instead. The thinking agents leave both unset, shown as "(auto)" in the table above.

Key Features:

• Hybrid Thinking Modes: Switch between thinking (deep reasoning) and non-thinking (fast) modes via reasoning.mode
• Automatic Prompt Caching: Significant cost reduction on repeated context via cache-hit pricing (1/10 of launch price)
• Extended Thinking: Reinforcement learning CoT for complex security analysis (both V4 models)
• Strong Coding: Optimized for code generation and exploit development
• Long Context: 1M token context window with up to 384K output tokens
• Tool Calling: Seamless integration with 20+ pentesting tools via function calling
• Streaming: Real-time response streaming for interactive workflows
• Multilingual: Strong Chinese and English support
• Additional Features: JSON Output, Chat Prefix Completion (beta), FIM/Fill-in-the-Middle Completion (non-thinking mode only)

Concurrency Limits: deepseek-v4-flash: 2500 concurrent requests; deepseek-v4-pro: 500 concurrent requests.

LiteLLM Integration: Set DEEPSEEK_PROVIDER=deepseek to enable model name prefixing when using default PentAGI configurations with LiteLLM proxy. Leave empty for direct API usage.

GLM Provider Configuration

PentAGI integrates with GLM from Zhipu AI (Z.AI), providing advanced language models with MoE architecture, strong reasoning, and agentic capabilities developed by Tsinghua University.

Configuration Variables

Variable	Default Value	Description
GLM_API_KEY		GLM API key for authentication
GLM_SERVER_URL	https://api.z.ai/api/paas/v4	GLM API endpoint URL (international)
GLM_PROVIDER		Provider prefix for LiteLLM integration (optional)

Configuration Examples

# Direct API usage (international endpoint)
GLM_API_KEY=your_glm_api_key
GLM_SERVER_URL=https://api.z.ai/api/paas/v4

# Alternative endpoints
GLM_SERVER_URL=https://open.bigmodel.cn/api/paas/v4  # China
GLM_SERVER_URL=https://api.z.ai/api/coding/paas/v4   # Coding-specific

# With LiteLLM proxy
GLM_API_KEY=your_litellm_key
GLM_SERVER_URL=http://litellm-proxy:4000
GLM_PROVIDER=zai  # Adds prefix to model names (zai/glm-4) for LiteLLM

Supported Models

PentAGI supports 16 GLM models with tool calling, streaming, reasoning controls, and prompt caching. Models marked with * are used in the default configuration. GLM-5.3, GLM-5.3-Flash, and GLM-5.3-FlashX always reason and accept low, high, or max effort.

GLM-5.x Series - Latest Generation

Model ID	Thinking	Context	Max Output	Price (Input/Output/Cache)	Use Case
glm-5.3*	✅ Always	1M	128K	$1.40/$4.40/$0.26	Current flagship for complex software engineering, agent tasks, and vulnerability research
glm-5.3-flash*	✅ Always	1M	128K	$0.15/$0.50/$0.03	Cost-efficient native multimodal model for utility and latency-sensitive agents
glm-5.3-flashx	✅ Always	1M	128K	$0.37/$1.25/$0.075	Accelerated GLM-5.3-Flash endpoint delivering up to 200 output tokens per second
glm-5.2	✅ Hybrid	1M	128K	$1.40/$4.40/$0.26	Previous flagship for long-horizon engineering tasks
glm-5.1	✅ Hybrid	200K	128K	$1.40/$4.40/$0.26	Long-horizon tasks: 8h sustained autonomous execution, Claude Opus 4.6-aligned coding
glm-5	✅ Hybrid	200K	128K	$1.00/$3.20/$0.20	Foundation for Agentic Engineering, MoE 744B/40B active, Claude Opus 4.5-level coding

GLM-4.7 Series - Premium with Interleaved Thinking

Model ID	Thinking	Context	Max Output	Price (Input/Output/Cache)	Use Case
glm-4.7	✅ Hybrid	200K	128K	$0.60/$2.20/$0.11	Enhanced programming, stable multi-step reasoning
glm-4.7-flashx	✅ Hybrid	200K	128K	$0.07/$0.40/$0.01	Ultra-cheap with priority GPU, but lower RPM limits (avoid for high-frequency use)
glm-4.7-flash	✅ Hybrid	200K	128K	Free/Free/Free	Free ~30B SOTA model, 1 concurrent request

GLM-4.6 Series - Balanced with Auto-Thinking

Model ID	Thinking	Context	Max Output	Price (Input/Output/Cache)	Use Case
glm-4.6	✅ Auto	200K	128K	$0.60/$2.20/$0.11	Balanced, streaming tool calls, token-efficient

GLM-4.5 Series - Unified Reasoning/Coding/Agents

Model ID	Thinking	Context	Max Output	Price (Input/Output/Cache)	Use Case
glm-4.5	✅ Auto	128K	96K	$0.60/$2.20/$0.11	Unified, MoE 355B/32B active
glm-4.5-x	✅ Auto	128K	96K	$2.20/$8.90/$0.45	Ultra-fast premium, lowest latency
glm-4.5-air	✅ Auto	128K	96K	$0.20/$1.10/$0.03	Cost-effective MoE 106B/12B
glm-4.5-airx	✅ Auto	128K	96K	$1.10/$4.50/$0.22	Accelerated Air with priority GPU
glm-4.5-flash	✅ Auto	128K	96K	Free/Free/Free	Free with reasoning/coding/agents support

GLM-4 Legacy - Dense Architecture

Model ID	Thinking	Context	Max Output	Price (Input/Output)	Use Case
glm-4-32b-0414-128k	❌	128K	16K	$0.10/$0.10	Ultra-budget dense 32B, parsing without reasoning

Prices: Per 1M tokens. Cache pricing is for prompt cache hit; cache storage is currently free per Z.AI promotion. GLM-4-32B has no cache support.

Default Agent Configuration:

Strategy: glm-5.3 for critical reasoning and glm-5.3-flash for inexpensive utility and latency-sensitive work. glm-5.3-flashx remains selectable but is not a default because not every compatible gateway deploys it.

Agent Role	Default Model	Thinking	Temperature	Top P	Max Output
Generator / Refiner	glm-5.3	Max	1.0	0.95	32768
Coder	glm-5.3	Max	1.0	0.95	20480
Adviser / Pentester	glm-5.3	Max	1.0	0.95	16384
Primary Agent	glm-5.3	High	1.0	0.95	16384
Assistant / Installer	glm-5.3-flash	High	1.0	0.95	16384
Simple / Reflector	glm-5.3-flash	Low	1.0	0.95	8192
Searcher / Enricher / Simple JSON	glm-5.3-flash	Low	1.0	0.95	4096

All default roles use Z.AI's recommended temperature: 1.0 and top_p: 0.95. The full provider replay passed 288 of 289 cases; the sole failure was a transient gateway timeout and its focused retry passed.

Thinking Modes:

• Always on (GLM-5.3, GLM-5.3-Flash, GLM-5.3-FlashX): Cannot be disabled; reasoning.effort accepts low, high, or max
• Hybrid (GLM-5.2 and earlier GLM-5.x, GLM-4.7): Explicit toggle via reasoning.mode
• Auto (GLM-4.6, GLM-4.5 series): Model automatically determines when reasoning is needed
• Preserved Thinking (Z.AI Coding capability): all thinking-enabled agents in PentAGI also pass extra_body.thinking.clear_thinking: false so that reasoning_content from previous assistant turns is retained across the conversation. This is required on the standard API endpoint (/api/paas/v4) — on the Coding Plan endpoint it would be enabled by default. Improves reasoning continuity and cache hit rates in multi-turn tool call chains.
• All thinking-enabled agents also pass extra_body.tool_choice: auto defensively

Key Features:

• Long-Horizon Tasks: GLM-5.1 supports 8-hour sustained autonomous execution, ideal for complex multi-stage agentic workflows
• OpenClaw-Native Orchestration: GLM-5-Turbo is specifically optimized for tool invocation, instruction following, and long-chain execution
• Prompt Caching: Significant cost reduction on repeated context (cached input pricing shown)
• Ultra-Long Context: 200K tokens for GLM-5.x/4.7/4.6 series
• MoE Architecture: Efficient 744B/40B active (GLM-5/5.1), 355B/32B (GLM-4.5), 106B/12B (GLM-4.5-Air)
• Tool Calling: Seamless integration with 20+ pentesting tools via function calling
• Streaming: Real-time streaming with streaming tool calls support (GLM-4.6+)
• Multilingual: Exceptional Chinese and English NLP capabilities
• Free Options: GLM-4.7-Flash and GLM-4.5-Flash for prototyping and experimentation

LiteLLM Integration: Set GLM_PROVIDER=zai to enable model name prefixing when using default PentAGI configurations with LiteLLM proxy. Leave empty for direct API usage.

Kimi Provider Configuration

PentAGI integrates with Kimi from Moonshot AI, providing ultra-long context models with multimodal capabilities perfect for analyzing extensive codebases and documentation.

Configuration Variables

Variable	Default Value	Description
KIMI_API_KEY		Kimi API key for authentication
KIMI_SERVER_URL	https://api.moonshot.ai/v1	Kimi API endpoint URL (international)
KIMI_PROVIDER		Provider prefix for LiteLLM integration (optional)

Configuration Examples

# Direct API usage (international endpoint)
KIMI_API_KEY=your_kimi_api_key
KIMI_SERVER_URL=https://api.moonshot.ai/v1

# Alternative endpoint
KIMI_SERVER_URL=https://api.moonshot.cn/v1  # China

# With LiteLLM proxy
KIMI_API_KEY=your_litellm_key
KIMI_SERVER_URL=http://litellm-proxy:4000
KIMI_PROVIDER=moonshot  # Adds prefix to model names (moonshot/kimi-k3) for LiteLLM

Supported Models

PentAGI supports the four current Kimi models with tool calling, streaming, context caching, and multimodal input. Kimi K2.5, the older K2 series, kimi-latest, kimi-thinking-preview, and all Moonshot V1 models are retired and not included. Models marked with * are used in the default configuration.

Kimi K3 - Flagship (Always Reasoning)

Model ID	Thinking	Multimodal	Context	Price (Input Miss / Output / Cache Hit)	Use Case
kimi-k3*	✅ always	✅	1M	$3.00 / $15.00 / $0.30	Flagship for long-horizon coding and knowledge work; used by adviser with reasoning_effort: max

Kimi K2.7 Code Series - Coding-Focused

Model ID	Thinking	Multimodal	Context	Price (Input Miss / Output / Cache Hit)	Use Case
kimi-k2.7-code*	✅ always	✅	256K	$0.95 / $4.00 / $0.19	Coding-focused model used by generator, refiner, coder, and pentester
kimi-k2.7-code-highspeed*	✅ always	✅	256K	$1.90 / $8.00 / $0.38	Same model as kimi-k2.7-code with higher output throughput (~180-260 tokens/s) (primary_agent/assistant default)

Kimi K2.6 - Multimodal Model

Model ID	Thinking	Multimodal	Context	Price (Input Miss / Output / Cache Hit)	Use Case
kimi-k2.6*	✅ hybrid	✅	256K	$0.95 / $4.00 / $0.16	Utility and installer model with optional thinking

Prices: Per 1M tokens. K3 cache writes cost $3.00 with the default five-minute TTL or $6.00 with a one-hour TTL; cache hits cost $0.30. K2.7 and K2.6 table prices distinguish cache misses from cache hits.

CRITICAL — Kimi parameter constraints per model family: API returns invalid_request_error for any deviation:

• kimi-k3: always reasons, no thinking param at all; reasoning depth is set via the top-level reasoning_effort field (low/high/max, default max) — PentAGI pins it to max for all agents using this model. temperature MUST be 1.0, top_p MUST be 0.95, n MUST be 1, presence_penalty/frequency_penalty MUST be 0. Do not switch effort per call — it invalidates the prefix cache.
• kimi-k2.7-code / kimi-k2.7-code-highspeed: thinking may be omitted; if set explicitly, only {"type":"enabled","keep":"all"} is accepted (type: disabled is rejected). reasoning_effort is not supported. temperature MUST be 1.0, top_p MUST be 0.95, n MUST be 1; tool_choice: required is not supported (use auto).
• kimi-k2.6: thinking mode needs temperature=1.0, top_p=0.95, n=1, thinking.keep="all"; non-thinking mode needs temperature=0.6, top_p=0.95, n=1.
• All Kimi models: presence_penalty=0, frequency_penalty=0, tool_choice in {auto, none}.

Default Agent Configuration:

Strategy: kimi-k2.6 handles utility and installer work, kimi-k2.7-code-highspeed serves the primary/assistant loop, kimi-k2.7-code serves tool-heavy generator/refiner/coder/pentester roles, and kimi-k3 handles adviser reasoning. This configuration passed all 294 conformance cases.

Agent Role	Default Model	Thinking	Temperature	Top P	Max Output
Adviser (mentor/planner)	kimi-k3	Always (effort=max)	1.0	0.95	8192
Generator / Refiner	kimi-k2.7-code	Always (keep=all)	1.0	0.95	32768
Coder	kimi-k2.7-code	Enabled (keep=all)	1.0	0.95	20480
Pentester	kimi-k2.7-code	Enabled (keep=all)	1.0	0.95	16384
Primary Agent / Assistant	kimi-k2.7-code-highspeed	Enabled (keep=all)	1.0	0.95	16384
Installer	kimi-k2.6	Enabled	1.0	0.95	16384
Reflector / Searcher / Enricher	kimi-k2.6	Disabled	0.6	0.95	4096
Simple	kimi-k2.6	Disabled	0.6	0.95	8192
Simple JSON	kimi-k2.6	Disabled	0.6	0.95	4096

Key Features:

• Always-On Reasoning Flagship: kimi-k3 never disables thinking and offers a 1M token context for the most demanding long-horizon coding and knowledge work
• Ultra-Long Context: Up to 256K tokens (K2.7/K2.x) or 1M tokens (K3) for comprehensive codebase/documentation analysis
• Native Multimodal: K3, K2.7, and K2.6 support text, image, and video input
• Hybrid Thinking: K2.6 can toggle between thinking and non-thinking via reasoning.mode; K3 and K2.7 always reason
• Preserved Thinking (K2.7, K2.6): thinking.keep: "all" preserves historical reasoning_content across turns — required for multi-turn tool call chains
• Automatic Context Caching: K3/K2.7/K2.x models cache repeated prefixes
• Tool Calling: Full function-calling support for K3, K2.7, K2.x, and Moonshot V1
• Coding-Optimized Variants: kimi-k2.7-code/kimi-k2.7-code-highspeed target higher success rates on long-context programming tasks, with the highspeed variant tuned for throughput
• Multilingual: Strong Chinese, English, and multi-language support

Multi-turn with thinking + tool calls: PentAGI's universal reasoning preservation pattern (TextPartWithReasoning + WithPreserveReasoningContent) automatically ensures reasoning_content is sent back in the required TextContent → ToolCall order, satisfying Moonshot's "thinking is enabled but reasoning_content is missing in assistant tool call message" requirement.

LiteLLM Integration: Set KIMI_PROVIDER=moonshot to enable model name prefixing when using default PentAGI configurations with LiteLLM proxy. Leave empty for direct API usage.

Qwen Provider Configuration

PentAGI uses one OpenAI-compatible door for both Qwen Cloud and Alibaba Cloud Model Studio (DashScope). The bundled catalogue is the union of their agent-capable Chat Completions models, while the default role configuration uses only model IDs available on both platforms.

Configuration Variables

Variable	Default Value	Description
QWEN_API_KEY		Qwen Cloud, DashScope, or gateway API key
QWEN_SERVER_URL	https://dashscope-us.aliyuncs.com/compatible-mode/v1	Direct API or OpenAI-compatible gateway base URL
QWEN_PROVIDER		Gateway route prefix: qwen_cloud or dashscope

Configuration Examples

# Direct Alibaba Cloud Model Studio usage (Global/US endpoint)
QWEN_API_KEY=your_qwen_api_key
QWEN_SERVER_URL=https://dashscope-us.aliyuncs.com/compatible-mode/v1
QWEN_PROVIDER=

# Alternative endpoints
QWEN_SERVER_URL=https://dashscope-intl.aliyuncs.com/compatible-mode/v1  # International (Singapore)
QWEN_SERVER_URL=https://dashscope.aliyuncs.com/compatible-mode/v1       # Chinese Mainland (Beijing)

# Qwen Cloud through LiteLLM
QWEN_API_KEY=your_litellm_key
QWEN_SERVER_URL=http://litellm-proxy:4000
QWEN_PROVIDER=qwen_cloud

# Alibaba Cloud through LiteLLM
QWEN_PROVIDER=dashscope

Supported Models

PentAGI ships 50 text, reasoning, coding, and vision-language catalogue entries available from at least one of the two platforms. Image generation, video, speech, realtime, translation-only, embedding, reranking, and decision APIs use different protocols or billing units and are not exposed as PentAGI chat models. Prices below are Alibaba Cloud international list rates per 1M tokens where Alibaba offers the model; Qwen Cloud can bill differently.

Cross-platform model IDs used for portable configuration

Availability	Models
Qwen Cloud and DashScope	qwen3.8-max, qwen3.8-flash, qwen3.7-plus, qwen3.7-max, qwen3.6-flash, deepseek-v4.1-flash, deepseek-v4-pro
Qwen Cloud only	deepseek-v4-pro-0813
DashScope only	All other entries in the bundled catalogue

Flagship Models (Top-tier Reasoning)

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3.8-max	✅	—	—	—	$2.00/$6.00/$0.25	Newest flagship succeeding Qwen3.7-Max
qwen3.8-omni-flash	✅	✅	✅	✅	$0.15/$0.47/—	Current multimodal Omni tier
qwen3.7-max	✅	✅	✅	✅	$2.50/$7.50/$0.50	Next-gen flagship for agent-centric era
qwen3.6-max-preview	✅	✅	✅	✅	$1.30/$7.80/$0.13	Preview Max with enhanced vibe coding & front-end skills
qwen3-max	✅	✅	✅	✅	$1.20/$6.00/$0.24	Previous-gen flagship with agent programming upgrades
qwen-max	❌	✅	✅	✅	$1.60/$6.40/—	Legacy 32K text flagship
qwen-plus	✅	✅	✅	✅	$0.40/$4.00/$0.08	Qwen3-backbone Plus with switchable thinking modes

Balanced Plus Models (Mid-tier)

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3.7-plus	✅	—	—	—	$0.40/$1.60/$0.08	Cost-efficient tier of the Qwen3.7 generation
qwen3.6-plus	✅	✅	✅	✅	$0.50/$3.00/$0.05	Native VL Plus with agentic coding
qwen3.5-plus	✅	✅	✅	✅	$0.40/$2.40/$0.04	Previous-gen native VL with strong multimodal capabilities

Fast Flash Models (Cost-optimized)

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3.8-flash	✅	—	—	—	$0.15/$0.47/$0.016	Cost-efficient tier of the Qwen3.8 generation
qwen3.7-flash	✅	—	—	—	$0.03/$0.13/$0.02	Low-latency tier of the Qwen3.7 generation
qwen3.6-flash*	✅	✅	✅	✅	$0.25/$1.50/$0.05	Shared utility model
qwen3.5-flash	✅	✅	✅	✅	$0.10/$0.40/$0.01	Ultra-fast lightweight
qwen-flash	✅	✅	✅	✅	$0.05/$0.40/$0.01	Qwen3-series Flash with 1M context, tiered pricing

Code-Specialized Models

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3-coder-plus	❌	✅	✅	✅	$1.00/$5.00/$0.20	Strong coding agent with autonomous programming
qwen3-coder-flash	❌	✅	✅	✅	$0.30/$1.50/$0.06	Fast code-gen with multi-turn tool stability
qwen3-coder-next	❌	✅	✅	✅	$0.30/$1.50/—	Open-source code generation, SOTA at same scale

Vision-Language Models (Browser & Screenshot Analysis)

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3-vl-plus	✅	✅	✅	✅	$0.20/$1.60/$0.04	VL with visual agent capabilities, ultra-long video understanding
qwen3-vl-flash	✅	✅	✅	✅	$0.05/$0.40/$0.01	Small VL with 2D/3D localization for browser triage
qvq-max	✅	✅	✅	✅	$1.20/$4.80/—	Visual reasoning with chain-of-thought
qwen3-vl-235b-a22b-thinking	✅	—	—	—	$0.40/$4.00/—	Open-source 235B MoE VL (~22B active) with reasoning
qwen3-vl-235b-a22b-instruct	❌	—	—	—	$0.40/$1.60/—	Open-source 235B MoE VL (~22B active), instruction-following
qwen3-vl-32b-instruct	❌	—	—	—	$0.16/$0.64/—	Open-source 32B dense VL, instruction-following
qwen3-vl-30b-a3b-thinking	✅	—	—	—	$0.20/$2.40/—	Open-source 30B MoE VL (~3B active) with reasoning
qwen3-vl-30b-a3b-instruct	❌	—	—	—	$0.20/$0.80/—	Open-source 30B MoE VL (~3B active), instruction-following

Open-Source Qwen3.8 Series

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3.8-2.4t-a95b	✅	—	—	—	$2.00/$6.00/—	Open-source 3.8 flagship, always reasons
qwen3.8-27b	✅	—	—	—	$0.50/$3.00/$0.10	Dense open-weight 3.8 tier, hybrid thinking, 1M context

Open-Source Qwen3.6 Series

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3.6-27b	✅	✅	✅	✅	$0.60/$3.60/—	Native VL on hybrid architecture, on-premises ready
qwen3.6-35b-a3b	✅	✅	✅	✅	$0.25/$1.49/—	Efficient 35B MoE (~3B active) for continuous monitoring

Open-Source Qwen3.5 Series

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3.5-397b-a17b	✅	✅	✅	✅	$0.60/$3.60/—	Largest 397B params (~17B active), exceptional reasoning
qwen3.5-122b-a10b	✅	✅	✅	✅	$0.40/$3.20/—	Large 122B params (~10B active), strong balance
qwen3.5-35b-a3b	✅	✅	✅	✅	$0.25/$2.00/—	Efficient 35B MoE (~3B active), cost-effective
qwen3.5-27b	✅	✅	✅	✅	$0.30/$2.40/—	Medium 27B with hybrid linear attention + sparse MoE

Open-Source Qwen3 Coder Series

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3-coder-480b-a35b-instruct	❌	✅	✅	✅	$1.50/$7.50/—	Largest open coder MoE (480B/~35B active)
qwen3-coder-30b-a3b-instruct	❌	✅	✅	✅	$0.45/$2.25/—	Efficient 30B MoE (~3B active), repository-scale

Open-Source Qwen3 Dense & MoE Series

Model ID	Thinking	Intl	Global/US	China	Price (Input/Output/Cache)	Use Case
qwen3-next-80b-a3b-thinking	✅	✅	✅	✅	$0.15/$1.20/—	Next-gen 80B MoE (~3B active) thinking-only
qwen3-next-80b-a3b-instruct	❌	✅	✅	✅	$0.15/$1.20/—	Next-gen 80B MoE instruction-following
qwen3-235b-a22b-thinking-2507	✅	—	—	—	$0.23/$2.30/—	235B MoE (~22B active) thinking variant
qwen3-30b-a3b-thinking-2507	✅	—	—	—	$0.20/$2.40/—	30B MoE (~3B active) thinking variant
qwen3-30b-a3b-instruct-2507	❌	—	—	—	$0.20/$0.80/—	30B MoE (~3B active) non-thinking variant

Third-Party Models

These models share the OpenAI-compatible Qwen door. Availability differs by platform; the cross-platform table above is authoritative for portable role configuration.

Model ID	Thinking	Context	Price (Input/Output/Cache)	Use Case
glm-5.3-prime	✅	1M	$2.80/$8.80/—	DashScope priority GLM route
glm-5.2-fast-preview	✅	1M	$2.80/$8.80/—	DashScope high-throughput GLM 5.2 route
glm-5.2	✅	1M	$1.40/$4.40/$0.28	Zhipu AI GLM flagship route
deepseek-v4.1-flash*	✅	1M	$0.15/$0.60/—	Current shared low-latency DeepSeek model
deepseek-v4-pro*	✅	1M	$2.40/$4.80/$0.20	Shared model for security and tool-heavy roles
deepseek-v4-pro-0813	✅	1M	$2.40/$4.80/$0.20	Qwen Cloud-only V4 Pro snapshot
deepseek-v4-flash-0731	✅	1M	$0.44/$1.32/$0.088	Legacy DashScope Flash snapshot
kimi-k3	✅	1M	$3.00/$15.00/$0.30	Current Kimi flagship on DashScope
kimi-k2.7-code	✅	262K	$0.95/$4.00/$0.19	Moonshot coding model, thinking always on, 16K output ceiling

Prices: Per 1M tokens. Cache pricing reflects implicit cache hit (when available); MoE/dense open-source models do not expose cache pricing. Tiered models (Max/Plus) show lowest-tier pricing (typically ≤32k or ≤256k input); larger contexts incur higher rates per Alibaba Cloud pricing. deepseek-v4-flash-0731 shows the busy-hours rate; idle hours bill half.

Region Availability:

• Intl (International): Singapore region (dashscope-intl.aliyuncs.com)
• Global/US: US Virginia region (dashscope-us.aliyuncs.com)
• China: Chinese Mainland Beijing region (dashscope.aliyuncs.com)
• —: availability in that region is not recorded here

Default Agent Configuration:

Agent Role	Default Model	Tier
simple, simple_json, reflector, searcher, enricher	qwen3.6-flash	Utility
primary_agent, assistant, coder, installer, pentester	deepseek-v4.1-flash	Workhorse
generator, refiner, adviser	deepseek-v4-pro	Planning

The role configuration must run unchanged behind qwen_cloud/ and dashscope/. Qwen 3.6 Flash handles utility calls, DeepSeek V4.1 Flash provides the lower-cost workhorse tier, and DeepSeek V4 Pro remains on planning and advice. Thinking controls are left at provider defaults because Qwen Cloud does not accept the same disable operation that DashScope supports.

Key Features:

• Agent-Centric Design: Qwen3.7-Max is purpose-built for long-horizon autonomous execution and tool invocation
• Automatic Context Caching: 30-50% cost reduction on repeated context with implicit cache
• Extended Thinking: Chain-of-thought reasoning for complex security analysis (Qwen3.7/3.6/3.5/3-Max, QVQ-Max)
• Code Specialization: Qwen3-Coder series with multi-turn tool interaction and repository-level understanding
• Vision-Language: Qwen3-VL series for browser screenshot triage, 2D/3D localization, OCR-level analysis
• Tool Calling: Seamless integration with 20+ pentesting tools via function calling
• Streaming: Real-time response streaming for interactive workflows
• Multilingual: Strong Chinese, English, and multi-language support
• Open-Source Variants: Dense and MoE models from 27B to 2.4T for on-premises/air-gapped deployments

LiteLLM Integration: Set QWEN_PROVIDER=qwen_cloud for Qwen Cloud routes or QWEN_PROVIDER=dashscope for Alibaba Cloud routes. Leave it empty for direct DashScope API usage.

Alternative Integrations

DashScope is fully OpenAI-compatible, so Qwen can also power two other PentAGI subsystems through the standard OpenAI client.

As embedding provider (text-embedding-v4, see Alibaba Cloud Model Studio pricing):

EMBEDDING_PROVIDER=openai
EMBEDDING_URL=https://dashscope-intl.aliyuncs.com/compatible-mode/v1  # International (Singapore)
# EMBEDDING_URL=https://dashscope.aliyuncs.com/compatible-mode/v1     # Chinese Mainland
EMBEDDING_KEY=sk-*******
EMBEDDING_MODEL=text-embedding-v4
EMBEDDING_BATCH_SIZE=         # optional, default applies
EMBEDDING_STRIP_NEW_LINES=    # optional, default applies

Note: the Global/US DashScope endpoint (dashscope-us.aliyuncs.com) does not expose embedding APIs — use the International or China endpoints for text-embedding-v4.

As OpenAI-typed custom LLM provider: instead of the dedicated QWEN_* variables, you can wire any Qwen chat model through PentAGI's custom OpenAI-compatible provider by pointing OPENAI_SERVER_URL (or a custom provider entry) to the DashScope /compatible-mode/v1 endpoint and selecting the desired Qwen model name. Useful when you already manage all model traffic through a single OpenAI-shaped client (e.g. shared with LiteLLM/OneAPI proxies).

MiniMax Provider Configuration

PentAGI integrates with MiniMax's M-series through the OpenAI-compatible https://api.minimax.io/v1 endpoint: large-context agentic models with tool calling, JSON output, and streaming.

Configuration Variables

Variable	Default Value	Description
MINIMAX_API_KEY		MiniMax API key for authentication
MINIMAX_SERVER_URL	https://api.minimax.io/v1	MiniMax API endpoint URL
MINIMAX_PROVIDER		Provider prefix for LiteLLM integration (optional)

Configuration Examples

# Direct API usage
MINIMAX_API_KEY=your_minimax_api_key
MINIMAX_SERVER_URL=https://api.minimax.io/v1

# With LiteLLM proxy
MINIMAX_API_KEY=your_litellm_key
MINIMAX_SERVER_URL=http://litellm-proxy:4000
MINIMAX_PROVIDER=minimax  # Adds prefix to model names (minimax/MiniMax-M3) for LiteLLM

Supported Models

PentAGI ships 3 MiniMax models with tool calling, JSON output, and streaming. MiniMax-M3 is the default catalogue model; the bundled agent configuration uses MiniMax-M2.7 for roles where conformance testing showed more reliable context retention and unified-diff generation.

Model ID	Context	Price (Input/Output, ≤512K context)	Use Case
MiniMax-M3*	~1M	$0.30/$1.20 (2x above 512K tokens)	Latest flagship for agentic reasoning, tool use, code generation, and long-context tasks
MiniMax-M2.7	204K	$0.30/$1.20	Reliable reasoning and coding model used by stateful and diff-producing agents
MiniMax-M2.7-highspeed	204K	$0.60/$2.40	Low-latency variant of M2.7 for fast-response scenarios

LiteLLM Integration: Set MINIMAX_PROVIDER=minimax to enable model name prefixing when using default PentAGI configurations with LiteLLM proxy. Leave empty for direct API usage.

Mistral Provider Configuration

PentAGI talks to Mistral through the OpenAI-compatible https://api.mistral.ai/v1 endpoint: the Medium/Large/Small line, the Ministral small models, Codestral for code, and one Z.ai model Mistral serves itself.

Configuration Variables

Variable	Default Value	Description
MISTRAL_API_KEY		Mistral API key for authentication
MISTRAL_SERVER_URL	https://api.mistral.ai/v1	Mistral API endpoint URL
MISTRAL_PROVIDER		Provider prefix for LiteLLM integration (optional)

Configuration Examples

# Direct API usage
MISTRAL_API_KEY=your_mistral_api_key
MISTRAL_SERVER_URL=https://api.mistral.ai/v1

# With LiteLLM proxy
MISTRAL_API_KEY=your_litellm_key
MISTRAL_SERVER_URL=http://litellm-proxy:4000
MISTRAL_PROVIDER=mistral  # Adds prefix to model names (mistral/mistral-small-latest) for LiteLLM

Supported Models

PentAGI ships 6 Mistral models. The default configuration uses mistral-small-latest for utility and read-heavy agents, mistral-large-latest for primary and execution agents, and mistral-medium-latest for planning and advice. Small, Medium, and Large each have a 256K-token context window.

Model ID	Price (Input/Output)	Reasons	Use Case
mistral-small-latest*	$0.15/$0.60	yes	Hybrid instruct/reasoning/coding model for utility and read-heavy agents
mistral-medium-latest	$1.50/$7.50	yes	Frontier-class multimodal model for planning and advice
mistral-large-latest	$0.50/$1.50	no	General-purpose model for primary, assistant, coding, and pentesting
codestral-latest	$0.30/$0.90	no	Code completion and fill-in-the-middle
zai-glm-5-2	$1.40/$4.40	yes	Z.ai GLM 5.2 served by Mistral, public preview
zai-glm-5-3	$1.40/$4.40	yes	Z.ai GLM 5.3 served by Mistral, public preview; thinking cannot be turned off

LiteLLM Integration: Set MISTRAL_PROVIDER=mistral to enable model name prefixing when using default PentAGI configurations with LiteLLM proxy. Leave empty for direct API usage.

xAI (Grok) Provider Configuration

PentAGI talks to xAI through the OpenAI-compatible https://api.x.ai/v1 endpoint: the Grok 4.x line with large context windows, plus a coding model.

Configuration Variables

Variable	Default Value	Description
XAI_API_KEY		xAI API key for authentication
XAI_SERVER_URL	https://api.x.ai/v1	xAI API endpoint URL
XAI_PROVIDER		Provider prefix for LiteLLM integration (optional)

Configuration Examples

# Direct API usage
XAI_API_KEY=your_xai_api_key
XAI_SERVER_URL=https://api.x.ai/v1

# With LiteLLM proxy
XAI_API_KEY=your_litellm_key
XAI_SERVER_URL=http://litellm-proxy:4000
XAI_PROVIDER=xai  # Adds prefix to model names (xai/grok-4.3) for LiteLLM

Supported Models

PentAGI lists seven xAI Chat Completions model IDs that responded through the tested API. Catalogue availability does not imply suitability as an agent default. The bundled configuration uses grok-4.3 for tool-heavy roles, including searcher, and grok-4.20-0309-non-reasoning for simple, simple_json, reflector, and enricher; the exact bindings are in backend/pkg/providers/xai/config.yml. In saved generator chains, grok-4.3 called subtask_list directly on all nine, whereas grok-4.6 returned text without a tool call on all nine. The full replay matrix records outcomes and limitations. The Responses-only multi-agent model is not listed because PentAGI agents supply their own client-side tools.

Model ID	Context	Price (Input/Output)	Reasons	Saved-chain result
grok-4.7	500K	$2.00/$6.00	yes	API responds; generator/reflector refusals make it unsuitable as a default
grok-4.6	500K	$2.00/$6.00	yes	API responds; all nine saved generator requests returned text without a tool
grok-4.5	500K	$2.00/$6.00	yes	API responds; eight of nine generator requests explicitly refused
grok-4.3*	1M	$1.25/$2.50	yes	Direct plan on all nine saved generator chains; tool-role default and fallback
grok-4.20-0309-reasoning	1M	$1.25/$2.50	yes	Four direct plans, three more after safe tool continuation, two pending
grok-4.20-0309-non-reasoning*	1M	$1.25/$2.50	no	Utility-role default; six plans after safe tool continuation, three pending
grok-build-0.1	256K	$1.00/$2.00	yes	Coding model; five plans after safe tool continuation, four pending

Note: prices are for prompts under 200K tokens; at or above that threshold xAI applies the higher long-context rate to every token in the request.

LiteLLM Integration: Set XAI_PROVIDER=xai to enable model name prefixing when using default PentAGI configurations with LiteLLM proxy. Leave empty for direct API usage.

Advanced Setup

Langfuse Integration

Langfuse provides advanced capabilities for monitoring and analyzing AI agent operations.

1. Configure Langfuse environment variables in existing .env file.

Langfuse valuable environment variables

Database Credentials

• LANGFUSE_POSTGRES_USER and LANGFUSE_POSTGRES_PASSWORD - Langfuse PostgreSQL credentials
• LANGFUSE_CLICKHOUSE_USER and LANGFUSE_CLICKHOUSE_PASSWORD - ClickHouse credentials
• LANGFUSE_REDIS_AUTH - Redis password

Encryption and Security Keys

• LANGFUSE_SALT - Salt for hashing in Langfuse Web UI
• LANGFUSE_ENCRYPTION_KEY - Encryption key (32 bytes in hex)
• LANGFUSE_NEXTAUTH_SECRET - Secret key for NextAuth

Admin Credentials

• LANGFUSE_INIT_USER_EMAIL - Admin email
• LANGFUSE_INIT_USER_PASSWORD - Admin password
• LANGFUSE_INIT_USER_NAME - Admin username

API Keys and Tokens

• LANGFUSE_INIT_PROJECT_PUBLIC_KEY - Project public key (used from PentAGI side too)
• LANGFUSE_INIT_PROJECT_SECRET_KEY - Project secret key (used from PentAGI side too)

S3 Storage

• LANGFUSE_S3_ACCESS_KEY_ID - S3 access key ID
• LANGFUSE_S3_SECRET_ACCESS_KEY - S3 secret access key

2. Enable integration with Langfuse for PentAGI service in .env file.

LANGFUSE_BASE_URL=http://langfuse-web:3000
LANGFUSE_PROJECT_ID= # default: value from ${LANGFUSE_INIT_PROJECT_ID}
LANGFUSE_PUBLIC_KEY= # default: value from ${LANGFUSE_INIT_PROJECT_PUBLIC_KEY}
LANGFUSE_SECRET_KEY= # default: value from ${LANGFUSE_INIT_PROJECT_SECRET_KEY}

3. Run the Langfuse stack:

curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose-langfuse.yml
docker compose -f docker-compose.yml -f docker-compose-langfuse.yml up -d

Visit localhost:4000 to access Langfuse Web UI with credentials from .env file:

• LANGFUSE_INIT_USER_EMAIL - Admin email
• LANGFUSE_INIT_USER_PASSWORD - Admin password

Monitoring and Observability

For detailed system operation tracking, integration with monitoring tools is available.

1. Enable integration with OpenTelemetry and all observability services for PentAGI in .env file.

OTEL_HOST=otelcol:8148

2. Run the observability stack:

curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose-observability.yml
docker compose -f docker-compose.yml -f docker-compose-observability.yml up -d

Visit localhost:3000 to access Grafana Web UI.

Note

If you want to use Observability stack with Langfuse, you need to enable integration in .env file to set LANGFUSE_OTEL_EXPORTER_OTLP_ENDPOINT to http://otelcol:4318.

To run all available stacks together (Langfuse, Graphiti, and Observability):

docker compose -f docker-compose.yml -f docker-compose-langfuse.yml -f docker-compose-graphiti.yml -f docker-compose-observability.yml up -d

You can also register aliases for these commands in your shell to run it faster:

alias pentagi="docker compose -f docker-compose.yml -f docker-compose-langfuse.yml -f docker-compose-graphiti.yml -f docker-compose-observability.yml"
alias pentagi-up="docker compose -f docker-compose.yml -f docker-compose-langfuse.yml -f docker-compose-graphiti.yml -f docker-compose-observability.yml up -d"
alias pentagi-down="docker compose -f docker-compose.yml -f docker-compose-langfuse.yml -f docker-compose-graphiti.yml -f docker-compose-observability.yml down"

Knowledge Graph Integration (Graphiti)

Important

Graphiti is an optional beta integration and is disabled by default. Review Limitations and Security before enabling it in production.

PentAGI integrates with Graphiti, a temporal knowledge graph system powered by Neo4j, to provide advanced semantic understanding and relationship tracking for AI agent operations. The vxcontrol fork provides custom entity and edge types that are specific to pentesting purposes.

What is Graphiti?

Graphiti asynchronously extracts structured knowledge from agent interactions and builds a graph of entities, relationships, evidence, and temporal context. PentAGI sends agent responses and tool executions to Graphiti and exposes the graphiti_search tool to enabled agents. Graphiti complements the primary pgvector memory; it does not replace it.

• Semantic Memory: Store and recall relationships between tools, targets, vulnerabilities, and techniques
• Contextual Understanding: Track how different pentesting actions relate to each other over time
• Flow-Scoped Recall: Reuse knowledge within the active flow without exposing data from other engagements by default
• Advanced Querying: Search temporal context, relationships, successful tools, recent episodes, and entities by type

When enabled, PentAGI captures agent responses, tool execution details, and flow/task/subtask context. Ingestion is asynchronous, so newly submitted events can take time to become searchable.

Deployment Modes and Enabling

Graphiti can run as the bundled Neo4j + Graphiti stack, as an external service, or remain disabled.

For the bundled stack, configure .env:

GRAPHITI_ENABLED=true
GRAPHITI_TIMEOUT=30
GRAPHITI_URL=http://graphiti:8000
GRAPHITI_LLM_CLIENT_TYPE=openai

# Reused by the Graphiti OpenAI preset
OPEN_AI_KEY=your_openai_api_key
OPEN_AI_SERVER_URL=https://api.openai.com/v1

# Bundled Neo4j
NEO4J_USER=neo4j
NEO4J_DATABASE=neo4j
NEO4J_PASSWORD=replace_with_a_strong_password
NEO4J_URI=bolt://neo4j:7687

Download the optional compose file and the Neo4j settings with the APOC plugin Graphiti needs when installing manually, then start both stacks:

curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose-graphiti.yml
mkdir -p neo4j/conf neo4j/plugins
for f in conf/neo4j.conf conf/apoc.conf plugins/apoc-5.26.19-core.jar; do
  curl -fsSL -o "neo4j/$f" "https://raw.githubusercontent.com/vxcontrol/pentagi/master/examples/neo4j/$f"
done
docker compose -f docker-compose.yml -f docker-compose-graphiti.yml up -d

The base stack must create the external pentagi-network before the Graphiti stack can start. The installer handles stack ordering automatically.

For an external Graphiti deployment, set GRAPHITI_ENABLED=true and point GRAPHITI_URL to its API. Do not start docker-compose-graphiti.yml; configure providers, embeddings, the graph database, and ingest tuning on the external service itself.

PentAGI enables its client only when both GRAPHITI_ENABLED=true and GRAPHITI_URL is non-empty. At startup it performs three health-check attempts with a two-second backoff. If they all fail, PentAGI logs a warning and continues with Graphiti disabled.

LLM Provider and Model Presets

GRAPHITI_LLM_CLIENT_TYPE selects one deployment-wide preset. Model names and call parameters are not environment variables; they live in graphiti/<provider>.yaml.

Preset	Credentials and endpoint	Shipped main model
openai	OPEN_AI_KEY, OPEN_AI_SERVER_URL	openai/gpt-5-mini
gemini	GEMINI_API_KEY, GEMINI_SERVER_URL	gemini/gemini-3.5-flash-lite
custom	LLM_SERVER_KEY, LLM_SERVER_URL	Qwen/Qwen3.6-27B-FP8
litellm	GRAPHITI_LITELLM_API_KEY, GRAPHITI_LITELLM_BASE_URL	openrouter/openai/gpt-oss-20b

The Gemini preset uses Graphiti's LiteLLM/OpenAI-compatible client path. Point GEMINI_SERVER_URL at a compatible gateway if the native Gemini endpoint does not provide the required OpenAI-compatible API.

Each preset file must contain a matching provider plus MODEL_NAME and SMALL_MODEL_NAME mappings. The small model is used for reranking and lighter calls. Supported call settings include temperature, token limits, sampling and penalty parameters, JSON mode, reasoning effort, verbosity, pricing metadata, and provider-specific extra_body.

The installer copies examples/graphiti beside the installation as ./graphiti. The compose mount is controlled by:

GRAPHITI_CONFIG_PATH=./graphiti
GRAPHITI_CONFIG_DIR=llm_configs

GRAPHITI_CONFIG_PATH may point directly to ./examples/graphiti for development. GRAPHITI_CONFIG_DIR=llm_configs activates the mounted presets. If an older .env omits that variable, a newer compose file mounts an empty host directory at the unused configs path instead of hiding the presets built into the image.

Note

GRAPHITI_MODEL_NAME is obsolete and ignored. Edit the active YAML preset instead, then restart the Graphiti container.

Graphiti Embedding Configuration

By default, Graphiti uses the active LLM preset's credentials and its default OpenAI embedding model. To use PentAGI's shared embedding endpoint explicitly:

GRAPHITI_SEPARATE_EMBEDDING=true
EMBEDDING_URL=https://embedding.example.com/v1
EMBEDDING_KEY=your_embedding_api_key
EMBEDDING_MODEL=openai/text-embedding-3-large

Graphiti's embedder is OpenAI-compatible. EMBEDDING_PROVIDER is used by PentAGI but is not passed to Graphiti, so a non-OpenAI-compatible embedding provider cannot be shared directly.

Ingestion and Extraction Tuning

The supplied defaults prioritize flow isolation and limit expensive extraction to useful events.

Ingest policy actions:

• REJECT: do not store the episode.
• SKIP_LLM: store the episode for retrieval but do not extract nodes or edges.
• PROCESS: store the episode and run full LLM extraction.

Variable	Default	When to change it
GRAPHITI_INGEST_POLICY_RULES	{"graphiti_search":"REJECT","tool_execution_terminal":"PROCESS","tool_execution_file":"PROCESS"}	Add narrow, case-insensitive name/source patterns when specific events need different handling
GRAPHITI_INGEST_POLICY_FIELD	both	Restrict matching to name or source_description only when event naming is controlled
GRAPHITI_INGEST_POLICY_DEFAULT_ACTION	SKIP_LLM	Use PROCESS only when every unmatched event justifies extraction cost
GRAPHITI_INGEST_USE_GROUP_ACTORS	true	Keep enabled to preserve FIFO ordering independently for each flow
GRAPHITI_INGEST_WORKER_COUNT	16	Raise for more concurrent flows when the LLM and database have capacity; lower to control load
GRAPHITI_INGEST_LOCK_BY_GROUP_ID	true	Used only in shared-pool mode; ignored when group actors are enabled
GRAPHITI_INGEST_TASK_MAX_RETRIES	1 (0-5)	Increase for transient LLM/network failures
GRAPHITI_INGEST_TASK_RETRY_DELAY_SEC	2.0 (0.5-60)	Increase when an upstream service needs more recovery time
GRAPHITI_INGEST_TASK_TIMEOUT_SEC	0 (0-3600)	Set a finite value to prevent one stalled request from blocking a flow; 0 disables the timeout
GRAPHITI_INGEST_QUEUE_MAX_SIZE	0	Set a bound to return HTTP 429 instead of allowing an unlimited backlog
GRAPHITI_INGEST_DEAD_LETTER_ENABLED	false	Enable when failed episodes must be retained for operational review

Extraction uses the following fallback order: full combined extraction (nodes, attributes, summaries, and edges in one call), regular combined extraction (nodes and edges), then separate node/edge extraction. Empty or failed combined results automatically fall back; these log messages are expected during normal operation.

Variable	Default	Effect
GRAPHITI_TAXONOMY_LAYER_PROFILE	STRUCTURAL,EVIDENCE,PROGRESS,ATTEMPT	Controls which edge classes appear in prompts and pass validation; full/all enables every class and minimal selects the core attack graph
GRAPHITI_USE_COMBINED_FULL_EXTRACTION	true	Enables the most compact single-call extraction path
GRAPHITI_USE_COMBINED_EXTRACTION	true	Enables the regular combined fallback
GRAPHITI_COMBINED_FULL_GATING_ENABLED	true	Skips expensive full extraction for low-signal administrative/search events
GRAPHITI_COMBINED_DIAGNOSTIC_SAMPLES	false	Includes content samples in diagnostics; keep disabled because pentest output can contain credentials
GRAPHITI_ANCHOR_NODE_MODE	smart	smart loads all key entities plus limited high-volume types; limit applies one total cap
GRAPHITI_ANCHOR_NODE_LIMIT	25 (1-500)	Total anchor cap in limit mode
GRAPHITI_ANCHOR_MASS_TYPE_LIMIT	10 (1-100)	Per-type cap in smart mode; 0 is invalid
GRAPHITI_ANCHOR_QUERY_TIMEOUT	10 (1-60)	Bounds anchor lookup; timeout degrades gracefully to no anchors

Anchors connect entities across episodes and are used by the separate extraction path. Combined extraction has already produced its edges and does not perform this anchor lookup.

These flags are passed as process environment variables by the bundled compose file. This is important for combined extraction because Graphiti reads those flags when Python modules are imported.

Runtime, Logging, and Neo4j

The values below are PentAGI's recommended .env.example/compose defaults, not the raw Graphiti image fallbacks. Running a freshly pulled image behind an old compose file can instead enable telemetry and global search, use one shared-pool worker with PROCESS as the unmatched ingest action, enable the full taxonomy, and disable combined extraction. Keep the image, compose file, .env, and presets in sync.

Variable	Default	Guidance
GRAPHITI_CPUS, GRAPHITI_MEMORY	2.0, 2G	Container limits; raise together with concurrency only after observing CPU and memory pressure
GRAPHITI_SEMAPHORE_LIMIT	20	Limits parallel Graphiti coroutines; it is separate from ingest worker concurrency
GRAPHITI_TELEMETRY_ENABLED	false	Enables anonymous Graphiti telemetry when set to true
GRAPHITI_LOG_LEVEL	INFO	Use DEBUG temporarily; it can produce sensitive and high-volume output
GRAPHITI_LOG_STDOUT	events	off, events, or full; events is recommended for containers
GRAPHITI_FLOW_LOGGER_WARN_COUNT	256	Warns about growth of cached per-flow loggers; 0 disables the warning
GRAPHITI_DEBUG_RUNTIME_RESOURCES	false	Enables /debug/runtime-resources; expose only to trusted operators
GRAPHITI_SEARCH_SCOPE	flowid	Keep for flow/tenant isolation; all enables global searches and can expose other engagements
GRAPHITI_LOG_FORMAT	json	Reserved by the current deployment contract; the Graphiti logger does not yet apply it
NEO4J_CPUS, NEO4J_MEMORY	4.0, 4G	Neo4j container limits; use neo4j-admin server memory-recommendation --docker for production sizing
NEO4J_SHM_SIZE	4g	/dev/shm limit; actual use counts toward the container memory limit
NEO4J_NOFILE	65536	Open-file soft/hard limit, suitable for many indexes and concurrent connections
NEO4J_HEAP_INITIAL_SIZE, NEO4J_HEAP_MAX_SIZE, NEO4J_PAGECACHE_SIZE	2G, 2G, 1G	JVM heap/page cache sizing; NEO4J_CPUS/NEO4J_MEMORY only cap the container, the JVM does not reliably size itself to fit inside that cap on its own. Defaults favor heap over page cache — suited to a low write-throughput deployment with occasional wide reads, since query execution/result materialization lives in heap while a small dataset is already comfortably held by 1G of page cache; re-run neo4j-admin server memory-recommendation --docker once real data volume is known
NEO4J_TRANSACTION_MAX	1G	Caps a single transaction's memory (db.memory.transaction.max) so one runaway/unbounded query (e.g. a Cartesian product or an unbounded variable-length path before a LIMIT) fails cleanly with an out-of-memory Cypher error instead of exhausting the whole heap and taking down every other query on the server
NEO4J_BOLT_ADVERTISED_ADDRESS	empty	Set only when Neo4j Browser and the Bolt connector are reverse-proxied on different public domains (e.g. behind Guarder with CORS/cookie-group support for cross-origin bolt access); format host:port. Left empty, Neo4j's discovery endpoint advertises whatever Host header the request arrived with, which is correct only when both share one domain
NEO4J_HTTP_ADVERTISED_ADDRESS	empty	Set only when a reverse proxy in front of Neo4j Browser strips or rewrites the Host header, making the dynamic Host-header-based advertised address incorrect; format host:port. Leave empty in the common case (proxy forwards Host unchanged)

NEO4J_USER, NEO4J_PASSWORD, NEO4J_URI, and NEO4J_DATABASE configure the bundled connection. Neo4j Community Edition supports only its default database; do not configure a separate database name that requires Enterprise multi-database support.

The installer copies examples/neo4j beside the installation as ./neo4j. It contains static, non-.env-tunable settings that don't have a NEO4J_* variable: conf/neo4j.conf and conf/apoc.conf, plus a version-pinned plugins/apoc-*-core.jar. The compose mount is controlled by:

NEO4J_DIR=./neo4j

NEO4J_DIR may point directly to ./examples/neo4j for development. Both conf/ and plugins/ are mounted read-only; the stack still starts on Neo4j's built-in defaults (without APOC) if the directory is absent, since Docker creates an empty one automatically — but Graphiti writes relationships through APOC, so its graph then stays empty while PentAGI logs no error. Do not duplicate any NEO4J_* variable from the table above inside conf/neo4j.conf — the Neo4j Docker entrypoint always strips a matching line from the mounted file and re-appends the environment variable's value, so a duplicated setting in the file would be silently ignored.

The bundled stack currently wires Neo4j only. The Graphiti image contains FalkorDB support, but using it requires a separately configured deployment because the stock compose file does not expose GRAPHITI_GRAPH_BACKEND or FALKORDB_*.

Verification and Troubleshooting

Check service health, queue state, and logs:

docker compose -f docker-compose.yml -f docker-compose-graphiti.yml ps graphiti neo4j
docker compose -f docker-compose.yml -f docker-compose-graphiti.yml logs -f graphiti
curl -fsS http://localhost:8000/healthcheck
curl -fsS http://localhost:8000/queue-size

Neo4j Browser is available at http://localhost:7474; the Graphiti OpenAPI UI is at http://localhost:8000/docs. Both are bound to localhost by the stock compose file.

Common failures:

• A missing API key or base URL for the selected preset, a missing YAML file, or a YAML provider mismatch causes the Graphiti container to fail startup validation.
• LLM_CLIENT_TYPE=openai rejects local/custom model prefixes; use the custom preset for an OpenAI-compatible local server.
• In flowid search mode, requests without a group ID are rejected. PentAGI supplies the flow-derived group ID automatically.
• A bounded full queue returns HTTP 429. /queue-size reports waiting, processing, active-group, and dropped counters.
• Invalid retry, timeout, or anchor ranges fail startup rather than being silently normalized.

Update .env, docker-compose-graphiti.yml, the Graphiti image, and the graphiti preset directory together. Pulling only a new image can retain older compose defaults and silently change extraction behavior.

Limitations and Security

• Graphiti is beta and has no in-app graph explorer.
• One provider preset is active for the entire Graphiti deployment; it is not selected per PentAGI agent or flow.
• Graphiti extraction, reranking, and embeddings incur billing independently of the model used by the main PentAGI flow.
• Search is flow-scoped by default. Cross-flow reuse requires an explicit global-search design and must not be enabled on shared or multi-tenant deployments without additional isolation.
• The Graphiti HTTP API has no authentication layer in the bundled service. The stock compose binds it and Neo4j to 127.0.0.1; secure external deployments with network controls and authentication at a trusted reverse proxy.
• Agent and tool output may contain credentials and exploitation evidence. Protect Neo4j data, logs, dead letters, diagnostics, and backups accordingly.
• If Graphiti is unavailable, PentAGI continues with its primary memory and vector store after logging the failed startup health check. Set GRAPHITI_ENABLED=false to disable the integration explicitly.

GitHub and Google OAuth Integration

OAuth integration with GitHub and Google allows users to authenticate using their existing accounts on these platforms. This provides several benefits:

• Simplified login process without need to create separate credentials
• Enhanced security through trusted identity providers
• Access to user profile information from GitHub/Google accounts
• Seamless integration with existing development workflows

PentAGI uses PUBLIC_URL as the public origin/base URL for OAuth redirects. In the default deployment, both GitHub and Google callbacks are handled by:

${PUBLIC_URL}/api/v1/auth/login-callback

For GitHub OAuth:

1. Create a new OAuth App in your GitHub account.
2. Set Homepage URL to your PUBLIC_URL.
3. Set Authorization callback URL to ${PUBLIC_URL}/api/v1/auth/login-callback.
4. Add the client credentials to your .env file:

PUBLIC_URL=https://pentagi.example.com
OAUTH_GITHUB_CLIENT_ID=your_github_client_id
OAUTH_GITHUB_CLIENT_SECRET=your_github_client_secret

For Google OAuth:

1. Create OAuth credentials in your Google Cloud project.
2. Use the same callback endpoint: ${PUBLIC_URL}/api/v1/auth/login-callback.
3. Add the client credentials to your .env file:

PUBLIC_URL=https://pentagi.example.com
OAUTH_GOOGLE_CLIENT_ID=your_google_client_id
OAUTH_GOOGLE_CLIENT_SECRET=your_google_client_secret

Make sure PUBLIC_URL matches the externally accessible HTTPS address of your PentAGI instance and does not include the callback path itself. If the URL configured in the OAuth provider does not exactly match the callback generated by PentAGI, the provider will reject the login attempt with a redirect URI mismatch error.

Docker Image Configuration

PentAGI allows you to configure Docker image selection for executing various tasks. The system automatically chooses the most appropriate image based on the task type, but you can constrain this selection by specifying your preferred images:

Variable	Default	Description
PENTAGI_IMAGE	vxcontrol/pentagi:latest	Docker image used for the main PentAGI application service
DOCKER_DEFAULT_IMAGE	debian:latest	Default Docker image for general tasks and ambiguous cases
DOCKER_DEFAULT_IMAGE_FOR_PENTEST	vxcontrol/kali-linux	Default Docker image for security/penetration testing tasks
DOCKER_ALLOWED_IMAGES	empty	Comma-separated allow-list the selected image must belong to
DOCKER_IMAGE_SELECTION_MODE	llm	llm lets the model pick the image, fixed always uses the pentest image

PENTAGI_IMAGE changes the image used by the main pentagi service in docker-compose.yml. The DOCKER_DEFAULT_IMAGE and DOCKER_DEFAULT_IMAGE_FOR_PENTEST variables only affect automatic worker image selection for task execution inside PentAGI. They do not rewrite the rest of the Compose stack, so services such as pgvector, scraper, and the optional graphiti stack still use the image references defined in the compose files.

DOCKER_DEFAULT_IMAGE and DOCKER_DEFAULT_IMAGE_FOR_PENTEST are suggestions the model receives in the image selection prompt, not limits: on their own they do not stop a model from answering with some other image. Two settings turn them into limits:

• DOCKER_ALLOWED_IMAGES restricts the choice. An answer outside the list is discarded and the pentest image is used instead. An entry without a tag admits any tag of that repository, so vxcontrol/kali-linux also admits vxcontrol/kali-linux:2026.1. While the list is empty the model may pick any image, which is the default behaviour.
• DOCKER_IMAGE_SELECTION_MODE=fixed removes the choice altogether: the flow always runs in DOCKER_DEFAULT_IMAGE_FOR_PENTEST and no model call is made. Use it when weaker or local models answer with the wrong environment.

Regardless of these settings, an answer that is not a usable image reference never reaches Docker: the flow falls back to the pentest image and the rejected answer is logged.

Restricting the choice is useful for:

• Security Enforcement: Restricting usage to only verified and trusted images
• Environment Standardization: Using corporate or customized images across all operations
• Performance Optimization: Utilizing pre-built images with necessary tools already installed

Configuration examples:

# Using a custom PentAGI application image
PENTAGI_IMAGE=registry.example.com/security/pentagi:latest

# Using a custom image for general tasks
DOCKER_DEFAULT_IMAGE=mycompany/custom-debian:latest

# Using a specialized image for penetration testing
DOCKER_DEFAULT_IMAGE_FOR_PENTEST=mycompany/pentest-tools:v2.0

Note

If a user explicitly specifies a particular Docker image in their task, the system will try to use that exact image, ignoring these settings. These variables only affect the system's automatic image selection process.

For an advanced OpenVAS/GVM experiment that uses a custom pentest image, see OpenVAS via a Custom Pentest Image.

Restricted Networks, Docker Mirrors, and Proxies

If your environment cannot reach Docker Hub (docker.io) directly, changing PentAGI environment variables is usually not enough to fix image download failures. PentAGI still relies on Docker's own registry access for Compose-managed services, and the installer network checks also validate Docker Hub reachability.

For restricted networks:

1. Confirm that the host can resolve and reach docker.io.
2. If your environment requires an outbound proxy for PentAGI or installer HTTP traffic, set the PROXY_URL environment variable. To route Docker image pulls through a proxy, configure the Docker daemon or Docker Desktop proxy separately — Docker does not use PentAGI's PROXY_URL for registry access.
3. If Docker Hub is blocked or heavily rate-limited, configure an organization-approved registry mirror or registry proxy before running the installer or docker compose up.
4. Restart Docker after changing the daemon configuration, then rerun the installer checks or Compose startup.

Example Docker daemon mirror configuration:

{
  "registry-mirrors": ["https://mirror.example.com"]
}

On Linux, this is typically configured in /etc/docker/daemon.json. On Docker Desktop, use the equivalent Docker Engine or proxy settings. A Docker Hub mirror covers Docker Hub-hosted images such as vxcontrol/*, but the main Compose stack already includes quay.io/prometheuscommunity/postgres-exporter, and the optional observability stack includes gcr.io/cadvisor/cadvisor. Those registries still need direct access or individually approved proxy/mirror paths.

See the official Docker documentation for registry mirrors and daemon proxy configuration.

Troubleshooting: "failed to select primary docker image via llm call"

A flow that fails immediately with failed to select primary docker image via llm call usually indicates a problem with the configured LLM backend, not with Docker or the image registry. Older PentAGI versions reported the same failure as failed to get primary docker image, which led users to debug Docker even though the registry was healthy.

When a flow starts, PentAGI makes its first LLM call to choose the primary Docker image for the task. This image-selection call runs through the simple agent type, so a failure here points at the model assigned to that agent type rather than at Docker. A message such as API returned unexpected status code: 502 or 404 in this context is returned by the LLM backend, not by Docker Hub.

This is distinct from the registry reachability problems described above: if Docker pulls succeed and the Compose stack starts, but flow creation still fails at image selection, investigate the LLM backend rather than Docker.

To diagnose:

1. Check PentAGI logs first: docker logs pentagi.
2. Check the logs of your configured LLM backend (the server behind your provider or LLM_SERVER_URL).
3. Verify that the base URL, API key, and model name in Custom LLM Provider Configuration are correct and reachable from the container. If you assign different models per agent type, check the model used by the simple agent type, since image selection runs through it.
4. For custom, OpenAI-compatible, vLLM, or SGLang backends, confirm that the model supports tool calling (function calling) and that the matching tool-call parser is enabled. A missing or mismatched tool-call parser is a known cause of this failure.

Development

Development Requirements

• golang
• nodejs
• docker
• postgres

Environment Setup

Backend Setup

Run once cd backend && go mod download to install needed packages.

For generating swagger files have to run

swag init -g ../../pkg/server/router.go -o pkg/server/docs/ --parseDependency --parseInternal --parseDepth 2 -d cmd/pentagi

before installing swag package via

go install github.com/swaggo/swag/cmd/swag@v1.8.7

For generating graphql resolver files have to run

go run github.com/99designs/gqlgen --config ./gqlgen/gqlgen.yml

after that you can see the generated files in pkg/graph folder.

For generating ORM methods (database package) from sqlc configuration

docker run --rm -v $(pwd):/src -w /src --network pentagi-network -e DATABASE_URL="{URL}" sqlc/sqlc:1.27.0 generate -f sqlc/sqlc.yml

For generating Langfuse SDK from OpenAPI specification

fern generate --local

and to install fern-cli

pnpm add -g fern-api

Testing

For running tests cd backend && go test -v ./...

Frontend Setup

Run once cd frontend && pnpm install to install needed packages.

For generating graphql files have to run pnpm run graphql:generate which using graphql-codegen.ts file.

Be sure that you have graphql-codegen installed globally:

pnpm add -g graphql-codegen

After that you can run:

• pnpm run prettier to check if your code is formatted correctly
• pnpm run prettier:fix to fix it
• pnpm run lint to check if your code is linted correctly
• pnpm run lint:fix to fix it

For generating SSL certificates you need to run pnpm run ssl:generate which using generate-ssl.ts file or it will be generated automatically when you run pnpm run dev.

Backend Configuration

Edit the configuration for backend in .vscode/launch.json file:

• DATABASE_URL - PostgreSQL database URL (eg. postgres://postgres:postgres@localhost:5432/pentagidb?sslmode=disable)
• DOCKER_HOST - Docker SDK API (eg. for macOS DOCKER_HOST=unix:///Users/<my-user>/Library/Containers/com.docker.docker/Data/docker.raw.sock) more info

Optional:

• SERVER_PORT - Port to run the server (default: 8443)
• SERVER_USE_SSL - Enable SSL for the server (default: false)

PostgreSQL / pgvector connection pool sizing

PentAGI opens two independent connection pools to the same Postgres instance:

Pool	Env var	Default	Used by
Shared sql.DB	DATABASE_MAX_OPEN_CONNS	25	All sqlc queries and GORM handlers share a single *sql.DB
Shared pgxpool	DATABASE_VECTOR_MAX_CONNS	10	All pgvector stores (agent memory + knowledge API) share a single pool

Additional tuning knob:

• DATABASE_MAX_IDLE_CONNS — maximum idle connections kept open in the sql.DB pool between requests (default: 5).

Budget for the stock vxcontrol/pgvector image (max_connections = 100, superuser_reserved_connections = 3):

Available for client connections  = 97
  pentagi sql.DB  (DATABASE_MAX_OPEN_CONNS)   = 25
  pentagi pgxpool (DATABASE_VECTOR_MAX_CONNS) = 10
  pgexporter                                  =  3
  autovacuum workers                          =  3
  ─────────────────────────────────────────
  Total consumed                              = 41
  Free buffer                                 = 56  (≈ 58 %)

The defaults are sized for 10 parallel flows with concurrent API requests. If you run more flows or deploy multiple PentAGI instances against the same Postgres, raise max_connections via the command override in docker-compose.yml and increase the pool sizes proportionally:

pgvector:
  image: vxcontrol/pgvector:latest
  command: postgres -c max_connections=200

To inspect the live connection budget on a running deployment:

# Postgres limits
docker exec pgvector sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c \
  "SELECT name, setting FROM pg_settings
   WHERE name IN ('"'"'max_connections'"'"', '"'"'superuser_reserved_connections'"'"');"'

# Current usage vs. available
docker exec pgvector sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c \
  "SELECT max_conn, used, max_conn - used AS available
   FROM (SELECT current_setting('"'"'max_connections'"'"')::int AS max_conn,
                count(*) AS used FROM pg_stat_activity) t;"'

# Breakdown by client
docker exec pgvector sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c \
  "SELECT application_name, client_addr, state, count(*)
   FROM pg_stat_activity
   WHERE pid <> pg_backend_pid()
   GROUP BY 1, 2, 3 ORDER BY count DESC;"'

External PostgreSQL and schema handling

DATABASE_URL may point at any PostgreSQL instance, not only the bundled pgvector container. Two extra knobs apply when — and only when — TENANT_ID is set, because that is when PentAGI creates its own schema and rewrites the connection's search_path:

Env var	Default	Purpose
DATABASE_EXTENSIONS_SCHEMA	public	Schema holding the shared vector and pg_trgm extensions that every tenant's search_path must reach
DATABASE_SEARCH_PATH_VIA_OPTIONS	false	Send the tenant search_path inside the options startup parameter instead of as a bare connection parameter

Supabase (cloud or self-hosted) needs both of them considered, and is the reason they exist:

• Supabase installs its bundled extensions into an extensions schema instead of public, so set DATABASE_EXTENSIONS_SCHEMA=extensions. Without it, startup aborts with an error naming the schema where vector was actually found — no need to move a provider-managed extension with ALTER EXTENSION.
• Supabase's pooler (Supavisor) does not reliably forward a bare search_path connection parameter. Prefer a direct PostgreSQL connection: self-hosted, expose the db service port and bypass the supavisor service; cloud, use the "Direct connection" string (or the IPv4 add-on on IPv4-only networks). If the pooler cannot be bypassed, use its session mode and try DATABASE_SEARCH_PATH_VIA_OPTIONS=true — PentAGI verifies the effective schema on boot and refuses to start if it did not take effect, so a silent cross-tenant data mix-up is not possible.

Both settings are managed by the installer under Server Settings, next to TENANT_ID — see Running Several Instances for that scenario, and Multi-Instance Deployment for the full matrix, including the PgBouncer recipe (pool_mode = session, ignore_startup_parameters, per-tenant connect_query).

Frontend Configuration

Edit the configuration for frontend in .vscode/launch.json file:

• VITE_API_URL - Backend API URL. Omit the URL scheme (e.g., localhost:8080 NOT http://localhost:8080)
• VITE_USE_HTTPS - Enable SSL for the server (default: false)
• VITE_PORT - Port to run the server (default: 8000)
• VITE_HOST - Host to run the server (default: 0.0.0.0)

Running the Application

Backend

Run the command(s) in backend folder:

• Use .env file to set environment variables like a source .env
• Run go run cmd/pentagi/main.go to start the server

Note

The first run can take a while as dependencies and docker images need to be downloaded to setup the backend environment.

Frontend

Run the command(s) in frontend folder:

• Run pnpm install to install the dependencies
• Run pnpm run dev to run the web app
• Run pnpm run build to build the web app

Open your browser and visit the web app URL.

Testing LLM Agents

PentAGI includes a powerful utility called ctester for testing and validating LLM agent capabilities. This tool helps ensure your LLM provider configurations work correctly with different agent types, allowing you to optimize model selection for each specific agent role.

The utility features parallel testing of multiple agents, detailed reporting, and flexible configuration options.

Key Features

• Parallel Testing: Tests multiple agents simultaneously for faster results
• Comprehensive Test Suite: Evaluates basic completion, JSON responses, function calling, and penetration testing knowledge
• Detailed Reporting: Generates markdown reports with success rates and performance metrics
• Flexible Configuration: Test specific agents or test groups as needed
• Specialized Test Groups: Includes domain-specific tests for cybersecurity and penetration testing scenarios

Usage Scenarios

For Developers (with local Go environment)

If you've cloned the repository and have Go installed:

# Default configuration with .env file
cd backend
go run cmd/ctester/*.go -verbose

# Custom provider configuration
go run cmd/ctester/*.go -config ../examples/configs/openrouter.provider.yml -verbose

# Generate a report file
go run cmd/ctester/*.go -config ../examples/configs/deepinfra.provider.yml -report ../test-report.md

# Test specific agent types only
go run cmd/ctester/*.go -agents simple,simple_json,primary_agent -verbose

# Test specific test groups only
go run cmd/ctester/*.go -groups basic,advanced -verbose

For Users (using Docker image)

If you prefer to use the pre-built Docker image without setting up a development environment:

# Using Docker to test with default environment
docker run --rm -v $(pwd)/.env:/opt/pentagi/.env vxcontrol/pentagi /opt/pentagi/bin/ctester -verbose

# Test with your custom provider configuration
docker run --rm \
  -v $(pwd)/.env:/opt/pentagi/.env \
  -v $(pwd)/my-config.yml:/opt/pentagi/config.yml \
  vxcontrol/pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/config.yml -agents simple,primary_agent,coder -verbose

# Generate a detailed report
docker run --rm \
  -v $(pwd)/.env:/opt/pentagi/.env \
  -v $(pwd):/opt/pentagi/output \
  vxcontrol/pentagi /opt/pentagi/bin/ctester -report /opt/pentagi/output/report.md

Using Pre-configured Providers

The Docker image comes with built-in support for major providers (OpenAI, Anthropic, Gemini, Ollama) and pre-configured provider files for additional services (OpenRouter, OpenCode, Atlas, OrcaRouter, DeepInfra, DeepSeek, Moonshot, Novita, xAI):

# Test with OpenRouter configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/openrouter.provider.yml

# Test with OpenCode Go plan configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/opencode.provider.yml

# Test with DeepInfra configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/deepinfra.provider.yml

# Test with DeepSeek configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type deepseek

# Test with GLM configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type glm

# Test with Kimi configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type kimi

# Test with Qwen configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type qwen

# Test with DeepSeek configuration file for custom provider
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/deepseek.provider.yml

# Test with Moonshot configuration file for custom provider
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/moonshot.provider.yml

# Test with Novita configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/novita.provider.yml

# Test with xAI configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/xai.provider.yml

# Test with OpenAI configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type openai

# Test with Anthropic configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type anthropic

# Test with Gemini configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type gemini

# Test with AWS Bedrock configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -type bedrock

# Test with Custom OpenAI configuration
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/custom-openai.provider.yml

# Test with Azure OpenAI configuration (needs LLM_SERVER_API_TYPE=azure, see Using Azure OpenAI)
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/azure-openai.provider.yml

# Test with Ollama configuration (local inference)
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/ollama-llama318b.provider.yml

# Test with Ollama Qwen3 32B configuration (requires custom model creation)
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/ollama-qwen332b-fp16-tc.provider.yml

# Test with Ollama QwQ 32B configuration (requires custom model creation and 71.3GB VRAM)
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/ollama-qwq32b-fp16-tc.provider.yml

To use these configurations, your .env file only needs to contain:

LLM_SERVER_URL=https://openrouter.ai/api/v1      # or https://api.deepinfra.com/v1/openai or https://api.openai.com/v1 or https://opencode.ai/zen/go/v1 or https://api.novita.ai/openai or https://api.atlascloud.ai/v1 or https://api.orcarouter.ai/v1 or https://api.x.ai/v1
LLM_SERVER_KEY=your_api_key
LLM_SERVER_MODEL=                                # Leave empty, as models are specified in the config
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/openrouter.provider.yml  # or deepinfra.provider.ymll or opencode.provider.ymll or custom-openai.provider.yml or novita.provider.yml or atlas.provider.yml or orcarouter.provider.yml or xai.provider.yml
LLM_SERVER_PROVIDER=                             # Provider name for LiteLLM proxy (e.g., openrouter, deepseek, moonshot, novita, opencode, orcarouter, xai)
LLM_SERVER_PRESERVE_REASONING=false              # Preserve reasoning content in multi-turn conversations (required by Moonshot, default: false)

# For OpenAI (official API)
OPEN_AI_KEY=your_openai_api_key                  # Your OpenAI API key
OPEN_AI_SERVER_URL=https://api.openai.com/v1     # OpenAI API endpoint

# For Anthropic (Claude models)
ANTHROPIC_API_KEY=your_anthropic_api_key         # Your Anthropic API key
ANTHROPIC_SERVER_URL=https://api.anthropic.com/v1  # Anthropic API endpoint

# For Gemini (Google AI)
GEMINI_API_KEY=your_gemini_api_key               # Your Google AI API key
GEMINI_SERVER_URL=https://generativelanguage.googleapis.com  # Google AI API endpoint

# For AWS Bedrock (enterprise foundation models)
BEDROCK_REGION=us-east-1                         # AWS region for Bedrock service
# Authentication (choose one method, priority: DefaultAuth > BearerToken > AccessKey):
BEDROCK_DEFAULT_AUTH=false                       # Use AWS SDK credential chain (env vars, EC2 role, ~/.aws/credentials)
BEDROCK_BEARER_TOKEN=                            # Bearer token authentication (takes priority over static credentials)
BEDROCK_ACCESS_KEY_ID=your_aws_access_key        # AWS access key ID (static credentials)
BEDROCK_SECRET_ACCESS_KEY=your_aws_secret_key    # AWS secret access key (static credentials)
BEDROCK_SESSION_TOKEN=                           # AWS session token (optional, for temporary credentials with static auth)
BEDROCK_SERVER_URL=                              # Optional custom Bedrock endpoint (VPC endpoints, local testing)
BEDROCK_CONFIG_PATH=                             # Optional path to a custom YAML provider config (overrides built-in model/pricing definitions)

# For Ollama (local server or cloud)
OLLAMA_SERVER_URL=                               # Local: http://ollama-server:11434, Cloud: https://ollama.com
OLLAMA_SERVER_API_KEY=                           # Required for Ollama Cloud (https://ollama.com/settings/keys), leave empty for local
OLLAMA_SERVER_MODEL=
OLLAMA_SERVER_CONFIG_PATH=
OLLAMA_SERVER_PULL_MODELS_TIMEOUT=
OLLAMA_SERVER_PULL_MODELS_ENABLED=
OLLAMA_SERVER_LOAD_MODELS_ENABLED=

# For DeepSeek (Chinese AI with strong reasoning)
DEEPSEEK_API_KEY=                                # DeepSeek API key
DEEPSEEK_SERVER_URL=https://api.deepseek.com     # DeepSeek API endpoint
DEEPSEEK_PROVIDER=                               # Optional: LiteLLM prefix (e.g., 'deepseek')

# For GLM (Zhipu AI)
GLM_API_KEY=                                     # GLM API key
GLM_SERVER_URL=https://api.z.ai/api/paas/v4      # GLM API endpoint (international)
GLM_PROVIDER=                                    # Optional: LiteLLM prefix (e.g., 'zai')

# For Kimi (Moonshot AI)
KIMI_API_KEY=                                    # Kimi API key
KIMI_SERVER_URL=https://api.moonshot.ai/v1       # Kimi API endpoint (international)
KIMI_PROVIDER=                                   # Optional: LiteLLM prefix (e.g., 'moonshot')

# For Qwen Cloud or Alibaba Cloud Model Studio
QWEN_API_KEY=                                    # Direct provider or gateway API key
QWEN_SERVER_URL=https://dashscope-us.aliyuncs.com/compatible-mode/v1  # Direct DashScope or gateway URL
QWEN_PROVIDER=                                   # Gateway prefix: 'qwen_cloud' or 'dashscope'; empty for direct DashScope

# For Ollama (local inference) use variables above
OLLAMA_SERVER_URL=http://localhost:11434
OLLAMA_SERVER_MODEL=llama3.1:8b-instruct-q8_0
OLLAMA_SERVER_CONFIG_PATH=/opt/pentagi/conf/ollama-llama318b.provider.yml
OLLAMA_SERVER_PULL_MODELS_ENABLED=false
OLLAMA_SERVER_LOAD_MODELS_ENABLED=false

Using OpenAI with Unverified Organizations

For OpenAI accounts with unverified organizations that don't have access to the latest reasoning models (o1, o3, o4-mini), you need to use a custom configuration.

To use OpenAI with unverified organization accounts, configure your .env file as follows:

LLM_SERVER_URL=https://api.openai.com/v1
LLM_SERVER_KEY=your_openai_api_key
LLM_SERVER_MODEL=                                # Leave empty, models are specified in config
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/custom-openai.provider.yml

This configuration uses the pre-built custom-openai.provider.yml file that maps all agent types to models available for unverified organizations, using o3-mini instead of models like o1, o3, and o4-mini.

You can test this configuration using:

# Test with custom OpenAI configuration for unverified accounts
docker exec -it pentagi /opt/pentagi/bin/ctester -config /opt/pentagi/conf/custom-openai.provider.yml

Using LiteLLM Proxy

When using LiteLLM proxy to access various LLM providers, model names are prefixed with the provider name (e.g., moonshot/kimi-2.5 instead of kimi-2.5). To use the same provider configuration files with both direct API access and LiteLLM proxy, set the LLM_SERVER_PROVIDER variable:

# Direct access to Moonshot API
LLM_SERVER_URL=https://api.moonshot.ai/v1
LLM_SERVER_KEY=your_moonshot_api_key
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/moonshot.provider.yml
LLM_SERVER_PROVIDER=                             # Empty for direct access

# Access via LiteLLM proxy
LLM_SERVER_URL=http://litellm-proxy:4000
LLM_SERVER_KEY=your_litellm_api_key
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/moonshot.provider.yml
LLM_SERVER_PROVIDER=moonshot                     # Provider prefix for LiteLLM

With LLM_SERVER_PROVIDER=moonshot, the system automatically prefixes all model names from the configuration file with moonshot/, making them compatible with LiteLLM's model naming convention.

LiteLLM Provider Name Mapping:

When using LiteLLM proxy, set the corresponding *_PROVIDER variable to enable model prefixing:

• deepseek - for DeepSeek models (DEEPSEEK_PROVIDER=deepseek → deepseek/deepseek-v4-flash)
• zai - for GLM models (GLM_PROVIDER=zai → zai/glm-4)
• moonshot - for Kimi models (KIMI_PROVIDER=moonshot → moonshot/kimi-k3)
• dashscope - for Qwen models (QWEN_PROVIDER=dashscope → dashscope/qwen-plus)
• openai, anthropic, gemini - for major cloud providers
• opencode - for OpenCode Go plan
• openrouter - for OpenRouter aggregator
• orcarouter - for OrcaRouter aggregator
• deepinfra - for DeepInfra hosting
• novita - for Novita AI
• xai - for xAI (grok-* models)
• Any other provider name configured in your LiteLLM instance

Example with LiteLLM:

# Use DeepSeek models via LiteLLM proxy with model prefixing
DEEPSEEK_API_KEY=your_litellm_proxy_key
DEEPSEEK_SERVER_URL=http://litellm-proxy:4000
DEEPSEEK_PROVIDER=deepseek  # Models become deepseek/deepseek-v4-flash, deepseek/deepseek-v4-pro for LiteLLM

# Direct DeepSeek API usage (no prefix needed)
DEEPSEEK_API_KEY=your_deepseek_api_key
DEEPSEEK_SERVER_URL=https://api.deepseek.com
# Leave DEEPSEEK_PROVIDER empty

This approach allows you to:

• Use the same configuration files for both direct and proxied access
• Switch between providers without modifying configuration files
• Easily test different routing strategies with LiteLLM

Running Tests in a Production Environment

If you already have a running PentAGI container and want to test the current configuration:

# Run ctester in an existing container using current environment variables
docker exec -it pentagi /opt/pentagi/bin/ctester -verbose

# Test specific agent types with deterministic ordering
docker exec -it pentagi /opt/pentagi/bin/ctester -agents simple,primary_agent,pentester -groups basic,knowledge -verbose

# Generate a report file inside the container
docker exec -it pentagi /opt/pentagi/bin/ctester -report /opt/pentagi/data/agent-test-report.md

# Access the report from the host
docker cp pentagi:/opt/pentagi/data/agent-test-report.md ./

Command-line Options

The utility accepts several options:

• -env <path> - Path to environment file (default: .env)
• -type <provider> - Provider type: custom, openai, anthropic, ollama, bedrock, gemini (default: custom)
• -config <path> - Path to custom provider config (default: from LLM_SERVER_CONFIG_PATH env variable)
• -tests <path> - Path to custom tests YAML file (optional)
• -report <path> - Path to write the report file (optional)
• -agents <list> - Comma-separated list of agent types to test (default: all)
• -groups <list> - Comma-separated list of test groups to run (default: all)
• -verbose - Enable verbose output with detailed test results for each agent

Available Agent Types

Agents are tested in the following deterministic order:

1. simple - Basic completion tasks
2. simple_json - JSON-structured responses
3. primary_agent - Main reasoning agent
4. assistant - Interactive assistant mode
5. generator - Content generation
6. refiner - Content refinement and improvement
7. adviser - Expert advice and consultation
8. reflector - Self-reflection and analysis
9. searcher - Information gathering and search
10. enricher - Data enrichment and expansion
11. coder - Code generation and analysis
12. installer - Installation and setup tasks
13. pentester - Penetration testing and security assessment

Available Test Groups

• basic - Fundamental completion and prompt response tests
• advanced - Complex reasoning and function calling tests
• json - JSON format validation and structure tests (specifically designed for simple_json agent)
• knowledge - Domain-specific cybersecurity and penetration testing knowledge tests

Note

: The json test group is specifically designed for the simple_json agent type, while all other agents are tested with basic, advanced, and knowledge groups. This specialization ensures optimal testing coverage for each agent's intended purpose.

Example Provider Configuration

Provider configuration defines which models to use for different agent types:

simple:
  model: "provider/model-name"
  temperature: 0.7
  top_p: 0.95
  n: 1
  max_tokens: 4000

simple_json:
  model: "provider/model-name"
  temperature: 0.7
  top_p: 1.0
  n: 1
  max_tokens: 4000
  json: true

# ... other agent types ...

Optimization Workflow

1. Create a baseline: Run tests with default configuration to establish benchmark performance
2. Analyze agent-specific performance: Review the deterministic agent ordering to identify underperforming agents
3. Test specialized configurations: Experiment with different models for each agent type using provider-specific configs
4. Focus on domain knowledge: Pay special attention to knowledge group tests for cybersecurity expertise
5. Validate function calling: Ensure tool-based tests pass consistently for critical agent types
6. Compare results: Look for the best success rate and performance across all test groups
7. Deploy optimal configuration: Use in production with your optimized setup

This tool helps ensure your AI agents are using the most effective models for their specific tasks, improving reliability while optimizing costs.

Embedding Configuration and Testing

PentAGI uses vector embeddings for semantic search, knowledge storage, and memory management. The system supports multiple embedding providers that can be configured according to your needs and preferences.

Supported Embedding Providers

PentAGI supports the following embedding providers:

• OpenAI (default): Uses OpenAI's text embedding models
• Ollama: Local embedding model through Ollama
• Mistral: Mistral AI's embedding models
• Jina: Jina AI's embedding service
• HuggingFace: Models from HuggingFace
• GoogleAI: Google's embedding models
• VoyageAI: VoyageAI's embedding models

OpenAI-compatible third parties: any provider exposing OpenAI's /embeddings API can be plugged in via EMBEDDING_PROVIDER=openai with a custom EMBEDDING_URL. For example, Qwen DashScope offers text-embedding-v4 through the /compatible-mode/v1 endpoint (International and Chinese Mainland regions only — the US region does not expose embeddings). See the Qwen Alternative Integrations subsection for the full configuration snippet.

Embedding Provider Configuration (click to expand)

Environment Variables

To configure the embedding provider, set the following environment variables in your .env file:

# Primary embedding configuration
EMBEDDING_PROVIDER=openai       # Provider type (openai, ollama, mistral, jina, huggingface, googleai, voyageai)
EMBEDDING_MODEL=text-embedding-3-small  # Model name to use
EMBEDDING_URL=                  # Optional custom API endpoint
EMBEDDING_KEY=                  # API key for the provider (if required)
EMBEDDING_BATCH_SIZE=100        # Number of documents to process in a batch
EMBEDDING_STRIP_NEW_LINES=true  # Whether to remove new lines from text before embedding
EMBEDDING_MAX_TEXT_BYTES=8192   # Max bytes of text sent to embedding model per document (byte proxy for token limit)

# Advanced settings
PROXY_URL=                      # Optional proxy for all API calls
HTTP_CLIENT_TIMEOUT=600         # Timeout in seconds for external API calls (default: 600, 0 = no timeout)
TERMINAL_TOOL_TIMEOUT=1200      # Default timeout in seconds for terminal tool commands when timeout=0 or negative (range: 1–10800; values <= 0 or above 10800 are clamped to 10800 = 3 hours)

# SSL/TLS Certificate Configuration (for external communication with LLM backends and tool servers)
EXTERNAL_SSL_CA_PATH=           # Path to custom CA certificate file (PEM format) inside the container
                                # Must point to /opt/pentagi/ssl/ directory (e.g., /opt/pentagi/ssl/ca-bundle.pem)
EXTERNAL_SSL_INSECURE=false     # Skip certificate verification (use only for testing)

How to Add Custom CA Certificates (click to expand)

If you see this error: tls: failed to verify certificate: x509: certificate signed by unknown authority

Step 1: Get your CA certificate bundle in PEM format (can contain multiple certificates)

Step 2: Place the file in the SSL directory on your host machine:

# Default location (if PENTAGI_SSL_DIR is not set)
cp ca-bundle.pem ./pentagi-ssl/

# Or custom location (if using PENTAGI_SSL_DIR in docker-compose.yml)
cp ca-bundle.pem /path/to/your/ssl/dir/

Step 3: Set the path in .env file (path must be inside the container):

# The volume pentagi-ssl is mounted to /opt/pentagi/ssl inside the container
EXTERNAL_SSL_CA_PATH=/opt/pentagi/ssl/ca-bundle.pem
EXTERNAL_SSL_INSECURE=false

Step 4: Restart PentAGI:

docker compose restart pentagi

Notes:

• The pentagi-ssl volume is mounted to /opt/pentagi/ssl inside the container
• You can change host directory using PENTAGI_SSL_DIR variable in docker-compose.yml
• File supports multiple certificates and intermediate CAs in one PEM file
• Use EXTERNAL_SSL_INSECURE=true only for testing (not recommended for production)

Provider-Specific Limitations

Each provider has specific limitations and supported features:

• OpenAI: Supports all configuration options
• Ollama: Does not support EMBEDDING_KEY as it uses local models
• Mistral: Supports all configuration options
• Jina: Supports all configuration options
• HuggingFace: Requires EMBEDDING_KEY and supports all other options
• GoogleAI: Does not support EMBEDDING_URL, requires EMBEDDING_KEY
• VoyageAI: Supports all configuration options

If EMBEDDING_URL and EMBEDDING_KEY are both left empty, the system uses the corresponding LLM provider's server and key together (e.g., OPEN_AI_SERVER_URL and OPEN_AI_KEY when EMBEDDING_PROVIDER=openai). A key set in EMBEDDING_KEY without EMBEDDING_URL goes to the provider's public endpoint, and an EMBEDDING_URL set without a key receives the LLM provider's key only when it is that provider's own server. So an OpenAI-compatible endpoint of another vendor needs its key in EMBEDDING_KEY, and a keyless local server (LocalAI, vLLM, TEI) takes any non-empty value there. Whenever the Mistral embedder uses MISTRAL_SERVER_URL, it also names the model the way that server expects: MISTRAL_PROVIDER=mistral turns mistral-embed into mistral/mistral-embed, and a model that already starts with mistral/ is sent as is.

Why Consistent Embedding Providers Matter

It's crucial to use the same embedding provider consistently because:

1. Vector Compatibility: Different providers produce vectors with different dimensions and mathematical properties
2. Semantic Consistency: Changing providers can break semantic similarity between previously embedded documents
3. Memory Corruption: Mixed embeddings can lead to poor search results and broken knowledge base functionality

If you change your embedding provider, you should flush and reindex your entire knowledge base (see etester utility below).

Embedding Tester Utility (etester)

PentAGI includes a specialized etester utility for testing, managing, and debugging embedding functionality. This tool is essential for diagnosing and resolving issues related to vector embeddings and knowledge storage.

Etester Commands (click to expand)

# Test embedding provider and database connection
cd backend
go run cmd/etester/main.go test -verbose

# Show statistics about the embedding database
go run cmd/etester/main.go info

# Delete all documents from the embedding database (use with caution!)
go run cmd/etester/main.go flush

# Recalculate embeddings for all documents (after changing provider)
go run cmd/etester/main.go reindex

# Search for documents in the embedding database
go run cmd/etester/main.go search -query "How to install PostgreSQL" -limit 5

Using Docker

If you're running PentAGI in Docker, you can use etester from within the container:

# Test embedding provider
docker exec -it pentagi /opt/pentagi/bin/etester test

# Show detailed database information
docker exec -it pentagi /opt/pentagi/bin/etester info -verbose

Advanced Search Options

The search command supports various filters to narrow down results:

# Filter by document type
docker exec -it pentagi /opt/pentagi/bin/etester search -query "Security vulnerability" -doc_type guide -threshold 0.8

# Filter by flow ID
docker exec -it pentagi /opt/pentagi/bin/etester search -query "Code examples" -doc_type code -flow_id 42

# All available search options
docker exec -it pentagi /opt/pentagi/bin/etester search -help

Available search parameters:

• -query STRING: Search query text (required)
• -doc_type STRING: Filter by document type (answer, memory, guide, code)
• -flow_id NUMBER: Filter by flow ID (positive number)
• -answer_type STRING: Filter by answer type (guide, vulnerability, code, tool, other)
• -guide_type STRING: Filter by guide type (install, configure, use, pentest, development, other)
• -limit NUMBER: Maximum number of results (default: 3)
• -threshold NUMBER: Similarity threshold (0.0-1.0, default: 0.7)

Memory Lifecycle Across Flows

PentAGI stores several kinds of vector documents, and they serve different purposes:

• memory captures flow-specific execution history such as tool results and agent observations
• guide, answer, and code are intended for reusable knowledge that can help future runs

If you want to inspect what happened in one engagement, search the vector store with the related flow_id. If you want knowledge to survive beyond a single run, store the durable result explicitly as a guide, answer, or code document instead of relying on execution memory alone.

For example, if a target has recurring setup notes, authentication quirks, or target-specific testing methodology, instruct the agent to save that information as a guide and search for it at the beginning of the next engagement. This is the safest current workflow when you want a new flow to start with reusable context.

Flow deletion removes the flow from normal queries through PentAGI's soft-delete mechanism, so reusable knowledge should be treated as a separate concern from per-flow execution history. If you enable the optional Graphiti knowledge graph described earlier in this README, treat its current search context as scoped to the active flow or engagement unless you explicitly build a separate cross-flow reuse workflow.

Common Troubleshooting Scenarios

1. After changing embedding provider: Always run flush or reindex to ensure consistency
2. Poor search results: Try adjusting the similarity threshold or check if embeddings are correctly generated
3. Database connection issues: Verify PostgreSQL is running with pgvector extension installed
4. Missing API keys: Check environment variables for your chosen embedding provider

Troubleshooting: Flow Stalls or Hangs Without Progress

If a flow starts but then appears to wait indefinitely with no subtasks progressing, a common cause is an embedding provider that is misconfigured or unreachable. PentAGI uses the embedding provider to store and search vector memory while a flow runs, so embedding calls that fail or hang can leave a flow waiting instead of advancing.

1. Check the container logs first. Embedding errors surface in the PentAGI logs:

docker logs pentagi

Look for embedding-related failures such as authentication errors (401/403), wrong-model or not-found errors (404), connection timeouts, or TLS certificate errors. These point at the embedding provider configuration rather than at the flow itself.

2. Validate the provider with etester. The Embedding Tester Utility (etester) checks both the embedding provider and the database connection without starting a flow:

docker exec -it pentagi /opt/pentagi/bin/etester test -verbose

A failing test confirms the problem is in the embedding configuration rather than in the flow.

3. Verify the configuration. Check the following in your .env file against the Supported Embedding Providers list and each provider's documented limitations:

• EMBEDDING_PROVIDER is one of the supported providers (default openai).
• EMBEDDING_MODEL is a valid model name for that provider.
• EMBEDDING_URL and EMBEDDING_KEY are correct for the provider. If both are left empty, PentAGI falls back to the matching LLM provider settings (for example OPEN_AI_KEY and OPEN_AI_SERVER_URL when EMBEDDING_PROVIDER=openai), so a missing or wrong key there can break embeddings too.
• The endpoint is reachable from inside the container. If outbound calls go through a proxy, confirm PROXY_URL is set; if calls hang rather than fail quickly, HTTP_CLIENT_TIMEOUT controls how long PentAGI waits on the provider before giving up.

Changing provider? If you switch embedding providers after data has already been indexed, run flush or reindex with etester so old and new vectors are not mixed. See Why Consistent Embedding Providers Matter above.

Function Testing with ftester

PentAGI includes a versatile utility called ftester for debugging, testing, and developing specific functions and AI agent behaviors. While ctester focuses on testing LLM model capabilities, ftester allows you to directly invoke individual system functions and AI agent components with precise control over execution context.

Key Features

• Direct Function Access: Test individual functions without running the entire system
• Mock Mode: Test functions without a live PentAGI deployment using built-in mocks
• Interactive Input: Fill function arguments interactively for exploratory testing
• Detailed Output: Color-coded terminal output with formatted responses and errors
• Context-Aware Testing: Debug AI agents within the context of specific flows, tasks, and subtasks
• Observability Integration: All function calls are logged to Langfuse and Observability stack

Usage Modes

Command Line Arguments

Run ftester with specific function and arguments directly from the command line:

# Basic usage with mock mode
cd backend
go run cmd/ftester/main.go [function_name] -[arg1] [value1] -[arg2] [value2]

# Example: Test terminal command in mock mode
go run cmd/ftester/main.go terminal -command "ls -la" -message "List files"

# Using a real flow context
go run cmd/ftester/main.go -flow 123 terminal -command "whoami" -message "Check user"

# Testing AI agent in specific task/subtask context
go run cmd/ftester/main.go -flow 123 -task 456 -subtask 789 pentester -message "Find vulnerabilities"

Interactive Mode

Run ftester without arguments for a guided interactive experience:

# Start interactive mode
go run cmd/ftester/main.go [function_name]

# For example, to interactively fill browser tool arguments
go run cmd/ftester/main.go browser

Available Functions (click to expand)

Environment Functions

• terminal: Execute commands in a container and return the output
• file: Perform file operations (read, write, list) in a container

Search Functions

• browser: Access websites and capture screenshots
• web_search: Unified search orchestrator that agents actually call — pass a query and a mode (links, answer, research, exploit) and it auto-selects, retries, and falls back across the engines below, so you never name an engine explicitly
• google: Search the web using Google Custom Search
• duckduckgo: Search the web using DuckDuckGo
• tavily: Search using Tavily AI search engine
• firecrawl: Search using Firecrawl with main-content markdown scraping
• traversaal: Search using Traversaal AI search engine
• perplexity: Search using Perplexity AI
• sploitus: Search for security exploits, vulnerabilities (CVEs), and pentesting tools
• searxng: Search using Searxng meta search engine (aggregates results from multiple engines)
• internal (ftester-only debug function, not an agent tool): Opt-in browser-analytics fallback engine that discovers links, scrapes each page, and summarizes the result; requires WEB_SEARCH_INTERNAL_ENABLED=true, a configured scraper, and at least one available link engine

Vector Database Functions

• search_in_memory: Search for information in vector database
• search_guide: Find guidance documents in vector database
• search_answer: Find answers to questions in vector database
• search_code: Find code examples in vector database

AI Agent Functions

• advice: Get expert advice from an AI agent
• coder: Request code generation or modification
• maintenance: Run system maintenance tasks
• memorist: Store and organize information in vector database
• pentester: Perform security tests and vulnerability analysis
• search: Complex search across multiple sources

Utility Functions

• describe: Show information about flows, tasks, and subtasks

Debugging Flow Context (click to expand)

The describe function provides detailed information about tasks and subtasks within a flow. This is particularly useful for diagnosing issues when PentAGI encounters problems or gets stuck.

# List all flows in the system
go run cmd/ftester/main.go describe

# Show all tasks and subtasks for a specific flow
go run cmd/ftester/main.go -flow 123 describe

# Show detailed information for a specific task
go run cmd/ftester/main.go -flow 123 -task 456 describe

# Show detailed information for a specific subtask
go run cmd/ftester/main.go -flow 123 -task 456 -subtask 789 describe

# Show verbose output with full descriptions and results
go run cmd/ftester/main.go -flow 123 describe -verbose

This function allows you to identify the exact point where a flow might be stuck and resume processing by directly invoking the appropriate agent function.

Function Help and Discovery (click to expand)

Each function has a help mode that shows available parameters:

# Get help for a specific function
go run cmd/ftester/main.go [function_name] -help

# Examples:
go run cmd/ftester/main.go terminal -help
go run cmd/ftester/main.go browser -help
go run cmd/ftester/main.go describe -help

You can also run ftester without arguments to see a list of all available functions:

go run cmd/ftester/main.go

Output Format (click to expand)

The ftester utility uses color-coded output to make interpretation easier:

• Blue headers: Section titles and key names
• Cyan [INFO]: General information messages
• Green [SUCCESS]: Successful operations
• Red [ERROR]: Error messages
• Yellow [WARNING]: Warning messages
• Yellow [MOCK]: Indicates mock mode operation
• Magenta values: Function arguments and results

JSON and Markdown responses are automatically formatted for readability.

Advanced Usage Scenarios (click to expand)

Debugging Stuck AI Flows

When PentAGI gets stuck in a flow:

1. Pause the flow through the UI
2. Use describe to identify the current task and subtask
3. Directly invoke the agent function with the same task/subtask IDs
4. Examine the detailed output to identify the issue
5. Resume the flow or manually intervene as needed

Testing Environment Variables

Verify that API keys and external services are configured correctly:

# Test Google search API configuration
go run cmd/ftester/main.go google -query "pentesting tools"

# Test browser access to external websites
go run cmd/ftester/main.go browser -url "https://example.com"

Developing New AI Agent Behaviors

When developing new prompt templates or agent behaviors:

1. Create a test flow in the UI
2. Use ftester to directly invoke the agent with different prompts
3. Observe responses and adjust prompts accordingly
4. Check Langfuse for detailed traces of all function calls

Verifying Docker Container Setup

Ensure containers are properly configured:

go run cmd/ftester/main.go -flow 123 terminal -command "env | grep -i proxy" -message "Check proxy settings"

Docker Container Usage (click to expand)

If you have PentAGI running in Docker, you can use ftester from within the container:

# Run ftester inside the running PentAGI container
docker exec -it pentagi /opt/pentagi/bin/ftester [arguments]

# Examples:
docker exec -it pentagi /opt/pentagi/bin/ftester -flow 123 describe
docker exec -it pentagi /opt/pentagi/bin/ftester -flow 123 terminal -command "ps aux" -message "List processes"

This is particularly useful for production deployments where you don't have a local development environment.

Integration with Observability Tools (click to expand)

All function calls made through ftester are logged to:

1. Langfuse: Captures the entire AI agent interaction chain, including prompts, responses, and function calls
2. OpenTelemetry: Records metrics, traces, and logs for system performance analysis
3. Terminal Output: Provides immediate feedback on function execution

To access detailed logs:

• Check Langfuse UI for AI agent traces (typically at http://localhost:4000)
• Use Grafana dashboards for system metrics (typically at http://localhost:3000)
• Examine terminal output for immediate function results and errors

Command-line Options

The main utility accepts several options:

• -env <path> - Path to environment file (optional, default: .env)
• -provider <type> - Provider type to use (default: custom, options: openai, anthropic, gemini, bedrock, ollama, deepseek, glm, kimi, qwen, minimax, custom)
• -flow <id> - Flow ID for testing functions that require it (0 means using mocks, default: 0)
• -user <id> - User ID for testing functions that require it (default: 0; 1 is the default admin user)
• -task <id> - Task ID for agent context (optional)
• -subtask <id> - Subtask ID for agent context (optional)

Function-specific arguments are passed after the function name using -name value format.

Pentesting Prompt Methodology

When refining prompts for offensive security work, give the agent a clear methodology instead of a flat list of payloads:

1. Start with explicit scope, authorization, and success criteria
2. Map the application first: roles, routes, parameters, uploads, integrations, and trust boundaries
3. Prioritize attack surfaces systematically instead of testing everything at once
4. Validate findings with reproducible evidence before escalating to deeper exploitation
5. Finish with report-ready notes that capture impact, prerequisites, and next steps

For PentAGI-specific prompt guidance, see backend/docs/prompt_engineering_pentagi.md. For a practical starting point, reuse and adapt examples/prompts/base_web_pentest.md to match the target application, technology stack, and engagement scope.

Building

Building Docker Image

The Docker build process automatically embeds version information from git tags. To properly version your build, use the provided scripts:

Linux/macOS

# Load version variables
source ./scripts/version.sh

# Standard build
docker build \
  --build-arg PACKAGE_VER=$PACKAGE_VER \
  --build-arg PACKAGE_REV=$PACKAGE_REV \
  -t pentagi:$PACKAGE_VERSION_FULL .

# Multi-platform build
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --build-arg PACKAGE_VER=$PACKAGE_VER \
  --build-arg PACKAGE_REV=$PACKAGE_REV \
  -t pentagi:$PACKAGE_VERSION_FULL .

# Build and push
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --build-arg PACKAGE_VER=$PACKAGE_VER \
  --build-arg PACKAGE_REV=$PACKAGE_REV \
  -t myregistry/pentagi:$PACKAGE_VERSION_FULL \
  --push .

Windows (PowerShell)

# Load version variables
. .\scripts\version.ps1

# Standard build
docker build `
  --build-arg PACKAGE_VER=$env:PACKAGE_VER `
  --build-arg PACKAGE_REV=$env:PACKAGE_REV `
  -t pentagi:$env:PACKAGE_VERSION_FULL .

# Multi-platform build
docker buildx build `
  --platform linux/amd64,linux/arm64 `
  --build-arg PACKAGE_VER=$env:PACKAGE_VER `
  --build-arg PACKAGE_REV=$env:PACKAGE_REV `
  -t pentagi:$env:PACKAGE_VERSION_FULL .

Quick build without version

For development builds without version tracking:

docker build -t pentagi:dev .

Note

• The build scripts automatically determine version from git tags
• Release builds (on tag commit) have no revision suffix
• Development builds (after tag) include commit hash as revision (e.g., 1.1.0-ce.hbc6e800); the edition is ce for Community and ee for Enterprise, and a release build is 1.1.0-ce
• To use the built image locally, update the image name in docker-compose.yml or use the build option

Credits

This project is made possible thanks to the following research and developments:

• Emerging Architectures for LLM Applications
• A Survey of Autonomous LLM Agents
• Codel by Andriy Semenets - initial architectural inspiration for agent-based automation

License

PentAGI is licensed under the MIT License.

Copyright (c) 2025 PentAGI Development Team

Third-Party Dependencies

All third-party dependencies use MIT-compatible licenses. See licenses/ directory for detailed license reports.

VXControl Cloud Services

⚠️ Note: While the VXControl Cloud SDK code is MIT licensed, accessing VXControl Cloud Services (threat intelligence, AI support, premium features) requires a separate License Key and compliance with Terms of Service.

The SDK code itself is free to use - service access requires registration.

For questions contact: info@pentagi.com or info@vxcontrol.com