The added Claude/Bedrock rows put "✅ adaptive-only" in the narrow Thinking
column, which broke the source pipe alignment of the carefully-padded tables.
Use a plain ✅ in the Thinking column (the adaptive-only detail already lives in
the Use Case text and the Adaptive Thinking note) and re-pad the rows so the
columns line up again.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Code review found the providers were fully wired in code but missing from
several user-facing surfaces:
- MiniMax (#328): add to .env.example, docker-compose env passthrough,
backend/docs/config.md env table, README provider list + a MiniMax
configuration section, and backend/docs/database.md PROVIDER_TYPE enum.
- Claude Opus 4.7/4.8 (#288): add to the README Claude and Bedrock model
catalogs and correct the model counts (10→11 Claude, 21→24 Bedrock); note
4.7/4.8 are adaptive-thinking-only in the Adaptive Thinking section.
- llms_how_to.md: scope the "Temperature=1.0" rule to budget thinking and add
an adaptive-thinking caveat (4.7/4.8 reject sampling params), so the guide no
longer contradicts the shipped adaptive code path.
- docker-compose: point the Bedrock config/models default mount at the tracked
examples/configs/bedrock-glm-flash.* files (the README-documented path) so a
plain `docker compose up` no longer creates empty placeholder directories.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reworks PR #233 to follow the existing config-path pattern and make an
externally-added Bedrock model fully usable from the web UI.
- BEDROCK_CONFIG_PATH: replace the embedded per-agent config (model
assignments + prices), mirroring OLLAMA_SERVER_CONFIG_PATH /
LLM_SERVER_CONFIG_PATH. DefaultProviderConfig now takes *config.Config
and reads the external file when set, else the embedded config.yml.
- BEDROCK_MODELS_PATH: merge an external model catalog onto the embedded
models.yml so new ids appear and are selectable under Settings ->
Providers. DefaultModels now takes *config.Config and the resolver +
provider construction pass it through; new ids are added, a matching
name overrides the embedded entry.
Wires both through docker-compose, .env.example, config.md and the README,
and ships examples/configs/bedrock-glm-flash.{provider,models}.yml using the
real AWS Bedrock id zai.glm-4.7-flash (In-Region, no inference-profile
prefix, 4K max output).
Dropped from #233: the ProviderConfig.Name field and the SeedDefaultProviders
mechanism (a per-user DB write fired on startup and inside the read-only
SettingsProviders resolver) -- the config already reaches the UI through
DefaultProvidersConfig without any DB rows.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reworks PR #332 to follow the repo's provider-doc convention instead of
its README-marketing form:
- add examples/configs/atlas.provider.yml, modeled on the existing
aggregator example configs (deepinfra/openrouter/novita)
- list Atlas Cloud in the README aggregators line
- LLM_SERVER_PROVIDER left EMPTY for direct access — it is a LiteLLM
model-name prefix, and #332 incorrectly recommended `openai`, which
would break /models discovery for Atlas's vendor-prefixed model ids
Dropped from #332 (not matching any existing aggregator's docs): vendor
logo/banner, UTM-tracked links, and the static 59-model table.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Use the package-path form for the tester utilities
(go run ./cmd/ctester, go run ./cmd/etester test) instead of shell
glob / single-file invocations, which are more portable and avoid the
multi-file compile pitfall.
- Add -verbose to the container etester example so it matches the local
example.
- Wrap the new README Quick Start pointer across multiple lines; rendered
Markdown is unchanged.
Issue #61 asked for a proper guide on how to start using PentAGI. A
first-use guide (How to Use PentAGI After Login) already covers what to
do after login, but the maintainer kept the issue open until an article
about installing and configuring the product is published.
Add examples/guides/installation_configuration.md, a concise ordered
walkthrough that connects the existing detailed README sections into a
single path: choose installer vs manual Docker Compose, set core server
variables (PUBLIC_URL, CORS_ORIGINS, security vars), configure and test
an LLM provider with ctester, configure and test the embedding provider
with etester, optionally add search providers and the Graphiti/Langfuse/
observability stacks, then start and verify the stack and change the
default admin password. It ends with a quick checklist and links forward
to the existing post-login usage guide.
The guide links to the relevant README reference sections rather than
duplicating them. A single pointer link is added at the top of the
README Quick Start section for discoverability.
Docs only. No installer behavior, runtime code, env vars, or schema
changes. Every environment variable named in the guide already exists in
.env.example and backend/pkg/config/config.go.
Add a troubleshooting subsection to the Embedding Configuration and
Testing section for the common case where a flow starts but then waits
indefinitely with no subtasks progressing. As noted on the issue, this
is frequently caused by a misconfigured or unreachable embedding
provider rather than by the flow itself.
The subsection points users to "docker logs pentagi" as the first
check, to the etester "test" command to validate the embedding provider
and database connection without starting a flow, and to the specific
.env settings to verify (EMBEDDING_PROVIDER, EMBEDDING_MODEL,
EMBEDDING_URL, EMBEDDING_KEY, the LLM-provider fallback, PROXY_URL, and
HTTP_CLIENT_TIMEOUT). Documentation only: no new environment variables,
no provider default changes, and no code or test changes.
Refs #322
Address review feedback on PR #325: capitalize SGLang to match the
project's name and clarify that tool calling and function calling
refer to the same capability.
Refs #309
Add a troubleshooting subsection to the Docker Image Configuration
section explaining that "failed to select primary docker image via llm
call" (older versions: "failed to get primary docker image") is raised
when PentAGI's first LLM call fails during image selection, not when
Docker or the registry is unhealthy. Points users to PentAGI and LLM
backend logs, provider URL/key/model verification, and tool-call parser
configuration for custom/OpenAI-compatible/vLLM/sglang backends.
The "failed to select primary docker image via llm call" symptom was
attributed to tool-call parser failures, but image selection is a plain
text completion (providers.go: prv.Call -> WrapGenerateFromSinglePrompt),
not a tool call. That error is a generic LLM-backend failure of the
`simple` agent type and is already covered in its own README section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Issue #313 reported flows that stall after a few steps when running a
custom OpenAI-compatible backend (LiteLLM in front of llama.cpp serving
qwen3.6-35b via LLM_SERVER_*). The backend returned malformed tool-call
arguments, surfaced as 'Failed to parse tool call arguments as JSON'
HTTP 500s and cascading retries. The maintainer fixed the stall in the
latest build by sanitizing wrong function-call arguments.
Add a troubleshooting subsection under Custom LLM Provider Configuration
that explains the root cause and how to diagnose it:
- Custom OpenAI-compatible backends must return valid tool-call
(function-call) JSON; llama.cpp, SGLang, and vLLM usually require a
specific tool-call parser and matching chat template, and not every
setup produces valid tool calls out of the box.
- Symptoms: 'Failed to parse tool call arguments as JSON', flow stalls,
looping tool calls, the 'failed to select primary docker image via
llm call' start-of-flow failure, and unexpected backend HTTP errors.
- Investigation: check PentAGI and backend/proxy logs, validate with the
ctester utility before a full flow, confirm the parser/chat template
match the model, and update PentAGI (recent builds sanitize malformed
function-call arguments).
Docs only. No tool-call parser code, provider runtime, schema, migration,
or config-default changes. Wording frames compatibility as dependent on
the backend's OpenAI-compatible tool-call behavior rather than claiming
every llama.cpp backend is supported.
commitlint had no config anywhere (no config file, no husky commit-msg
hook), so its rules were never loaded; the "commit" script also pointed
at an uninstalled binary. Remove @commitlint/cli and
@commitlint/config-conventional, the dead "commit"/"commitlint" scripts,
and the stale commitlint entry in README Development Requirements.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Issue #310 asks how to provide a Google Vertex AI API key in .env for
Anthropic Claude. PentAGI currently has no dedicated Vertex AI provider
path in code: backend/pkg/config and backend/cmd/installer do not read
VERTEX_API_KEY, GOOGLE_APPLICATION_CREDENTIALS, or any vertex_ai
variable. The supported routes for Claude today are direct Anthropic
(ANTHROPIC_API_KEY / ANTHROPIC_SERVER_URL) and AWS Bedrock (BEDROCK_*).
Document this explicitly so users do not assume a hidden Vertex AI
configuration path exists:
- README.md: add a NOTE callout inside the Anthropic Provider
Configuration section listing the supported routes and pointing
users who need Vertex AI today at the OpenAI-compatible custom LLM
provider path (LLM_SERVER_URL / LLM_SERVER_KEY / LLM_SERVER_MODEL)
fronted by a translating gateway, with a caveat that reliability
depends on the gateway.
- backend/docs/config.md: add a matching Note paragraph under the
Anthropic section that points at the AWS Bedrock and custom LLM
provider sections, and states that no VERTEX_API_KEY or
GOOGLE_APPLICATION_CREDENTIALS variable is wired into provider
initialization today.
Docs-only change. No runtime Go code, no installer behavior, no
generated files, no new environment variables. All env var names cited
in the new text already exist in the current PentAGI .env.example,
backend/pkg/config, and backend/cmd/installer.
- Update model descriptions to reflect V4 1M context window (up to 384K output)
instead of legacy 128K wording in models.yml and README.
- Split Flash and Pro pricing per official DeepSeek API docs:
- deepseek-v4-flash: input 0.14 / output 0.28 / cache_hit 0.0028 per 1M tokens
- deepseek-v4-pro: input 0.435 / output 0.87 / cache_hit 0.003625 per 1M tokens
- Apply per-role price split across all 13 role configs in both the embedded
config.yml and the user-facing examples/configs/deepseek.provider.yml.
- Replace stale "cache pricing is 10% of input cost" claim in the README,
which no longer holds for either V4 model.
- No change to LiteLLM prefix behavior, role-to-model mapping, lifecycle,
queues, GraphQL schema, migrations, frontend, or installer flow.
- README: align supported-models intro with the local convention used
by every other provider section ("Models marked with `*` are used
in default configuration"), so the asterisk on each model ID has a
near-by explanation.
- Installer help (`LLMFormDeepSeekHelp`): swap the legacy
"DeepSeek-Chat" / "DeepSeek-Reasoner" bullets in "Default PentAGI
Models" for the current `deepseek-v4-flash` / `deepseek-v4-pro`
defaults so the wizard guidance matches the bundled config.
No code, schema, or LiteLLM prefix behavior changes.
The DeepSeek provider config still defaulted to the legacy
`deepseek-chat` and `deepseek-reasoner` model names, which the
upstream DeepSeek API has announced for deprecation on 2026-07-24.
A first-run install therefore breaks once the legacy names are
removed.
Swap the defaults to the current DeepSeek V4 family:
- non-thinking roles use `deepseek-v4-flash`
- reasoning-heavy roles use `deepseek-v4-pro`
The change is limited to the embedded `config.yml` / `models.yml`
inside `backend/pkg/providers/deepseek`, the matching example at
`examples/configs/deepseek.provider.yml`, the `DeepSeekAgentModel`
fallback constant in `deepseek.go`, and three doc references
(README.md, backend/docs/config.md, backend/docs/llms_how_to.md)
plus one installer help string in
`backend/cmd/installer/wizard/locale/locale.go`. LiteLLM prefix
behavior is untouched.
- Introduced `EMBEDDING_MAX_TEXT_BYTES` to limit the maximum byte size of text sent to the embedding model.
- Renamed database connection pool settings: `DATABASE_MAX_OPEN_CONNS`, `DATABASE_MAX_IDLE_CONNS`, and `DATABASE_VECTOR_MAX_CONNS` for improved PostgreSQL connection management.
- Updated relevant documentation to reflect these new configuration options and their usage.
- Adjusted various components to utilize the new settings for enhanced performance and resource management.
- Introduced shared connection pooling for PostgreSQL using `*sql.DB` for sqlc and GORM, optimizing resource usage.
- Added new environment variables: `DB_MAX_OPEN_CONNS`, `DB_MAX_IDLE_CONNS`, and `DB_VECTOR_MAX_CONNS` for configurable connection limits.
- Updated documentation to reflect new connection pooling strategy and provide operational commands for monitoring.
- Implemented shared `pgxpool` for pgvector stores to reduce connection overhead and improve performance.
- Adjusted various components to utilize the new connection pooling setup, ensuring efficient database interactions.
Address Copilot review feedback on PR #305: the 'Current Limitations' bullet for the Graphiti integration mixed PentAGI's user-facing .env variables with the container env vars defined in docker-compose-graphiti.yml.
Reword both README.md and backend/docs/config.md to lead with the user-facing OPEN_AI_KEY and OPEN_AI_SERVER_URL .env variables and explicitly note that docker-compose-graphiti.yml maps them into the bundled vxcontrol/graphiti container as OPENAI_API_KEY and OPENAI_BASE_URL. Operators set the .env variables; the container variables are an implementation detail.
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Address Copilot review feedback on PR #304:
- Clarify the UserFiles template variable produces a <task_files> XML block with <uploads>/<resources> nested sections (matches flowfiles.FileListingForPrompt output).
- Distinguish that uploads/resources mirror to /work/uploads/ and /work/resources/, while container snapshots can originate from arbitrary container paths and are cached only under container/ on the flow side.
- Note that the 255 filename limit is enforced by len(name) <= 255, i.e. byte-length, so it is roughly 255 ASCII characters.
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
The Graphiti container shipped with docker-compose-graphiti.yml only
takes OPENAI_API_KEY and OPEN_AI_SERVER_URL for entity extraction.
PentAGI configures many other LLM providers (Anthropic, Google AI,
AWS Bedrock, DeepSeek, GLM, Kimi, Qwen) for the main flow, but those
credentials are not consumed by Graphiti today. Until that changes,
operators need to plan around an OpenAI-compatible endpoint just for
the knowledge graph.
This commit makes the limitation visible in two surfaces without
changing runtime behavior:
- README.md: Adds a beta callout at the top of the Knowledge Graph
Integration section and a new 'Current Limitations' subsection
covering provider scope, fixed model, independent billing, and the
lack of an in-app graph explorer.
- backend/docs/config.md: Mirrors the beta callout under Graphiti
Knowledge Graph Settings and adds a 'Current Limitations (Beta)'
subsection with the same constraints, so config-focused readers
see the same message.
Both notes explicitly point at the simple fallback: leave
GRAPHITI_ENABLED=false if the deployment cannot reach an
OpenAI-compatible endpoint.
Refs #187
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Add a How-to subsection that describes the Files tab on a flow page
without restating implementation details. The new section covers:
- The three file sources surfaced in the UI (uploads, resources,
container snapshots) with their exact action labels.
- The on-host layout under {dataDir}/flow-{id}-data/ and the
corresponding container paths /work/uploads and /work/resources.
- Per-file actions (Download, Copy path, Save as resource, Delete)
and the Pull action's disabled state when the container is not
running.
- Automatic injection of uploaded files and attached resources into
agent system prompts via the <UserFiles> block, so users understand
how the assistant sees their files.
- Current limits (300 MB / 1000 files / 2 GB / 255-char names) and
current limitations, including that flow deletion does not yet
archive or remove the flow data directory on disk.
This is a documentation-only change and does not introduce or change
runtime behavior.
Refs #193
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
