Add Pre-commit Hooks (#165)
* chore (pre-commit): Setup Pre-commit Hooks and Add Path filter to unittests * chore (docs): Add pre-commit hook docs * chore (docs): Code Rabbit nitpicks
This commit is contained in:
Vineeth Voruganti
GitHub
parent
54fc5225ca
commit
c070b375a7
|
|
@ -1,6 +1,6 @@
|
|||
# Honcho Environment Variables Template
|
||||
# Copy this file to .env and fill in the appropriate values
|
||||
#
|
||||
#
|
||||
# Required variables are marked with (REQUIRED)
|
||||
# Optional variables have default values and can be left commented out
|
||||
|
||||
|
|
|
|||
|
|
@ -45,4 +45,3 @@ Log of changes introduced in this release in the style fo https://keepachangelog
|
|||
### **Fixed**
|
||||
|
||||
### **Security**
|
||||
|
||||
|
|
|
|||
|
|
@ -54,5 +54,5 @@ jobs:
|
|||
uses: actions/attest-build-provenance@v1.1.2
|
||||
with:
|
||||
subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
|
||||
subject-digest: ${{ steps.push.outputs.digest }}
|
||||
subject-digest: ${{ steps.push.outputs.digest }}
|
||||
push-to-registry: true
|
||||
|
|
|
|||
|
|
@ -3,14 +3,60 @@ name: FastAPI Tests with PostgreSQL and uv
|
|||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
paths:
|
||||
- '**.py'
|
||||
- '**.ts'
|
||||
- '**.js'
|
||||
- '**.tsx'
|
||||
- '**.jsx'
|
||||
- 'pyproject.toml'
|
||||
- 'uv.lock'
|
||||
- 'sdks/typescript/package.json'
|
||||
- 'sdks/typescript/bun.lock'
|
||||
- '.github/workflows/unittest.yml'
|
||||
pull_request:
|
||||
branches: [main]
|
||||
paths:
|
||||
- '**.py'
|
||||
- '**.ts'
|
||||
- '**.js'
|
||||
- '**.tsx'
|
||||
- '**.jsx'
|
||||
- 'pyproject.toml'
|
||||
- 'uv.lock'
|
||||
- 'sdks/typescript/package.json'
|
||||
- 'sdks/typescript/bun.lock'
|
||||
- '.github/workflows/unittest.yml'
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
# Determine which tests to run based on changed files
|
||||
changes:
|
||||
runs-on: ubuntu-latest
|
||||
outputs:
|
||||
python: ${{ steps.filter.outputs.python }}
|
||||
typescript: ${{ steps.filter.outputs.typescript }}
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: dorny/paths-filter@v3
|
||||
id: filter
|
||||
with:
|
||||
filters: |
|
||||
python:
|
||||
- '**.py'
|
||||
- 'pyproject.toml'
|
||||
- 'uv.lock'
|
||||
- 'migrations/**'
|
||||
- '.github/workflows/unittest.yml'
|
||||
typescript:
|
||||
- 'sdks/typescript/**'
|
||||
- '.github/workflows/unittest.yml'
|
||||
|
||||
test-python:
|
||||
needs: changes
|
||||
if: ${{ needs.changes.outputs.python == 'true' }}
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
services:
|
||||
|
|
@ -64,6 +110,8 @@ jobs:
|
|||
SUMMARY_MODEL: test
|
||||
|
||||
test-typescript:
|
||||
needs: changes
|
||||
if: ${{ needs.changes.outputs.typescript == 'true' }}
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
|
|
@ -86,3 +134,22 @@ jobs:
|
|||
env:
|
||||
HONCHO_API_KEY: test-key
|
||||
HONCHO_BASE_URL: http://localhost:8000
|
||||
|
||||
# Status check for branch protection rules
|
||||
# This job always runs and reports success only if all required jobs pass
|
||||
test-status:
|
||||
runs-on: ubuntu-latest
|
||||
needs: [changes, test-python, test-typescript]
|
||||
if: always()
|
||||
steps:
|
||||
- name: Check test results
|
||||
run: |
|
||||
if [[ "${{ needs.changes.outputs.python }}" == "true" && "${{ needs.test-python.result }}" != "success" && "${{ needs.test-python.result }}" != "skipped" ]]; then
|
||||
echo "Python tests failed or were cancelled"
|
||||
exit 1
|
||||
fi
|
||||
if [[ "${{ needs.changes.outputs.typescript }}" == "true" && "${{ needs.test-typescript.result }}" != "success" && "${{ needs.test-typescript.result }}" != "skipped" ]]; then
|
||||
echo "TypeScript tests failed or were cancelled"
|
||||
exit 1
|
||||
fi
|
||||
echo "All required tests passed!"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
{
|
||||
"default": true,
|
||||
"MD013": false,
|
||||
"MD024": false,
|
||||
"MD025": false,
|
||||
"MD029": false,
|
||||
"MD040": false,
|
||||
"MD041": false,
|
||||
"line-length": false,
|
||||
"no-duplicate-heading": false,
|
||||
"single-h1": false,
|
||||
"ol-prefix": false,
|
||||
"fenced-code-language": false,
|
||||
"first-line-h1": false
|
||||
}
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
# .pre-commit-config.yaml
|
||||
repos:
|
||||
# Basic file checks (run on all files)
|
||||
- repo: https://github.com/pre-commit/pre-commit-hooks
|
||||
rev: v4.5.0
|
||||
hooks:
|
||||
- id: trailing-whitespace
|
||||
- id: end-of-file-fixer
|
||||
- id: check-yaml
|
||||
- id: check-json
|
||||
- id: check-toml
|
||||
- id: check-added-large-files
|
||||
args: ['--maxkb=1000']
|
||||
- id: check-merge-conflict
|
||||
- id: debug-statements
|
||||
files: \.(py|js|ts)$
|
||||
- id: mixed-line-ending
|
||||
args: ['--fix=lf']
|
||||
# Additional checks from suggestions
|
||||
- id: check-docstring-first
|
||||
files: \.py$
|
||||
- id: check-executables-have-shebangs
|
||||
- id: check-case-conflict
|
||||
|
||||
# Python code formatting and linting with ruff
|
||||
- repo: https://github.com/astral-sh/ruff-pre-commit
|
||||
rev: v0.8.4
|
||||
hooks:
|
||||
# Linter - only on Python directories
|
||||
- id: ruff
|
||||
args: [--fix]
|
||||
files: ^(src/|tests/|scripts/|migrations/|sdks/python/).*\.py$
|
||||
# Formatter - only on Python directories
|
||||
- id: ruff-format
|
||||
files: ^(src/|tests/|scripts/|migrations/|sdks/python/).*\.py$
|
||||
|
||||
# Security checks - only on main src code (not tests/scripts)
|
||||
- repo: https://github.com/PyCQA/bandit
|
||||
rev: 1.7.10
|
||||
hooks:
|
||||
- id: bandit
|
||||
args: ['-r']
|
||||
files: ^(src/|sdks/python/src/).*\.py$
|
||||
|
||||
# Local hooks using your uv environment
|
||||
- repo: local
|
||||
hooks:
|
||||
# TypeScript linting with biome
|
||||
- id: biome-check
|
||||
name: biome check and format
|
||||
entry: bash -c 'cd sdks/typescript && bun run lint:fix'
|
||||
language: system
|
||||
files: ^sdks/typescript/.*\.(js|ts|jsx|tsx|json|jsonc)$
|
||||
pass_filenames: false
|
||||
|
||||
# Type checking with basedpyright - only on main Python code
|
||||
- id: basedpyright
|
||||
name: basedpyright
|
||||
entry: uv run basedpyright
|
||||
language: system
|
||||
files: ^(src/|tests/|sdks/python/|scripts/).*\.py$
|
||||
require_serial: true
|
||||
pass_filenames: false
|
||||
|
||||
# Run main application tests
|
||||
- id: pytest-main
|
||||
name: pytest (main app)
|
||||
entry: uv run pytest tests/
|
||||
language: system
|
||||
files: ^(src/|tests/).*\.py$
|
||||
stages: [pre-push]
|
||||
pass_filenames: false
|
||||
|
||||
# Run Python SDK tests (if they exist)
|
||||
- id: pytest-python-sdk
|
||||
name: pytest (Python SDK)
|
||||
entry: bash -c 'if [ -d "sdks/python/tests" ]; then cd sdks/python && uv run pytest; fi'
|
||||
language: system
|
||||
files: ^sdks/python/.*\.py$
|
||||
stages: [pre-push]
|
||||
pass_filenames: false
|
||||
|
||||
# TypeScript build/test with bun
|
||||
- id: typescript-check
|
||||
name: TypeScript build and test
|
||||
entry: bash -c 'if [ -f "sdks/typescript/package.json" ]; then cd sdks/typescript && bun run build && bun run test; fi'
|
||||
language: system
|
||||
files: ^sdks/typescript/.*\.(js|ts|jsx|tsx|json)$
|
||||
stages: [pre-push]
|
||||
pass_filenames: false
|
||||
|
||||
# TypeScript type checking with bun
|
||||
- id: typescript-typecheck
|
||||
name: TypeScript type check
|
||||
entry: bash -c 'if [ -f "sdks/typescript/package.json" ]; then cd sdks/typescript && bun run typecheck; fi'
|
||||
language: system
|
||||
files: ^sdks/typescript/.*\.(ts|tsx)$
|
||||
pass_filenames: false
|
||||
|
||||
# Optional: Coverage check for main app only
|
||||
- id: coverage-main
|
||||
name: coverage check (main app)
|
||||
entry: bash -c 'uv run coverage run -m pytest tests/ && uv run coverage report --fail-under=80'
|
||||
language: system
|
||||
files: ^(src/|tests/).*\.py$
|
||||
stages: [pre-push]
|
||||
pass_filenames: false
|
||||
|
||||
# License header check for Python files
|
||||
- id: check-license-header
|
||||
name: check license headers
|
||||
entry: bash -c 'for f in "$@"; do if [[ "$f" =~ \.(py)$ ]] && ! grep -q "Copyright" "$f"; then echo "Missing license header in $f"; exit 1; fi; done' --
|
||||
language: system
|
||||
files: ^(src/|sdks/python/src/).*\.py$
|
||||
pass_filenames: true
|
||||
|
||||
# Documentation linting
|
||||
- repo: https://github.com/igorshubovych/markdownlint-cli
|
||||
rev: v0.37.0
|
||||
hooks:
|
||||
- id: markdownlint
|
||||
args: ['--fix']
|
||||
files: \.(md|mdx)$
|
||||
|
||||
# Commit message linting
|
||||
- repo: https://github.com/commitizen-tools/commitizen
|
||||
rev: v3.13.0
|
||||
hooks:
|
||||
- id: commitizen
|
||||
stages: [commit-msg]
|
||||
|
|
@ -18,11 +18,14 @@ Before you start contributing, please:
|
|||
|
||||
1. Fork the repository on GitHub
|
||||
2. Clone your fork locally:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/YOUR_USERNAME/honcho.git
|
||||
cd honcho
|
||||
```
|
||||
|
||||
3. Add the upstream repository as a remote:
|
||||
|
||||
```bash
|
||||
git remote add upstream https://github.com/plastic-labs/honcho.git
|
||||
```
|
||||
|
|
|
|||
|
|
@ -44,4 +44,3 @@ EXPOSE 8000
|
|||
|
||||
# https://stackoverflow.com/questions/29663459/python-app-does-not-print-anything-when-running-detached-in-docker
|
||||
CMD ["fastapi", "run", "--host", "0.0.0.0", "src/main.py"]
|
||||
|
||||
|
|
|
|||
52
README.md
52
README.md
|
|
@ -192,6 +192,58 @@ This is a development server that will reload whenever code is changed. When
|
|||
first launching the API with a connection to the database it will provision the
|
||||
necessary tables for Honcho to operate.
|
||||
|
||||
### Pre-commit Hooks
|
||||
|
||||
Honcho uses pre-commit hooks to ensure code quality and consistency across the project. These hooks automatically run checks on your code before each commit, including linting, formatting, type checking, and security scans.
|
||||
|
||||
#### Installation
|
||||
|
||||
To set up pre-commit hooks in your development environment:
|
||||
|
||||
1. **Install pre-commit using uv**
|
||||
|
||||
```bash
|
||||
uv add --dev pre-commit
|
||||
```
|
||||
|
||||
2. **Install the pre-commit hooks**
|
||||
|
||||
```bash
|
||||
uv run pre-commit install \
|
||||
--hook-type pre-commit \
|
||||
--hook-type commit-msg \
|
||||
--hook-type pre-push
|
||||
```
|
||||
|
||||
This will install hooks for `pre-commit`, `commit-msg`, and `pre-push` stages.
|
||||
|
||||
#### What the hooks do
|
||||
|
||||
The pre-commit configuration includes:
|
||||
|
||||
- **Code Quality**: Python linting and formatting (ruff), TypeScript linting (biome)
|
||||
- **Type Checking**: Static type analysis with basedpyright
|
||||
- **Security**: Vulnerability scanning with bandit
|
||||
- **Documentation**: Markdown linting and license header checks
|
||||
- **Testing**: Automated test runs for Python and TypeScript code
|
||||
- **File Hygiene**: Trailing whitespace, line endings, file size checks
|
||||
- **Commit Standards**: Conventional commit message validation
|
||||
|
||||
#### Manual execution
|
||||
|
||||
You can run the hooks manually on all files without making a commit:
|
||||
|
||||
```bash
|
||||
uv run pre-commit run --all-files
|
||||
```
|
||||
|
||||
Or run specific hooks:
|
||||
|
||||
```bash
|
||||
uv run pre-commit run ruff --all-files
|
||||
uv run pre-commit run basedpyright --all-files
|
||||
```
|
||||
|
||||
### Docker
|
||||
|
||||
As mentioned earlier a `docker-compose` template is included for running Honcho.
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ PROFILES_SAMPLE_RATE = 0.1
|
|||
[llm]
|
||||
DEFAULT_MAX_TOKENS = 2500
|
||||
|
||||
# API Keys for LLM providers
|
||||
# API Keys for LLM providers
|
||||
# ANTHROPIC_API_KEY = "your-api-key"
|
||||
# OPENAI_API_KEY = "your-api-key"
|
||||
# OPENAI_COMPATIBLE_API_KEY = "your-api-key"
|
||||
|
|
|
|||
|
|
@ -5,18 +5,21 @@ These docs are built using Next.js via mintlify.
|
|||
## Setting Up Honcho's Docs Locally
|
||||
|
||||
1. Clone the repository:
|
||||
|
||||
```
|
||||
git clone git@github.com:plastic-labs/honcho.git
|
||||
```
|
||||
|
||||
2. Navigate into the `docs` folder:
|
||||
|
||||
```
|
||||
cd honcho/docs/
|
||||
```
|
||||
|
||||
The docs folder contains the markdown files that make up the documentation. The majority of the files are in the pages directory. Some notable files in this folder include:
|
||||
|
||||
|
||||
3. Verify that you have Node.js and npm installed in your system. You can check by running:
|
||||
|
||||
```
|
||||
node --version
|
||||
npm --version
|
||||
|
|
@ -25,18 +28,21 @@ npm --version
|
|||
4. If not installed, download Node.js and npm from the respective official websites.
|
||||
|
||||
5. Once you have Node.js and npm running, proceed to install `pnpm` - another package manager that helps to manage project dependencies:
|
||||
|
||||
```
|
||||
npm install -g pnpm
|
||||
```
|
||||
|
||||
6. Install the project dependencies using pnpm:
|
||||
|
||||
```
|
||||
pnpm i
|
||||
```
|
||||
|
||||
7. After the successful installation of the project dependencies, start the local server:
|
||||
|
||||
```
|
||||
pnpm dev
|
||||
```
|
||||
|
||||
Now, you should be able to view the docs on your local environment by visiting `http://localhost:3000`. You can explore the different markdown files and make changes as you see fit.
|
||||
Now, you should be able to view the docs on your local environment by visiting `http://localhost:3000`. You can explore the different markdown files and make changes as you see fit.
|
||||
|
|
|
|||
|
|
@ -13,13 +13,13 @@ This guide helps you understand which versions of Honcho's API are compatible wi
|
|||
<CardGroup cols={2}>
|
||||
<Card title="TypeScript SDK" icon="js">
|
||||
**Compatible Version:** v1.2.1
|
||||
|
||||
|
||||
Install with:
|
||||
```bash
|
||||
npm install @honcho-ai/sdk@1.2.1
|
||||
```
|
||||
</Card>
|
||||
|
||||
|
||||
<Card title="Python SDK" icon="python">
|
||||
**Compatible Version:** v1.2.2
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
|
|||
|
||||
- Migration/provision scripts did not have correct database connection arguments, causing timeouts
|
||||
</Update>
|
||||
|
||||
|
||||
<Update label="v2.0.3">
|
||||
### Fixed
|
||||
|
||||
|
|
@ -201,7 +201,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
|
|||
|
||||
- Get/poll deriver queue status endpoints added to workspace
|
||||
- Added endpoint to upload files as messages
|
||||
|
||||
|
||||
### Removed
|
||||
|
||||
- Removed peer messages in accordance with Honcho 2.1.0
|
||||
|
|
@ -222,7 +222,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
|
|||
[TypeScript SDK](https://www.npmjs.com/package/@honcho-ai/sdk)
|
||||
<Update label="v1.2.1 (Current)">
|
||||
### Added
|
||||
|
||||
|
||||
- linting via Biome
|
||||
- Adding filter parameter to various endpoints
|
||||
|
||||
|
|
@ -258,4 +258,4 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
|
|||
If you encounter issues using the Honcho API or its SDKs:
|
||||
|
||||
1. Open an issue on [GitHub](https://github.com/plastic-labs/honcho/issues)
|
||||
2. Join our [Discord community](http://discord.gg/plasticlabs) for support
|
||||
2. Join our [Discord community](http://discord.gg/plasticlabs) for support
|
||||
|
|
|
|||
|
|
@ -34,4 +34,4 @@
|
|||
<path class="cls-2" d="M839.24,3.18v156.95h-49.36v-65.97h-39.58v65.97h-49.36V3.18h49.36v56.41h39.58V3.18h49.36Z"/>
|
||||
<path class="cls-2" d="M966.05,7.05c10.39,4.7,17.93,12.89,22.63,24.57,4.7,11.68,7.05,28.36,7.05,50.04s-2.35,38.37-7.05,50.04c-4.7,11.68-12.25,19.87-22.63,24.57-10.39,4.7-24.91,7.05-43.56,7.05s-32.95-2.35-43.33-7.05c-10.39-4.7-17.93-12.89-22.63-24.57-4.7-11.68-7.05-28.36-7.05-50.04s2.35-38.36,7.05-50.04c4.7-11.68,12.24-19.86,22.63-24.57,10.39-4.7,24.83-7.05,43.33-7.05s33.17,2.35,43.56,7.05ZM909.41,40.38c-2.96,2.5-5.04,6.9-6.26,13.19-1.22,6.29-1.82,15.66-1.82,28.09s.6,21.8,1.82,28.09c1.21,6.29,3.3,10.69,6.26,13.19s7.31,3.75,13.08,3.75,10.12-1.25,13.08-3.75,5.04-6.9,6.26-13.19c1.21-6.29,1.82-15.66,1.82-28.09s-.61-21.8-1.82-28.09c-1.22-6.29-3.3-10.69-6.26-13.19s-7.32-3.75-13.08-3.75-10.12,1.25-13.08,3.75Z"/>
|
||||
</g>
|
||||
</svg>
|
||||
</svg>
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 4.6 KiB After Width: | Height: | Size: 4.6 KiB |
|
|
@ -27,4 +27,4 @@
|
|||
<path class="cls-2" d="M839.24,3.18v156.95h-49.36v-65.97h-39.58v65.97h-49.36V3.18h49.36v56.41h39.58V3.18h49.36Z"/>
|
||||
<path class="cls-2" d="M966.05,7.05c10.39,4.7,17.93,12.89,22.63,24.57,4.7,11.68,7.05,28.36,7.05,50.04s-2.35,38.37-7.05,50.04c-4.7,11.68-12.25,19.87-22.63,24.57-10.39,4.7-24.91,7.05-43.56,7.05s-32.95-2.35-43.33-7.05c-10.39-4.7-17.93-12.89-22.63-24.57-4.7-11.68-7.05-28.36-7.05-50.04s2.35-38.36,7.05-50.04c4.7-11.68,12.24-19.86,22.63-24.57,10.39-4.7,24.83-7.05,43.33-7.05s33.17,2.35,43.56,7.05ZM909.41,40.38c-2.96,2.5-5.04,6.9-6.26,13.19-1.22,6.29-1.82,15.66-1.82,28.09s.6,21.8,1.82,28.09c1.21,6.29,3.3,10.69,6.26,13.19s7.31,3.75,13.08,3.75,10.12-1.25,13.08-3.75,5.04-6.9,6.26-13.19c1.21-6.29,1.82-15.66,1.82-28.09s-.61-21.8-1.82-28.09c-1.22-6.29-3.3-10.69-6.26-13.19s-7.32-3.75-13.08-3.75-10.12,1.25-13.08,3.75Z"/>
|
||||
</g>
|
||||
</svg>
|
||||
</svg>
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 4.5 KiB After Width: | Height: | Size: 4.5 KiB |
|
|
@ -1 +1 @@
|
|||
This subdirectory contains the app/user/session paradigm documentation for Honcho (Honcho v1.1.0).
|
||||
This subdirectory contains the app/user/session paradigm documentation for Honcho (Honcho v1.1.0).
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/name/{name}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/get_or_create/{name}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v1/apps/{app_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/collections
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: delete /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/{user_id}/collections/name/{name}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/{user_id}/collections
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/collections/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}/documents
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: delete /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}/documents/{document_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}/documents/{document_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}/documents/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v1/apps/{app_id}/users/{user_id}/collections/{collection_id}/documents/{document_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/keys
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/messages/batch
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/messages
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/messages/{message_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/messages/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/messages/{message_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/chat
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/clone
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: delete /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}/chat/stream
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/{user_id}/sessions/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v1/apps/{app_id}/users/{user_id}/sessions/{session_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/get_or_create/{name}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v1/apps/{app_id}/users/name/{name}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v1/apps/{app_id}/users/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v1/apps/{app_id}/users/{user_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,12 +2,12 @@
|
|||
title: 'Introduction'
|
||||
---
|
||||
|
||||
This section of the documentation goes over all of the different API endpoints available in the Honcho
|
||||
This section of the documentation covers the different API endpoints available in the Honcho
|
||||
Server. They largely map to CRUD operations for each of the core primitives. For information about the core
|
||||
primitives consult [Architecture](/v1/getting-started/architecture)
|
||||
|
||||
<Warning>
|
||||
This part of the documentation is autogenerated for the most up to date and accurate API spec view the
|
||||
This part of the documentation is autogenerated. For the most up-to-date and accurate API spec view the
|
||||
[Redoc](https://demo.honcho.dev/redoc) or [Swagger](https://demo.honcho.dev/docs) directly.
|
||||
</Warning>
|
||||
|
||||
|
|
|
|||
|
|
@ -18,23 +18,23 @@ Honcho defines custom exception types in `src/exceptions.py`:
|
|||
class HonchoException(Exception):
|
||||
status_code = 500 # Default status code
|
||||
detail = "An unexpected error occurred" # Default message
|
||||
|
||||
|
||||
class ResourceNotFoundException(HonchoException):
|
||||
status_code = 404
|
||||
detail = "Resource not found"
|
||||
|
||||
|
||||
class ValidationException(HonchoException):
|
||||
status_code = 422
|
||||
detail = "Validation error"
|
||||
|
||||
|
||||
class ConflictException(HonchoException):
|
||||
status_code = 409
|
||||
status_code = 409
|
||||
detail = "Resource conflict"
|
||||
|
||||
|
||||
class AuthenticationException(HonchoException):
|
||||
status_code = 401
|
||||
detail = "Authentication failed"
|
||||
|
||||
|
||||
class AuthorizationException(HonchoException):
|
||||
status_code = 403
|
||||
detail = "Not authorized to access this resource"
|
||||
|
|
@ -107,7 +107,7 @@ try:
|
|||
logger.info(f"Successfully processed message {message_id}")
|
||||
except Exception as e:
|
||||
logger.error(
|
||||
f"Error processing message {message_id}: {str(e)}",
|
||||
f"Error processing message {message_id}: {str(e)}",
|
||||
exc_info=True
|
||||
)
|
||||
if os.getenv("SENTRY_ENABLED", "False").lower() == "true":
|
||||
|
|
@ -124,7 +124,7 @@ except Exception as e:
|
|||
2. **Include context in logs**:
|
||||
```python
|
||||
logger.error(
|
||||
f"Failed to process message for app {app_id}, user {user_id}",
|
||||
f"Failed to process message for app {app_id}, user {user_id}",
|
||||
exc_info=True
|
||||
)
|
||||
```
|
||||
|
|
@ -155,16 +155,16 @@ if os.getenv("SENTRY_ENABLED", "False").lower() == "true":
|
|||
async def update_document(db, collection_id, document_id, document):
|
||||
"""
|
||||
Update a document.
|
||||
|
||||
|
||||
Args:
|
||||
db: Database session
|
||||
collection_id: ID of the collection
|
||||
document_id: ID of the document
|
||||
document: Document update schema
|
||||
|
||||
|
||||
Returns:
|
||||
The updated document
|
||||
|
||||
|
||||
Raises:
|
||||
ResourceNotFoundException: If the document or collection does not exist
|
||||
ValidationException: If the document data is invalid
|
||||
|
|
@ -172,13 +172,13 @@ async def update_document(db, collection_id, document_id, document):
|
|||
try:
|
||||
# Get document (raises ResourceNotFoundException if not found)
|
||||
honcho_document = await get_document(db, collection_id, document_id)
|
||||
|
||||
|
||||
# Update document data
|
||||
if document.content is not None:
|
||||
honcho_document.content = document.content
|
||||
if document.metadata is not None:
|
||||
honcho_document.h_metadata = document.metadata
|
||||
|
||||
|
||||
await db.commit()
|
||||
logger.info(f"Document {document_id} updated successfully")
|
||||
return honcho_document
|
||||
|
|
@ -194,9 +194,9 @@ async def update_document(db, collection_id, document_id, document):
|
|||
@router.get("/{document_id}")
|
||||
async def get_document(
|
||||
app_id: str,
|
||||
user_id: str,
|
||||
collection_id: str,
|
||||
document_id: str,
|
||||
user_id: str,
|
||||
collection_id: str,
|
||||
document_id: str,
|
||||
db: AsyncSession = db
|
||||
):
|
||||
"""Get a document by ID"""
|
||||
|
|
@ -216,7 +216,7 @@ async def process_item(db, payload):
|
|||
if field not in payload:
|
||||
logger.error(f"Missing required field in payload: {field}")
|
||||
raise ValidationException(f"Missing field: {field}")
|
||||
|
||||
|
||||
# Process the item
|
||||
await do_processing(db, payload)
|
||||
logger.info(f"Processed message {payload['message_id']}")
|
||||
|
|
@ -225,4 +225,4 @@ async def process_item(db, payload):
|
|||
if os.getenv("SENTRY_ENABLED", "False").lower() == "true":
|
||||
sentry_sdk.capture_exception(e)
|
||||
raise
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ icon: 'handshake-angle'
|
|||
This project is completely open source and welcomes any and all open source
|
||||
contributions. The workflow for contributing is to make a fork of the
|
||||
repository. You can claim an issue in the issues tab or start a new thread to
|
||||
indicate a feature or bug fix you are working on.
|
||||
indicate a feature or bug fix you are working on.
|
||||
|
||||
Once you have finished your contribution make a PR , and it will be reviewed by
|
||||
a project manager. Feel free to join us in our
|
||||
[discord](http://discord.gg/plasticlabs) to discuss your changes or get help.
|
||||
|
||||
Your changes will undergo a period of testing and discussion before finally
|
||||
being entered into the `main` branch and being staged for release. For more
|
||||
being entered into the `main` branch and being staged for release. For more
|
||||
details, check out our [contributing](https://github.com/plastic-labs/honcho/blob/main/CONTRIBUTING.md)
|
||||
document.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 'License'
|
|||
icon: 'scroll'
|
||||
---
|
||||
|
||||
Honcho is licensed under the AGPL-3.0 License. This is copied below for convenience and also present in the
|
||||
Honcho is licensed under the AGPL-3.0 License. This is copied below for convenience and also present in the
|
||||
[GitHub Repository](https://github.com/plastic-labs/honcho)
|
||||
|
||||
```
|
||||
|
|
@ -668,4 +668,4 @@ specific requirements.
|
|||
if any, to sign a "copyright disclaimer" for the program, if necessary.
|
||||
For more information on this, and how to apply and follow the GNU AGPL, see
|
||||
<https://www.gnu.org/licenses/>.
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,26 +4,26 @@ description: 'Learn the core primitives and the structure of Honcho'
|
|||
icon: 'building'
|
||||
---
|
||||
|
||||
Honcho is a user context management system for AI powered applications.
|
||||
The storage concepts are inspired by, but not a 1:1 mapping of, the OpenAI
|
||||
Assistants API. The insights concepts are inspired by cognitive science,
|
||||
Honcho is a user context management system for AI-powered applications.
|
||||
The storage concepts are inspired by, but not a 1:1 mapping of, the OpenAI
|
||||
Assistants API. The insights concepts are inspired by cognitive science,
|
||||
philosophy, and machine learning.
|
||||
|
||||
Honcho is open source. We believe trust and transparency are vital for
|
||||
developing AI technology. We're also focused on using and supporting existing
|
||||
tools rather than developing from scratch.
|
||||
|
||||
We focus on flexible, user-centric storage primitives to promote community
|
||||
exploration of novel memory frameworks and the usage of the
|
||||
[Dialectic API](https://blog.plasticlabs.ai/blog/Introducing-Honcho's-Dialectic-API)
|
||||
to support them. Language models are highly capable of modeling human psychology.
|
||||
By building a data management framework that is user-centric, we aim to address
|
||||
not only practical application development issues (like scaling, statefulness,
|
||||
etc.) but also kickstart exploration of the design space of what's possible
|
||||
given access to rich user models. You can read more about Honcho's origin,
|
||||
We focus on flexible, user-centric storage primitives to promote community
|
||||
exploration of novel memory frameworks and the usage of the
|
||||
[Dialectic API](https://blog.plasticlabs.ai/blog/Introducing-Honcho's-Dialectic-API)
|
||||
to support them. Language models are highly capable of modeling human psychology.
|
||||
By building a data management framework that is user-centric, we aim to address
|
||||
not only practical application development issues (like scaling, statefulness,
|
||||
etc.) but also kickstart exploration of the design space of what's possible
|
||||
given access to rich user models. You can read more about Honcho's origin,
|
||||
inspiration and philosophy on our [blog](https://blog.plasticlabs.ai).
|
||||
|
||||
## Core Primitives
|
||||
## Core Primitives
|
||||
|
||||
Using Honcho has the following flow:
|
||||
1. Initialize your `Honcho` instance and `App`
|
||||
|
|
@ -53,7 +53,7 @@ erDiagram
|
|||
datetime created_at
|
||||
jsonb h_metadata "metadata"
|
||||
}
|
||||
|
||||
|
||||
User {
|
||||
BigInteger id PK
|
||||
string public_id
|
||||
|
|
@ -62,7 +62,7 @@ erDiagram
|
|||
datetime created_at
|
||||
string app_id FK
|
||||
}
|
||||
|
||||
|
||||
Session {
|
||||
BigInteger id PK
|
||||
string public_id
|
||||
|
|
@ -71,7 +71,7 @@ erDiagram
|
|||
datetime created_at
|
||||
string user_id FK
|
||||
}
|
||||
|
||||
|
||||
Message {
|
||||
BigInteger id PK
|
||||
string public_id
|
||||
|
|
@ -81,7 +81,7 @@ erDiagram
|
|||
jsonb h_metadata "metadata"
|
||||
datetime created_at
|
||||
}
|
||||
|
||||
|
||||
Metamessage {
|
||||
BigInteger id PK
|
||||
string public_id
|
||||
|
|
@ -93,7 +93,7 @@ erDiagram
|
|||
datetime created_at
|
||||
jsonb h_metadata "metadata"
|
||||
}
|
||||
|
||||
|
||||
Collection {
|
||||
BigInteger id PK
|
||||
string public_id
|
||||
|
|
@ -102,7 +102,7 @@ erDiagram
|
|||
jsonb h_metadata "metadata"
|
||||
string user_id FK
|
||||
}
|
||||
|
||||
|
||||
Document {
|
||||
BigInteger id PK
|
||||
string public_id
|
||||
|
|
@ -121,30 +121,30 @@ An `App` is the highest-level primitive in Honcho. It is the scope that all of y
|
|||
### Users
|
||||
|
||||
The `User` object is the main interface for managing a User's context. With it
|
||||
you can interface with the `User`'s `Session`s and `Collections`s directly.
|
||||
you can interface with the `User`'s `Session`s and `Collections`s directly.
|
||||
|
||||
### Sessions
|
||||
### Sessions
|
||||
|
||||
The `Session` object is useful for organizing your interactions with `User`s.
|
||||
Different `User`s can have different sessions enabling you to neatly segment user
|
||||
context. It also accepts a `location_id` parameter which can specifically
|
||||
denote *where* users' sessions are taking place.
|
||||
denote *where* users' sessions are taking place.
|
||||
|
||||
### Messages
|
||||
### Messages
|
||||
|
||||
Sessions are made up of `Message` objects. You can append them to sessions.
|
||||
This is pretty straightforward.
|
||||
|
||||
### Metamessages
|
||||
|
||||
Success in LLM applications is dependent on elegant context management, so we
|
||||
provide a `Metamessage` object for flexible context storage and construction. Each
|
||||
`Metamessage` is tied to a `User` object via the required `user_id` argument. Keeping
|
||||
this separate from the core user-assistant message history ensures the
|
||||
Success in LLM applications is dependent on elegant context management, so we
|
||||
provide a `Metamessage` object for flexible context storage and construction. Each
|
||||
`Metamessage` is tied to a `User` object via the required `user_id` argument. Keeping
|
||||
this separate from the core user-assistant message history ensures the
|
||||
insights service running ambiently is doing so on authentic ground truth
|
||||
We've found this particularly useful for storing intermediate inferences,
|
||||
constructing very specific chat histories, and more. Metamessages can optionally be
|
||||
attached to sessions and/or messages, so constructing historical context for inference is
|
||||
We've found this particularly useful for storing intermediate inferences,
|
||||
constructing very specific chat histories, and more. Metamessages can optionally be
|
||||
attached to sessions and/or messages, so constructing historical context for inference is
|
||||
as easy as possible.
|
||||
|
||||
### Collections
|
||||
|
|
|
|||
|
|
@ -95,4 +95,4 @@ Repeat step 3.
|
|||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
Curious about what changed in a CLI version? [Check out the CLI changelog.](/changelog/introduction)
|
||||
Curious about what changed in a CLI version? [Check out the CLI changelog.](/changelog/introduction)
|
||||
|
|
|
|||
|
|
@ -4,17 +4,17 @@ description: "An endpoint for reasoning about your users"
|
|||
icon: "comments"
|
||||
---
|
||||
|
||||
Honcho by default runs ambient inference on top of the `message` objects you store. Those messages serve as the ground truth upon which facts about the user are derived and stored. The **Dialectic Endpoint** is the natural language interface through which insights are synthesized from those facts. We believe [intellectual respect](https://blog.plasticlabs.ai/extrusions/Extrusion-02.24) for LLMs is paramount in building effective AI agents/apps. It follows that the LLM should know better than any human what would aid them in their generation task. Thus, the Dialectic endpoint exists for flexible agent-to-agent communication.
|
||||
Honcho by default runs ambient inference on top of the `message` objects you store. Those messages serve as the ground truth upon which facts about the user are derived and stored. The **Dialectic Endpoint** is the natural language interface through which insights are synthesized from those facts. We believe [intellectual respect](https://blog.plasticlabs.ai/extrusions/Extrusion-02.24) for LLMs is paramount in building effective AI agents/apps. It follows that the LLM should know better than any human what would aid them in their generation task. Thus, the Dialectic endpoint exists for flexible agent-to-agent communication.
|
||||
|
||||
## Automatic Fact Derivation
|
||||
|
||||
On every message written to a session, an automatic callback is run that will reason about the conversation and store facts in a `collection` named `honcho`. This is a reserved `collection` specifically for the backend Honcho agent to interact with.
|
||||
On every message written to a session, an automatic callback is run that will reason about the conversation and store facts in a `collection` named `honcho`. This is a reserved `collection` specifically for the backend Honcho agent to interact with.
|
||||
|
||||
## Dialectic Endpoint
|
||||
|
||||
You can query the automatically derived facts in the `honcho` collection directly, or you can offload this task to our agent and use the Dialectic endpoint. This endpoint allows you to define logic enabling your agent to talk to our agent that automatically retrieves and synthesizes facts from the collection.
|
||||
You can query the automatically derived facts in the `honcho` collection directly, or you can offload this task to our agent and use the Dialectic endpoint. This endpoint allows you to define logic enabling your agent to talk to our agent that automatically retrieves and synthesizes facts from the collection.
|
||||
|
||||
This chat interface is exposed via the `chat` endpoint. It accepts a string or a list of strings. Below is some example code on how this works.
|
||||
This chat interface is exposed via the `chat` endpoint. It accepts a string or a list of strings. Below is some example code on how this works.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ const session = await honcho.apps.users.sessions.create(app.id, user.id, {});
|
|||
// (assuming some messages have been written to Honcho for the deriver to use)
|
||||
```
|
||||
</CodeGroup>
|
||||
## Static Dialectic Call
|
||||
## Static Dialectic Call
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
|
|
@ -91,6 +91,3 @@ with honcho.apps.users.sessions.with_streaming_response.stream(
|
|||
</CodeGroup>
|
||||
|
||||
We've designed the Dialectic endpoint to be infinitely flexible. We wrote an incomplete list of ideas on how to use it on our blog [here](https://blog.plasticlabs.ai/blog/Introducing-Honcho's-Dialectic-API#how-it-works).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Any application interface that defines logic based on events and supports
|
|||
special commands can work easily with Honcho. Here's how to use Honcho with
|
||||
**Discord** as an interface. If you're not familiar with Discord bot
|
||||
application logic, the [py-cord](https://pycord.dev/) docs would be a good
|
||||
place to start.
|
||||
place to start.
|
||||
|
||||
## Events
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ is_reply_to_bot = (
|
|||
is_mention = bot.user.mentioned_in(message)
|
||||
```
|
||||
|
||||
These lines check what kind of message is being sent in Discord, which is a useful condition to check before entering the reply logic. The code inside that if-statement is commented quite well, so we'll just go over the relevant Honcho parts.
|
||||
These lines check what kind of message is being sent in Discord, which is a useful condition to check before entering the reply logic. The code inside that if-statement is commented quite well, so we'll just go over the relevant Honcho parts.
|
||||
|
||||
```python
|
||||
# Get a user object for the message author
|
||||
|
|
@ -121,7 +121,7 @@ user_id = f"discord_{str(message.author.id)}"
|
|||
user = honcho.apps.users.get_or_create(name=user_id, app_id=app.id)
|
||||
```
|
||||
|
||||
Here we're getting or creating a user for an app that's been defined at the top of the file.
|
||||
Here we're getting or creating a user for an app that's been defined at the top of the file.
|
||||
|
||||
```python
|
||||
# Use the channel ID as the location_id (for DMs, this will be unique to the user)
|
||||
|
|
@ -151,7 +151,7 @@ The first helper function we create is called `get_session`. This simplifies a l
|
|||
def get_session(user_id, location_id, create=False):
|
||||
# Get an existing session for the user and location or optionally create a new one if none exists.
|
||||
# Returns a tuple of (session, is_new) where is_new indicates if a new session was created.
|
||||
|
||||
|
||||
# Query for *active* sessions with both user_id and location_id
|
||||
sessions_iter = honcho.apps.users.sessions.list(
|
||||
app_id=app.id, user_id=user_id, reverse=True, filter={"is_active": True}
|
||||
|
|
@ -246,7 +246,7 @@ async def restart(ctx):
|
|||
await ctx.respond(msg)
|
||||
```
|
||||
|
||||
This slash command restarts a conversation with a bot. In Honcho, the `delete` method marks a session's `is_active` field to `False`.
|
||||
This slash command restarts a conversation with a bot. In Honcho, the `delete` method marks a session's `is_active` field to `False`.
|
||||
|
||||
## Recap
|
||||
|
||||
|
|
@ -257,4 +257,3 @@ How you use Honcho is tightly coupled with the client you're building in. Here,
|
|||
- how to sort and filter when calling list methods
|
||||
|
||||
You are well on your way to becoming a context construction master! Stay tuned for more in-depth examples. If you want a challenge, try deciphering how we construct context in one of our apps, [Bloom](https://github.com/plastic-labs/tutor-gpt/blob/main/app/Chat.tsx).
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ cd honcho-mcp
|
|||
3. Sync the virtual environment. This package uses [uv](https://docs.astral.sh/uv/), [install](https://docs.astral.sh/uv/#installation) if you haven't.
|
||||
|
||||
```
|
||||
uv sync
|
||||
uv sync
|
||||
```
|
||||
|
||||
4. In Claude Desktop, go to the *top left Mac Toolbar* Settings > Developer and click "Edit Config"
|
||||
|
|
@ -49,7 +49,7 @@ uv sync
|
|||
|
||||
<Warning>You probably will need to put the full path to the uv executable in the command field. You can get this by running `which uv` on MacOS/Linux or `where uv` on Windows.</Warning>
|
||||
|
||||
6. Restart the Claude Desktop app. Upon relaunch it should start Honcho and the tools should be available!
|
||||
6. Restart the Claude Desktop app. Upon relaunch it should start Honcho and the tools should be available!
|
||||
|
||||
Just note that, by default, the MCP server is set up to use the Honcho Demo server, which only persists data for 7 days. If you're using the hosted version of Honcho, copy the `.env.template` to a proper `.env` file and update the URL and API key variables accordingly.
|
||||
|
||||
|
|
@ -59,4 +59,4 @@ Finally, Claude needs instructions on how to use Honcho. The Desktop app doesn't
|
|||
|
||||
<Note>Be sure to update the \<app_name\> and \<user_name\> variables in the instructions.txt file.</Note>
|
||||
|
||||
Claude should then query for insights before responding and write your messages to storage! If you come up with more creative ways to get Claude to manage its own memory with Honcho, feel free to [let us know](https://discord.gg/plasticlabs) or make a PR on this [repo](https://github.com/plastic-labs/honcho-mcp/tree/main)!
|
||||
Claude should then query for insights before responding and write your messages to storage! If you come up with more creative ways to get Claude to manage its own memory with Honcho, feel free to [let us know](https://discord.gg/plasticlabs) or make a PR on this [repo](https://github.com/plastic-labs/honcho-mcp/tree/main)!
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@ title: "Spellbooks and Tutorials"
|
|||
sidebarTitle: 'Overview'
|
||||
description: 'Helpful guides and design patterns for building with Honcho'
|
||||
icon: 'hat-wizard'
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: "A simple example of how to store and derive facts about individual
|
|||
---
|
||||
|
||||
This guide shows how to implement a simple user memory system that derives and stores facts about users that
|
||||
are then referenced later on.
|
||||
are then referenced later on.
|
||||
|
||||
A fully working example can be found on [GitHub](https://github.com/plastic-labs/honcho-python/tree/main/examples/discord/fact-memory).
|
||||
It's setup as a discord bot so view our [Discord guide](./discord)
|
||||
|
|
@ -50,7 +50,7 @@ For this part we will be leveraging LangChain and GPT-4 to derivce facts on the
|
|||
```python
|
||||
def derive_facts(user_input):
|
||||
# Derive facts about the user
|
||||
|
||||
|
||||
fact_derivation = ChatPromptTemplate.from_messages([
|
||||
SystemMessagePromptTemplate(prompt=prompt)
|
||||
])
|
||||
|
|
@ -91,7 +91,7 @@ advantage of one of LangChain's built in output parsers for this.
|
|||
This is where Honcho comes into play. With Honcho we can initialize
|
||||
`Collections` for each user and can store facts as vector embeddings. You can
|
||||
use multiple collections if you want to segment different types of facts or
|
||||
data, but for now we just need one.
|
||||
data, but for now we just need one.
|
||||
|
||||
```python
|
||||
def store_facts(app_id, user_id, facts):
|
||||
|
|
@ -102,7 +102,7 @@ def store_facts(app_id, user_id, facts):
|
|||
except NotFoundError as e:
|
||||
collection = honcho.apps.users.collections.create(app_id=app.id, user_id=user.id, name="discord")
|
||||
collection: Collection
|
||||
|
||||
|
||||
for fact in facts: # store each fact in the collection
|
||||
honcho.apps.users.collections.documents.create(
|
||||
app_id=app_id, user_id=user_id, collection_id=collection.id, content=fact
|
||||
|
|
@ -120,7 +120,7 @@ The trick we use below is to have the LLM determine the query and then use it in
|
|||
|
||||
```python
|
||||
def introspect(chat_history, input):
|
||||
|
||||
|
||||
introspection_prompt = ChatPromptTemplate.from_messages([
|
||||
system_introspection
|
||||
])
|
||||
|
|
@ -166,11 +166,11 @@ _type: prompt
|
|||
input_variables:
|
||||
["chat_history", "user_input"]
|
||||
template: >
|
||||
Given the conversation history and user input, use your theory of mind skills to list out questions you'd like to know about the user in order to best respond to them.
|
||||
|
||||
Given the conversation history and user input, use your theory of mind skills to list out questions you'd like to know about the user in order to best respond to them.
|
||||
|
||||
Chat history: ```{chat_history}```
|
||||
User input: ```{user_input}```
|
||||
|
||||
|
||||
Output the questions as a numbered list.
|
||||
```
|
||||
|
||||
|
|
@ -189,5 +189,5 @@ template: >
|
|||
```
|
||||
---
|
||||
|
||||
This is a very simple method of using Honcho to hold user context. For further reading on the limits read about
|
||||
This is a very simple method of using Honcho to hold user context. For further reading on the limits read about
|
||||
[violation of expectation](https://arxiv.org/abs/2310.06983).
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ async def restaurant_recommendation_chat():
|
|||
app = await honcho.apps.get_or_create(name="food-app")
|
||||
user = await honcho.apps.users.get_or_create(app_id=app.id, name="food-lover")
|
||||
session = await honcho.apps.users.sessions.create(app_id=app.id, user_id=user.id)
|
||||
|
||||
|
||||
# Store multiple user messages about food preferences
|
||||
user_messages = [
|
||||
"I absolutely love spicy Thai food, especially curries with coconut milk.",
|
||||
|
|
@ -132,7 +132,7 @@ async def restaurant_recommendation_chat():
|
|||
"I try to eat vegetarian most of the time, but occasionally enjoy seafood.",
|
||||
"I can't handle overly sweet desserts, but love something with dark chocolate."
|
||||
]
|
||||
|
||||
|
||||
# Store the user's messages in the session
|
||||
for message in user_messages:
|
||||
await honcho.apps.users.sessions.messages.create(
|
||||
|
|
@ -143,12 +143,12 @@ async def restaurant_recommendation_chat():
|
|||
is_user=True
|
||||
)
|
||||
print(f"User: {message}")
|
||||
|
||||
|
||||
# Ask for restaurant recommendations based on preferences
|
||||
print("\nRequesting restaurant recommendations...")
|
||||
print("Assistant: ", end="", flush=True)
|
||||
full_response = ""
|
||||
|
||||
|
||||
# Stream the response
|
||||
with honcho.apps.users.sessions.with_streaming_response.stream(
|
||||
app_id=app.id,
|
||||
|
|
@ -160,7 +160,7 @@ async def restaurant_recommendation_chat():
|
|||
print(chunk, end="", flush=True)
|
||||
full_response += chunk
|
||||
await asyncio.sleep(0.01)
|
||||
|
||||
|
||||
# Store the assistant's complete response
|
||||
await honcho.apps.users.sessions.messages.create(
|
||||
app_id=app.id,
|
||||
|
|
@ -183,7 +183,7 @@ async function restaurantRecommendationChat() {
|
|||
const app = await honcho.apps.getOrCreate('food-app');
|
||||
const user = await honcho.apps.users.getOrCreate(app.id, 'food-lover');
|
||||
const session = await honcho.apps.users.sessions.create(app.id, user.id, {});
|
||||
|
||||
|
||||
// Store multiple user messages about food preferences
|
||||
const userMessages = [
|
||||
"I absolutely love spicy Thai food, especially curries with coconut milk.",
|
||||
|
|
@ -191,7 +191,7 @@ async function restaurantRecommendationChat() {
|
|||
"I try to eat vegetarian most of the time, but occasionally enjoy seafood.",
|
||||
"I can't handle overly sweet desserts, but love something with dark chocolate."
|
||||
];
|
||||
|
||||
|
||||
// Store the user's messages in the session
|
||||
for (const message of userMessages) {
|
||||
await honcho.apps.users.sessions.messages.create(app.id, user.id, session.id, {
|
||||
|
|
@ -200,23 +200,23 @@ async function restaurantRecommendationChat() {
|
|||
});
|
||||
console.log(`User: ${message}`);
|
||||
}
|
||||
|
||||
|
||||
// Ask for restaurant recommendations based on preferences
|
||||
console.log("\nRequesting restaurant recommendations...");
|
||||
process.stdout.write("Assistant: ");
|
||||
let fullResponse = "";
|
||||
|
||||
|
||||
// Stream the response
|
||||
const stream = await honcho.apps.users.sessions.chat(app.id, user.id, session.id, {
|
||||
queries: "Based on this user's food preferences, recommend 3 restaurants they might enjoy in the Lower East Side.",
|
||||
stream: true
|
||||
});
|
||||
|
||||
|
||||
for await (const chunk of stream) {
|
||||
process.stdout.write(chunk);
|
||||
fullResponse += chunk;
|
||||
}
|
||||
|
||||
|
||||
// Store the assistant's complete response
|
||||
await honcho.apps.users.sessions.messages.create(app.id, user.id, session.id, {
|
||||
content: fullResponse,
|
||||
|
|
@ -237,4 +237,4 @@ When implementing streaming:
|
|||
- Be mindful of memory usage when accumulating large responses
|
||||
- Use appropriate error handling for network interruptions
|
||||
|
||||
Streaming responses provide a more interactive and engaging user experience. By implementing streaming in your Honcho applications, you can create more responsive AI-powered features that feel natural and immediate to your users.
|
||||
Streaming responses provide a more interactive and engaging user experience. By implementing streaming in your Honcho applications, you can create more responsive AI-powered features that feel natural and immediate to your users.
|
||||
|
|
|
|||
|
|
@ -5169,4 +5169,4 @@
|
|||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
This subdirectory contains the peer-paradigm documentation for Honcho (Honcho v2.0.0 onwards).
|
||||
This subdirectory contains the peer-paradigm documentation for Honcho (Honcho v2.0.0 onwards).
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/keys
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/{message_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/{message_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/upload
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/chat
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/peers
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/peers/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/sessions
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/representation
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/search
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v2/workspaces/{workspace_id}/peers/{peer_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/clone
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: delete /v2/workspaces/{workspace_id}/sessions/{session_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/peers/{peer_id}/config
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/context
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: delete /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/search
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/peers/{peer_id}/config
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v2/workspaces/{workspace_id}/sessions/{session_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/list
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: get /v2/workspaces/{workspace_id}/deriver/status
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: post /v2/workspaces/{workspace_id}/search
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
---
|
||||
openapi: put /v2/workspaces/{workspace_id}
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ git checkout -b fix/your-bug-fix-name
|
|||
|
||||
**Branch naming conventions:**
|
||||
- `feature/description` - for new features
|
||||
- `fix/description` - for bug fixes
|
||||
- `fix/description` - for bug fixes
|
||||
- `docs/description` - for documentation updates
|
||||
- `refactor/description` - for code refactoring
|
||||
- `test/description` - for adding or updating tests
|
||||
|
|
@ -169,4 +169,4 @@ When reporting bugs or requesting features:
|
|||
|
||||
By contributing to Honcho, you agree that your contributions will be licensed under the same [AGPL-3.0 License](./license) that covers the project.
|
||||
|
||||
Thank you for helping make Honcho better! 🫡
|
||||
Thank you for helping make Honcho better! 🫡
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 'License'
|
|||
icon: 'scroll'
|
||||
---
|
||||
|
||||
Honcho is licensed under the AGPL-3.0 License. This is copied below for convenience and also present in the
|
||||
Honcho is licensed under the AGPL-3.0 License. This is copied below for convenience and also present in the
|
||||
[GitHub Repository](https://github.com/plastic-labs/honcho)
|
||||
|
||||
```
|
||||
|
|
@ -668,4 +668,4 @@ specific requirements.
|
|||
if any, to sign a "copyright disclaimer" for the program, if necessary.
|
||||
For more information on this, and how to apply and follow the GNU AGPL, see
|
||||
<https://www.gnu.org/licenses/>.
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebarTitle: "Architecture"
|
|||
|
||||
<Note> The goal of this page is to build an intuition for the primitives in Honcho and how they fit together </Note>
|
||||
|
||||
Honcho has 3 main components that work together to manage agent identity and context.
|
||||
Honcho has 3 main components that work together to manage agent identity and context.
|
||||
|
||||
- **The Storage API**: The Memory layer for storing interaction history for your agents
|
||||
- **The Deriver**: The background processing layer that builds representations of users and agents
|
||||
|
|
@ -20,7 +20,7 @@ how to use them.
|
|||
|
||||
## Data Model
|
||||
|
||||
Honcho has a hierarchical data model centered around the entities below.
|
||||
Honcho has a hierarchical data model centered around the entities below.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
|
|
@ -42,15 +42,17 @@ Honcho has a hierarchical data model centered around the entities below.
|
|||
|
||||
There are `Workspaces` at the top that contain `Peers` and `Sessions`. A `Peer`
|
||||
can be part of many `Sessions` and a `Session` can have many `Peers`. Both
|
||||
`Sessions` and `Peers` can have `Messages`
|
||||
`Sessions` and `Peers` can have `Messages`
|
||||
|
||||
### <Icon icon="building" /> Workspaces
|
||||
|
||||
Workspaces are the top-level containers that provide complete isolation between different applications or environments; they essentially as a namespace to isolate different workloads or environments
|
||||
Workspaces are the top-level containers that provide complete isolation between
|
||||
different applications or environments; they essentially serve as a namespace
|
||||
to isolate different workloads or environments
|
||||
|
||||
**Key Features:**
|
||||
- **Isolation**: Complete data separation between workspaces
|
||||
- **Multi-tenancy**: Support multiple applications or environments
|
||||
- **Multi-tenancy**: Support multiple applications or environments
|
||||
- **Configuration**: Workspace-level settings and metadata
|
||||
- **Access Control**: Authentication scoped to workspace level
|
||||
|
||||
|
|
@ -110,7 +112,7 @@ Messages are the fundamental units of interaction within sessions. They may
|
|||
also be used at the peer level to ingest information of any kind that is not related to a specific interaction, but provides
|
||||
important context for a peer (emails, docs, files, etc.).
|
||||
|
||||
**Key Features:**
|
||||
**Key Features:**
|
||||
- **Rich Content**: Support for text, metadata, and structured data
|
||||
- **Attribution**: Clear association with sending peer
|
||||
- **Ordering**: Chronological sequence within sessions
|
||||
|
|
@ -136,7 +138,7 @@ differently and update different representations.
|
|||
Facts derived here are used in the Dialectic chat endpoint to generate
|
||||
context-aware responses that can correctly reference both concrete facts
|
||||
extracted from messages and social insights deduced from facts, tone, and
|
||||
opinion.
|
||||
opinion.
|
||||
|
||||
<Info>
|
||||
Deriver tasks are processed in parallel, but tasks affecting the same peer representation will always be processed serially in order of message creation, so as to properly understand their cumulative effect.
|
||||
|
|
@ -151,11 +153,11 @@ There are two types of tasks that the deriver currently does:
|
|||
|
||||
Peer representations are more of an abstract concept, as they are made up of
|
||||
various pieces of data stored throughout Honcho. There are however
|
||||
multiple types of representations that Honcho can produce.
|
||||
multiple types of representations that Honcho can produce.
|
||||
|
||||
Honcho handles both **local** and **global** representations of Peers, where
|
||||
**local** representations are specific to a single Peer's view of another Peer,
|
||||
while Global Representations are based on any message ever produced by a Peer.
|
||||
while Global Representations are based on any message ever produced by a Peer.
|
||||
|
||||
<img src="/images/local-vs-global-reps.png" alt="Peer Representations" />
|
||||
|
||||
|
|
@ -164,7 +166,7 @@ representation, but she also maintains a local representation of Bob based on wh
|
|||
observes and similarly Bob has a global representation of himself and local
|
||||
representation of Alice. So in the example above, when Alice sends a message to
|
||||
Bob it triggers an update to both Alice's global representation of herself and Bob's local
|
||||
representation of Alice.
|
||||
representation of Alice.
|
||||
|
||||
If Alice were to have another conversation with a different Peer, Nico, and
|
||||
sent them a message, this action would trigger an update to Alice's Global
|
||||
|
|
|
|||
|
|
@ -13,18 +13,14 @@ Peers in Honcho are abstract entities that can represent humans, agents, or NPCs
|
|||
- **Local Representation**: The representation that a Peer forms of other Peers, based on the messages those other Peers have sent (as observed by the Peer forming the representation).
|
||||
- At the Session level, you can configure which Peers are able to observe messages from other Peers in that Session. This determines which Peers form representations of others within the Session.
|
||||
|
||||
### Ingest Arbitrary Data
|
||||
To facilitate the construction of a Peer's global representation, Honcho is able to ingest arbitrary data to a Peer by adding messages to the Peer directly, outside of the context of a Session.
|
||||
- Currently, Honcho supports the ingestion of arbitrary text data.
|
||||
|
||||
### Queue Status
|
||||
To help developers understand when a Peer's representation is fully up to date, Honcho exposes the ability to poll the status of Peer-centric queues that construct representations.
|
||||
To help developers understand when a Peer's representation is fully up to date, Honcho exposes the ability to poll the status of Peer-centric queues that construct representations.
|
||||
- If no Session is specified, the queue status reflects pending work for the Peer's global representation.
|
||||
- If a Session is specified, the queue status reflects pending work for the Peer's working representation in that Session.
|
||||
|
||||
### Search
|
||||
Honcho supports full-text search across message content across different scopes.
|
||||
- You can search within a specific Session, Peer, or across all messages in a Workspace.
|
||||
Honcho supports full-text search across message content in different scopes.
|
||||
- You can search within a specific Session, Peer, or across all messages in a Workspace.
|
||||
- Search results are ordered by relevance, making it easy to quickly retrieve important past messages.
|
||||
|
||||
### Scoped API Keys
|
||||
|
|
@ -33,8 +29,8 @@ Builders can create scoped API keys to control access to different resources wit
|
|||
- **Peer-Level Keys**: Access to everything scoped to a Peer.
|
||||
- **Session-Level Keys**: Access to everything scoped to a Session.
|
||||
|
||||
### Get Context
|
||||
### Get Context
|
||||
Honcho provides a powerful context retrieval feature that delivers formatted conversation context from sessions, making it easy to integrate with LLMs like OpenAI, Anthropic, and others.
|
||||
- By default, the context includes a blend of summary and messages which covers the entire history of the session.
|
||||
- By default, the context includes a blend of summary and messages which covers the entire history of the session.
|
||||
- Summaries are generated automatically at intervals, and recent messages are included based on your specified token budget for the context.
|
||||
- You can set any token limit, and if you prefer, you can disable summaries so that the context consists entirely of the most recent messages up to your chosen limit.
|
||||
|
|
|
|||
|
|
@ -67,4 +67,4 @@ cognitive functions.
|
|||
continually generating & updating internal world models to anticipate sensory input, rather than
|
||||
passively receiving it--closely linked to Bayesian brain hypotheses, which hold that the brain
|
||||
interprets the world probabilistically, weighing prior knowledge against new evidence to minimize
|
||||
uncertainty.
|
||||
uncertainty.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue