mirror of https://github.com/Significant-Gravitas/AutoGPT.git synced 2026-02-13 08:14:58 -05:00

Files

Swifty ab0b537cc7 refactor(backend): optimize find_block response size by removing raw JSON schemas (#12020 )

### Changes 🏗️

The `find_block` AutoPilot tool was returning ~90K characters per
response (10 blocks). The bloat came from including full JSON Schema
objects (`input_schema`, `output_schema`) with all nested `$defs`,
`anyOf`, and type definitions for every block.

**What changed:**

- **`BlockInfoSummary` model**: Removed `input_schema` (raw JSON
Schema), `output_schema` (raw JSON Schema), and `categories`. Added
`output_fields` (compact field-level summaries matching the existing
`required_inputs` format).
- **`BlockListResponse` model**: Removed `usage_hint` (info now in
`message`).
- **`FindBlockTool._execute()`**: Now extracts compact `output_fields`
from output schema properties instead of including the entire raw
schema. Credentials handling is unchanged.
- **Test**: Added `test_response_size_average_chars_per_block` with
realistic block schemas (HTTP, Email, Claude Code) to measure and assert
response size stays under 2K chars/block.
- **`CLAUDE.md`**: Clarified `dev` vs `master` branching strategy.

**Result:** Average response size reduced from ~9,000 to ~1,300 chars
per block (~85% reduction). This directly reduces LLM token consumption,
latency, and API costs for AutoPilot interactions.

### Checklist 📋

#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
  - [x] Verified models import and serialize correctly
- [x] Verified response size: 3,970 chars for 3 realistic blocks (avg
1,323/block)
- [x] Lint (`ruff check`) and type check (`pyright`) pass on changed
files
- [x] Frontend compatibility preserved: `blocks[].name` and `count`
fields retained for `block_list` handler

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Toran Bruce Richards <toran.richards@gmail.com>

2026-02-13 11:08:51 +01:00

3.6 KiB

Raw Blame History

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Repository Overview

AutoGPT Platform is a monorepo containing:

Backend (backend): Python FastAPI server with async support
Frontend (frontend): Next.js React application
Shared Libraries (autogpt_libs): Common Python utilities

Component Documentation

Backend: See @backend/CLAUDE.md for backend-specific commands, architecture, and development tasks
Frontend: See @frontend/CLAUDE.md for frontend-specific commands, architecture, and development patterns

Key Concepts

Agent Graphs: Workflow definitions stored as JSON, executed by the backend
Blocks: Reusable components in backend/backend/blocks/ that perform specific tasks
Integrations: OAuth and API connections stored per user
Store: Marketplace for sharing agent templates
Virus Scanning: ClamAV integration for file upload security

Environment Configuration

Configuration Files

Backend: backend/.env.default (defaults) → backend/.env (user overrides)
Frontend: frontend/.env.default (defaults) → frontend/.env (user overrides)
Platform: .env.default (Supabase/shared defaults) → .env (user overrides)

Docker Environment Loading Order

.env.default files provide base configuration (tracked in git)
.env files provide user-specific overrides (gitignored)
Docker Compose environment: sections provide service-specific overrides
Shell environment variables have highest precedence

Key Points

All services use hardcoded defaults in docker-compose files (no ${VARIABLE} substitutions)
The env_file directive loads variables INTO containers at runtime
Backend/Frontend services use YAML anchors for consistent configuration
Supabase services (db/docker/docker-compose.yml) follow the same pattern

Branching Strategy

dev is the main development branch. All PRs should target dev.
master is the production branch. Only used for production releases.

Creating Pull Requests

Create the PR against the dev branch of the repository.
Ensure the branch name is descriptive (e.g., feature/add-new-block)
Use conventional commit messages (see below)
Fill out the .github/PULL_REQUEST_TEMPLATE.md template as the PR description
Run the github pre-commit hooks to ensure code quality.

Reviewing/Revising Pull Requests

When the user runs /pr-comments or tries to fetch them, also run gh api /repos/Significant-Gravitas/AutoGPT/pulls/[issuenum]/reviews to get the reviews
Use gh api /repos/Significant-Gravitas/AutoGPT/pulls/[issuenum]/reviews/[review_id]/comments to get the review contents
Use gh api /repos/Significant-Gravitas/AutoGPT/issues/9924/comments to get the pr specific comments

Conventional Commits

Use this format for commit messages and Pull Request titles:

Conventional Commit Types:

feat: Introduces a new feature to the codebase
fix: Patches a bug in the codebase
refactor: Code change that neither fixes a bug nor adds a feature; also applies to removing features
ci: Changes to CI configuration
docs: Documentation-only changes
dx: Improvements to the developer experience

Recommended Base Scopes:

platform: Changes affecting both frontend and backend
frontend
backend
infra
blocks: Modifications/additions of individual blocks

Subscope Examples:

backend/executor
backend/db
frontend/builder (includes changes to the block UI component)
infra/prod

Use these scopes and subscopes for clarity and consistency in commit messages.

3.6 KiB Raw Blame History