RomanNum3ral
/
honcho
mirror of https://github.com/plastic-labs/honcho.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #276 from plastic-labs/vince/dev-1259 

V/C Docs Revamp
This commit is contained in:
doria 2025-12-10 13:06:42 -05:00 committed by GitHub
parent 42a28dfda1 2b25edaf25
commit 971b183f11
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
101 changed files with 14982 additions and 204 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

372
docs/bun.lock
View File

@ -4,11 +4,11 @@
"": {
"name": "honcho-docs",
"dependencies": {
"@mintlify/scraping": "^4.0.284",
"@mintlify/scraping": "^4.0.467",
"honcho-ai": "^0.0.11",
},
"devDependencies": {
"mint": "^4.2.123",
"mint": "^4.2.204",
},
},
},
@ -17,9 +17,9 @@
"@alloc/quick-lru": ["@alloc/quick-lru@5.2.0", "", {}, "sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw=="],
"@ark/schema": ["@ark/schema@0.49.0", "", { "dependencies": { "@ark/util": "0.49.0" } }, "sha512-GphZBLpW72iS0v4YkeUtV3YIno35Gimd7+ezbPO9GwEi9kzdUrPVjvf6aXSBAfHikaFc/9pqZOpv3pOXnC71tw=="],
"@ark/schema": ["@ark/schema@0.55.0", "", { "dependencies": { "@ark/util": "0.55.0" } }, "sha512-IlSIc0FmLKTDGr4I/FzNHauMn0MADA6bCjT1wauu4k6MyxhC1R9gz0olNpIRvK7lGGDwtc/VO0RUDNvVQW5WFg=="],
"@ark/util": ["@ark/util@0.49.0", "", {}, "sha512-/BtnX7oCjNkxi2vi6y1399b+9xd1jnCrDYhZ61f0a+3X8x8DxlK52VgEEzyuC2UQMPACIfYrmHkhD3lGt2GaMA=="],
"@ark/util": ["@ark/util@0.55.0", "", {}, "sha512-aWFNK7aqSvqFtVsl1xmbTjGbg91uqtJV7Za76YGNEwIO4qLjMfyY8flmmbhooYMuqPCO2jyxu8hve943D+w3bA=="],
"@asyncapi/parser": ["@asyncapi/parser@3.4.0", "", { "dependencies": { "@asyncapi/specs": "^6.8.0", "@openapi-contrib/openapi-schema-to-json-schema": "~3.2.0", "@stoplight/json": "3.21.0", "@stoplight/json-ref-readers": "^1.2.2", "@stoplight/json-ref-resolver": "^3.1.5", "@stoplight/spectral-core": "^1.18.3", "@stoplight/spectral-functions": "^1.7.2", "@stoplight/spectral-parsers": "^1.0.2", "@stoplight/spectral-ref-resolver": "^1.0.3", "@stoplight/types": "^13.12.0", "@types/json-schema": "^7.0.11", "@types/urijs": "^1.19.19", "ajv": "^8.17.1", "ajv-errors": "^3.0.0", "ajv-formats": "^2.1.1", "avsc": "^5.7.5", "js-yaml": "^4.1.0", "jsonpath-plus": "^10.0.0", "node-fetch": "2.6.7" } }, "sha512-Sxn74oHiZSU6+cVeZy62iPZMFMvKp4jupMFHelSICCMw1qELmUHPvuZSr+ZHDmNGgHcEpzJM5HN02kR7T4g+PQ=="],
@ -29,6 +29,8 @@
"@babel/helper-validator-identifier": ["@babel/helper-validator-identifier@7.27.1", "", {}, "sha512-D2hP9eA+Sqx1kBZgzxZh0y1trbuU+JoDkiEwqhQ36nodYqJwyEIhPSdMNd7lOm/4io72luTPWH20Yda0xOuUow=="],
"@canvas/image-data": ["@canvas/image-data@1.1.0", "", {}, "sha512-QdObRRjRbcXGmM1tmJ+MrHcaz1MftF2+W7YI+MsphnsCrmtyfS0d5qJbk0MeSbUeyM/jCb0hmnkXPsy026L7dA=="],
"@emnapi/runtime": ["@emnapi/runtime@1.4.5", "", { "dependencies": { "tslib": "^2.4.0" } }, "sha512-++LApOtY0pEEz1zrd9vy1/zXVaVJJ/EbAF3u0fXIzPJEDtnITsBGbbK0EkM72amhl/R5b+5xx0Y/QhcVOpuulg=="],
"@floating-ui/core": ["@floating-ui/core@1.7.3", "", { "dependencies": { "@floating-ui/utils": "^0.2.10" } }, "sha512-sGnvb5dmrJaKEZ+LDIpguvdX3bDlEllmv4/ClQ9awcmCZrlx5jQyyMWFM5kBI+EyNOCDDiKk8il0zeuX3Zlg/w=="],
@ -77,31 +79,35 @@
"@img/sharp-win32-x64": ["@img/sharp-win32-x64@0.33.5", "", { "os": "win32", "cpu": "x64" }, "sha512-MpY/o8/8kj+EcnxwvrP4aTJSWw/aZ7JIGR4aBeZkZw5B7/Jn+tY9/VNwtcoGmdT7GfggGIU4kygOMSbYnOrAbg=="],
"@inquirer/checkbox": ["@inquirer/checkbox@4.2.0", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-fdSw07FLJEU5vbpOPzXo5c6xmMGDzbZE2+niuDHX5N6mc6V0Ebso/q3xiHra4D73+PMsC8MJmcaZKuAAoaQsSA=="],
"@inquirer/ansi": ["@inquirer/ansi@1.0.2", "", {}, "sha512-S8qNSZiYzFd0wAcyG5AXCvUHC5Sr7xpZ9wZ2py9XR88jUz8wooStVx5M6dRzczbBWjic9NP7+rY0Xi7qqK/aMQ=="],
"@inquirer/confirm": ["@inquirer/confirm@5.1.14", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-5yR4IBfe0kXe59r1YCTG8WXkUbl7Z35HK87Sw+WUyGD8wNUx7JvY7laahzeytyE1oLn74bQnL7hstctQxisQ8Q=="],
"@inquirer/checkbox": ["@inquirer/checkbox@4.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/core": "^10.3.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-VXukHf0RR1doGe6Sm4F0Em7SWYLTHSsbGfJdS9Ja2bX5/D5uwVOEjr07cncLROdBvmnvCATYEWlHqYmXv2IlQA=="],
"@inquirer/confirm": ["@inquirer/confirm@5.1.21", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/type": "^3.0.10" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-KR8edRkIsUayMXV+o3Gv+q4jlhENF9nMYUZs9PA2HzrXeHI8M5uDag70U7RJn9yyiMZSbtF5/UexBtAVtZGSbQ=="],
"@inquirer/core": ["@inquirer/core@10.1.15", "", { "dependencies": { "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-8xrp836RZvKkpNbVvgWUlxjT4CraKk2q+I3Ksy+seI2zkcE+y6wNs1BVhgcv8VyImFecUhdQrYLdW32pAjwBdA=="],
"@inquirer/editor": ["@inquirer/editor@4.2.15", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "external-editor": "^3.1.0" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-wst31XT8DnGOSS4nNJDIklGKnf+8shuauVrWzgKegWUe28zfCftcWZ2vktGdzJgcylWSS2SrDnYUb6alZcwnCQ=="],
"@inquirer/editor": ["@inquirer/editor@4.2.23", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/external-editor": "^1.0.3", "@inquirer/type": "^3.0.10" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-aLSROkEwirotxZ1pBaP8tugXRFCxW94gwrQLxXfrZsKkfjOYC1aRvAZuhpJOb5cu4IBTJdsCigUlf2iCOu4ZDQ=="],
"@inquirer/expand": ["@inquirer/expand@4.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-PSqy9VmJx/VbE3CT453yOfNa+PykpKg/0SYP7odez1/NWBGuDXgPhp4AeGYYKjhLn5lUUavVS/JbeYMPdH50Mw=="],
"@inquirer/expand": ["@inquirer/expand@4.0.23", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/type": "^3.0.10", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-nRzdOyFYnpeYTTR2qFwEVmIWypzdAx/sIkCMeTNTcflFOovfqUk+HcFhQQVBftAh9gmGrpFj6QcGEqrDMDOiew=="],
"@inquirer/figures": ["@inquirer/figures@1.0.13", "", {}, "sha512-lGPVU3yO9ZNqA7vTYz26jny41lE7yoQansmqdMLBEfqaGsmdg7V3W9mK9Pvb5IL4EVZ9GnSDGMO/cJXud5dMaw=="],
"@inquirer/external-editor": ["@inquirer/external-editor@1.0.3", "", { "dependencies": { "chardet": "^2.1.1", "iconv-lite": "^0.7.0" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-RWbSrDiYmO4LbejWY7ttpxczuwQyZLBUyygsA9Nsv95hpzUWwnNTVQmAq3xuh7vNwCp07UTmE5i11XAEExx4RA=="],
"@inquirer/input": ["@inquirer/input@4.2.1", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-tVC+O1rBl0lJpoUZv4xY+WGWY8V5b0zxU1XDsMsIHYregdh7bN5X5QnIONNBAl0K765FYlAfNHS2Bhn7SSOVow=="],
"@inquirer/figures": ["@inquirer/figures@1.0.15", "", {}, "sha512-t2IEY+unGHOzAaVM5Xx6DEWKeXlDDcNPeDyUpsRc6CUhBfU3VQOEl+Vssh7VNp1dR8MdUJBWhuObjXCsVpjN5g=="],
"@inquirer/number": ["@inquirer/number@3.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-GcvGHkyIgfZgVnnimURdOueMk0CztycfC8NZTiIY9arIAkeOgt6zG57G+7vC59Jns3UX27LMkPKnKWAOF5xEYg=="],
"@inquirer/input": ["@inquirer/input@4.3.1", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/type": "^3.0.10" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-kN0pAM4yPrLjJ1XJBjDxyfDduXOuQHrBB8aLDMueuwUGn+vNpF7Gq7TvyVxx8u4SHlFFj4trmj+a2cbpG4Jn1g=="],
"@inquirer/password": ["@inquirer/password@4.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-DJolTnNeZ00E1+1TW+8614F7rOJJCM4y4BAGQ3Gq6kQIG+OJ4zr3GLjIjVVJCbKsk2jmkmv6v2kQuN/vriHdZA=="],
"@inquirer/number": ["@inquirer/number@3.0.23", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/type": "^3.0.10" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-5Smv0OK7K0KUzUfYUXDXQc9jrf8OHo4ktlEayFlelCjwMXz0299Y8OrI+lj7i4gCBY15UObk76q0QtxjzFcFcg=="],
"@inquirer/prompts": ["@inquirer/prompts@7.7.1", "", { "dependencies": { "@inquirer/checkbox": "^4.2.0", "@inquirer/confirm": "^5.1.14", "@inquirer/editor": "^4.2.15", "@inquirer/expand": "^4.0.17", "@inquirer/input": "^4.2.1", "@inquirer/number": "^3.0.17", "@inquirer/password": "^4.0.17", "@inquirer/rawlist": "^4.1.5", "@inquirer/search": "^3.0.17", "@inquirer/select": "^4.3.1" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-XDxPrEWeWUBy8scAXzXuFY45r/q49R0g72bUzgQXZ1DY/xEFX+ESDMkTQolcb5jRBzaNJX2W8XQl6krMNDTjaA=="],
"@inquirer/password": ["@inquirer/password@4.0.23", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/core": "^10.3.2", "@inquirer/type": "^3.0.10" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-zREJHjhT5vJBMZX/IUbyI9zVtVfOLiTO66MrF/3GFZYZ7T4YILW5MSkEYHceSii/KtRk+4i3RE7E1CUXA2jHcA=="],
"@inquirer/rawlist": ["@inquirer/rawlist@4.1.5", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-R5qMyGJqtDdi4Ht521iAkNqyB6p2UPuZUbMifakg1sWtu24gc2Z8CJuw8rP081OckNDMgtDCuLe42Q2Kr3BolA=="],
"@inquirer/prompts": ["@inquirer/prompts@7.10.1", "", { "dependencies": { "@inquirer/checkbox": "^4.3.2", "@inquirer/confirm": "^5.1.21", "@inquirer/editor": "^4.2.23", "@inquirer/expand": "^4.0.23", "@inquirer/input": "^4.3.1", "@inquirer/number": "^3.0.23", "@inquirer/password": "^4.0.23", "@inquirer/rawlist": "^4.1.11", "@inquirer/search": "^3.2.2", "@inquirer/select": "^4.4.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-Dx/y9bCQcXLI5ooQ5KyvA4FTgeo2jYj/7plWfV5Ak5wDPKQZgudKez2ixyfz7tKXzcJciTxqLeK7R9HItwiByg=="],
"@inquirer/search": ["@inquirer/search@3.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-CuBU4BAGFqRYors4TNCYzy9X3DpKtgIW4Boi0WNkm4Ei1hvY9acxKdBdyqzqBCEe4YxSdaQQsasJlFlUJNgojw=="],
"@inquirer/rawlist": ["@inquirer/rawlist@4.1.11", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/type": "^3.0.10", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-+LLQB8XGr3I5LZN/GuAHo+GpDJegQwuPARLChlMICNdwW7OwV2izlCSCxN6cqpL0sMXmbKbFcItJgdQq5EBXTw=="],
"@inquirer/select": ["@inquirer/select@4.3.1", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-Gfl/5sqOF5vS/LIrSndFgOh7jgoe0UXEizDqahFRkq5aJBLegZ6WjuMh/hVEJwlFQjyLq1z9fRtvUMkb7jM1LA=="],
"@inquirer/search": ["@inquirer/search@3.2.2", "", { "dependencies": { "@inquirer/core": "^10.3.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-p2bvRfENXCZdWF/U2BXvnSI9h+tuA8iNqtUKb9UWbmLYCRQxd8WkvwWvYn+3NgYaNwdUkHytJMGG4MMLucI1kA=="],
"@inquirer/select": ["@inquirer/select@4.4.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/core": "^10.3.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-l4xMuJo55MAe+N7Qr4rX90vypFwCajSakx59qe/tMaC1aEHWLyw68wF4o0A4SLAY4E0nd+Vt+EyskeDIqu1M6w=="],
"@inquirer/type": ["@inquirer/type@3.0.8", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-lg9Whz8onIHRthWaN1Q9EGLa/0LFJjyM8mEUbL1eTi6yMGvBf8gvyDLtxSXztQsxMvhxxNpJYrwa1YHdq+w4Jw=="],
@ -127,25 +133,25 @@
"@mdx-js/react": ["@mdx-js/react@3.1.0", "", { "dependencies": { "@types/mdx": "^2.0.0" }, "peerDependencies": { "@types/react": ">=16", "react": ">=16" } }, "sha512-QjHtSaoameoalGnKDT3FoIl4+9RwyTmo9ZJGBdLOks/YOiWHoRDI3PUwEzOE7kEmGcV3AFcp9K6dYu9rEuKLAQ=="],
"@mintlify/cli": ["@mintlify/cli@4.0.727", "", { "dependencies": { "@mintlify/common": "1.0.537", "@mintlify/link-rot": "3.0.674", "@mintlify/models": "0.0.229", "@mintlify/prebuild": "1.0.661", "@mintlify/previewing": "4.0.710", "@mintlify/validation": "0.1.471", "chalk": "^5.2.0", "detect-port": "^1.5.1", "fs-extra": "^11.2.0", "gray-matter": "^4.0.3", "ink": "^6.0.1", "inquirer": "^12.3.0", "js-yaml": "^4.1.0", "react": "^19.1.0", "semver": "^7.7.2", "yargs": "^17.6.0" }, "bin": { "mint": "bin/index.js", "mintlify": "bin/index.js" } }, "sha512-6iplgwOC9wK1FFdSFE9NX92qhxF0TkuZADf2rVkSR/A3MQ9LzTh9iKttRWD0q66pQ8l2kwOhzwqt/tW22ZLmcA=="],
"@mintlify/cli": ["@mintlify/cli@4.0.808", "", { "dependencies": { "@inquirer/prompts": "^7.9.0", "@mintlify/common": "1.0.607", "@mintlify/link-rot": "3.0.750", "@mintlify/models": "0.0.240", "@mintlify/prebuild": "1.0.736", "@mintlify/previewing": "4.0.786", "@mintlify/validation": "0.1.521", "adm-zip": "^0.5.10", "chalk": "^5.2.0", "color": "^4.2.3", "detect-port": "^1.5.1", "fs-extra": "^11.2.0", "gray-matter": "^4.0.3", "ink": "^6.0.1", "inquirer": "^12.3.0", "js-yaml": "^4.1.0", "mdast-util-mdx-jsx": "^3.2.0", "react": "^19.1.0", "semver": "^7.7.2", "unist-util-visit": "^5.0.0", "yargs": "^17.6.0" }, "bin": { "mint": "bin/index.js", "mintlify": "bin/index.js" } }, "sha512-oVd+33DuORSXQPyVhX9VamME+qZkbGwSGAaas3LaNoabGxw9O9Nb34KYDvABvVOf9LqHCy/O+FhmegW+zr3upQ=="],
"@mintlify/common": ["@mintlify/common@1.0.461", "", { "dependencies": { "@asyncapi/parser": "^3.4.0", "@mintlify/mdx": "^2.0.3", "@mintlify/models": "0.0.213", "@mintlify/openapi-parser": "^0.0.7", "@mintlify/validation": "0.1.424", "@sindresorhus/slugify": "^2.1.1", "acorn": "^8.11.2", "acorn-jsx": "^5.3.2", "estree-util-to-js": "^2.0.0", "estree-walker": "^3.0.3", "gray-matter": "^4.0.3", "hast-util-from-html": "^2.0.3", "hast-util-to-html": "^9.0.4", "hast-util-to-text": "^4.0.2", "js-yaml": "^4.1.0", "lodash": "^4.17.21", "mdast": "^3.0.0", "mdast-util-from-markdown": "^2.0.2", "mdast-util-mdx": "^3.0.0", "mdast-util-mdx-jsx": "^3.1.3", "micromark-extension-mdx-jsx": "^3.0.1", "openapi-types": "^12.0.0", "remark": "^15.0.1", "remark-frontmatter": "^5.0.0", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-mdx": "^3.1.0", "remark-stringify": "^11.0.0", "unified": "^11.0.5", "unist-builder": "^4.0.0", "unist-util-map": "^4.0.0", "unist-util-remove": "^4.0.0", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.1", "vfile": "^6.0.3" } }, "sha512-tDKqkB5RolG0INcUwpLjVb8BuhUt+KyJ8FH+W0UUw267olEaKnU8u8TYVVclHHvRd6jvYzaXjGdGARx2CN3pgQ=="],
"@mintlify/common": ["@mintlify/common@1.0.607", "", { "dependencies": { "@asyncapi/parser": "^3.4.0", "@mintlify/mdx": "^3.0.1", "@mintlify/models": "0.0.240", "@mintlify/openapi-parser": "^0.0.8", "@mintlify/validation": "0.1.521", "@sindresorhus/slugify": "^2.1.1", "acorn": "^8.11.2", "acorn-jsx": "^5.3.2", "color-blend": "^4.0.0", "estree-util-to-js": "^2.0.0", "estree-walker": "^3.0.3", "gray-matter": "^4.0.3", "hast-util-from-html": "^2.0.3", "hast-util-to-html": "^9.0.4", "hast-util-to-text": "^4.0.2", "hex-rgb": "^5.0.0", "js-yaml": "^4.1.0", "lodash": "^4.17.21", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.0.0", "mdast-util-mdx": "^3.0.0", "mdast-util-mdx-jsx": "^3.1.3", "micromark-extension-gfm": "^3.0.0", "micromark-extension-mdx-jsx": "^3.0.1", "micromark-extension-mdxjs": "^3.0.0", "openapi-types": "^12.0.0", "postcss": "^8.5.6", "remark": "^15.0.1", "remark-frontmatter": "^5.0.0", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-mdx": "^3.1.0", "remark-stringify": "^11.0.0", "tailwindcss": "^3.4.4", "unified": "^11.0.5", "unist-builder": "^4.0.0", "unist-util-map": "^4.0.0", "unist-util-remove": "^4.0.0", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.1", "vfile": "^6.0.3" } }, "sha512-9Yc8piWlOTSyapcV1MsjnsDZmaHlgP1cJ2IqtNd5+dvuy6pFz2TG8ELJxg9k9rf25KleOvI+QN3pJ8pHbnJWtg=="],
"@mintlify/link-rot": ["@mintlify/link-rot@3.0.674", "", { "dependencies": { "@mintlify/common": "1.0.537", "@mintlify/prebuild": "1.0.661", "@mintlify/previewing": "4.0.710", "@mintlify/validation": "0.1.471", "fs-extra": "^11.1.0", "unist-util-visit": "^4.1.1" } }, "sha512-QzbMAva0GdbBBG6R+pWmHrVzNdR08ug6e6a5Tnxk1NaNr8+/YR7cehu5xdAX31aO6n+CIv8Ot5HxzsqsY2vwtA=="],
"@mintlify/link-rot": ["@mintlify/link-rot@3.0.750", "", { "dependencies": { "@mintlify/common": "1.0.607", "@mintlify/prebuild": "1.0.736", "@mintlify/previewing": "4.0.786", "@mintlify/validation": "0.1.521", "fs-extra": "^11.1.0", "unist-util-visit": "^4.1.1" } }, "sha512-IkrpTs29C+ouUgyp9p2zGE80AfRlgOgkffzKcDi+UBkSrSSVA82ub3CaA+Lk5Zyrhr5t5aI1wx2Z9FnLmvuNwg=="],
"@mintlify/mdx": ["@mintlify/mdx@2.0.3", "", { "dependencies": { "@shikijs/transformers": "^3.6.0", "hast-util-to-string": "^3.0.1", "mdast-util-mdx-jsx": "^3.2.0", "next-mdx-remote-client": "^1.0.3", "rehype-katex": "^7.0.1", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-smartypants": "^3.0.2", "shiki": "^3.6.0", "unified": "^11.0.0", "unist-util-visit": "^5.0.0" }, "peerDependencies": { "react": "^18.3.1", "react-dom": "^18.3.1" } }, "sha512-UGlwavma8QooWAlhtXpTAG5MAUZTTUKI8Qu25Wqfp1HMOPrYGvo5YQPmlqqogbMsqDMcFPLP/ZYnaZsGUYBspQ=="],
"@mintlify/mdx": ["@mintlify/mdx@3.0.3", "", { "dependencies": { "@shikijs/transformers": "^3.11.0", "@shikijs/twoslash": "^3.12.2", "arktype": "^2.1.26", "hast-util-to-string": "^3.0.1", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.1.0", "mdast-util-mdx-jsx": "^3.2.0", "mdast-util-to-hast": "^13.2.0", "next-mdx-remote-client": "^1.0.3", "rehype-katex": "^7.0.1", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-smartypants": "^3.0.2", "shiki": "^3.11.0", "unified": "^11.0.0", "unist-util-visit": "^5.0.0" }, "peerDependencies": { "@radix-ui/react-popover": "^1.1.15", "react": "^18.3.1", "react-dom": "^18.3.1" } }, "sha512-YwvZZ/2CJG+MT2sWyKOXAEk/nS5lzq3ACUerqD8xtPtnMMCgqoSQ/Y8pA32OfTAHFMsiIwqI3NNWYFLEftyrWg=="],
"@mintlify/models": ["@mintlify/models@0.0.229", "", { "dependencies": { "axios": "^1.8.3", "openapi-types": "^12.0.0" } }, "sha512-1P3R6dQFNzjTbmVDCQf/vAGFGOEUdUv6sCaJAmZCNWY2mhwgvDU/Oa2YLiNmVrAqnWDH1Pkz5nq+i7gClrdXgA=="],
"@mintlify/models": ["@mintlify/models@0.0.240", "", { "dependencies": { "axios": "^1.8.3", "openapi-types": "^12.0.0" } }, "sha512-9j8UfcYw+pD5D5qhB/iPywSpnB/sgwft+mUc08mWS+Tol19smROa901Myy0yLT0NZPfoZVfSSLp8J5LTloljpA=="],
"@mintlify/openapi-parser": ["@mintlify/openapi-parser@0.0.7", "", { "dependencies": { "ajv": "^8.17.1", "ajv-draft-04": "^1.0.0", "ajv-formats": "^3.0.1", "jsonpointer": "^5.0.1", "leven": "^4.0.0", "yaml": "^2.4.5" } }, "sha512-3ecbkzPbsnkKVZJypVL0H5pCTR7a4iLv4cP7zbffzAwy+vpH70JmPxNVpPPP62yLrdZlfNcMxu5xKeT7fllgMg=="],
"@mintlify/openapi-parser": ["@mintlify/openapi-parser@0.0.8", "", { "dependencies": { "ajv": "^8.17.1", "ajv-draft-04": "^1.0.0", "ajv-formats": "^3.0.1", "jsonpointer": "^5.0.1", "leven": "^4.0.0", "yaml": "^2.4.5" } }, "sha512-9MBRq9lS4l4HITYCrqCL7T61MOb20q9IdU7HWhqYMNMM1jGO1nHjXasFy61yZ8V6gMZyyKQARGVoZ0ZrYN48Og=="],
"@mintlify/prebuild": ["@mintlify/prebuild@1.0.661", "", { "dependencies": { "@mintlify/common": "1.0.537", "@mintlify/openapi-parser": "^0.0.7", "@mintlify/scraping": "4.0.396", "@mintlify/validation": "0.1.471", "chalk": "^5.3.0", "favicons": "^7.2.0", "fs-extra": "^11.1.0", "gray-matter": "^4.0.3", "js-yaml": "^4.1.0", "mdast": "^3.0.0", "openapi-types": "^12.0.0", "unist-util-visit": "^4.1.1" } }, "sha512-hcYLxhf53RV6hecJLIEdG7ajQuTtDj3vuoueeLmhcVXEDYkvKKa36EOk9/olLUDvjqsENnK601NmdmHPd80pJA=="],
"@mintlify/prebuild": ["@mintlify/prebuild@1.0.736", "", { "dependencies": { "@mintlify/common": "1.0.607", "@mintlify/openapi-parser": "^0.0.8", "@mintlify/scraping": "4.0.467", "@mintlify/validation": "0.1.521", "chalk": "^5.3.0", "favicons": "^7.2.0", "fs-extra": "^11.1.0", "gray-matter": "^4.0.3", "js-yaml": "^4.1.0", "openapi-types": "^12.0.0", "sharp": "^0.33.1", "sharp-ico": "^0.1.5", "unist-util-visit": "^4.1.1", "uuid": "^11.1.0" } }, "sha512-ih38FjriVUpujDqrc6v9Yt4H1eC4ByGL5MVDSWy++RIkjRZLyPULnEOh1IcGqJ9zSYJOPtPgoIsTIta71/yZsw=="],
"@mintlify/previewing": ["@mintlify/previewing@4.0.710", "", { "dependencies": { "@mintlify/common": "1.0.537", "@mintlify/prebuild": "1.0.661", "@mintlify/validation": "0.1.471", "better-opn": "^3.0.2", "chalk": "^5.1.0", "chokidar": "^3.5.3", "express": "^4.18.2", "fs-extra": "^11.1.0", "got": "^13.0.0", "gray-matter": "^4.0.3", "ink": "^6.0.1", "ink-spinner": "^5.0.0", "is-online": "^10.0.0", "js-yaml": "^4.1.0", "mdast": "^3.0.0", "openapi-types": "^12.0.0", "react": "^19.1.0", "socket.io": "^4.7.2", "tar": "^6.1.15", "unist-util-visit": "^4.1.1", "yargs": "^17.6.0" } }, "sha512-3SyO58i7kmR4W+UCcP9gq/wTKsJ0Vs+pudFnfJt5Qk1QIMTXbZGjC/ojaYDbGqSt+VOmIPwbGchQzZrAp1aXbA=="],
"@mintlify/previewing": ["@mintlify/previewing@4.0.786", "", { "dependencies": { "@mintlify/common": "1.0.607", "@mintlify/prebuild": "1.0.736", "@mintlify/validation": "0.1.521", "better-opn": "^3.0.2", "chalk": "^5.1.0", "chokidar": "^3.5.3", "express": "^4.18.2", "fs-extra": "^11.1.0", "got": "^13.0.0", "gray-matter": "^4.0.3", "ink": "^6.0.1", "ink-spinner": "^5.0.0", "is-online": "^10.0.0", "js-yaml": "^4.1.0", "openapi-types": "^12.0.0", "react": "^19.1.0", "socket.io": "^4.7.2", "tar": "^6.1.15", "unist-util-visit": "^4.1.1", "yargs": "^17.6.0" } }, "sha512-OPVm66QdNdNjDcyv2iWA3/fJUfyBGvm6XKiORDhlW+dqiFX5aTDLEithsclmKz5r2JEpIqIJNSeiudpY8uGHAg=="],
"@mintlify/scraping": ["@mintlify/scraping@4.0.317", "", { "dependencies": { "@mintlify/common": "1.0.461", "@mintlify/openapi-parser": "^0.0.7", "fs-extra": "^11.1.1", "hast-util-to-mdast": "^10.1.0", "js-yaml": "^4.1.0", "mdast-util-mdx-jsx": "^3.1.3", "neotraverse": "^0.6.18", "puppeteer": "^22.14.0", "rehype-parse": "^9.0.0", "remark-gfm": "^4.0.0", "remark-mdx": "^3.0.1", "remark-parse": "^11.0.0", "remark-stringify": "^11.0.0", "unified": "^11.0.5", "unist-util-visit": "^5.0.0", "yargs": "^17.6.0", "zod": "^3.20.6" }, "bin": { "mintlify-scrape": "bin/cli.js" } }, "sha512-WVgReuvckQMgWkbR8JrGQp5l1cs4WB+V8+ZWjQHhCmyjp+Kv+2zVKs9dw2/yiWjZYiYytu6if7Dise9sbLuMbQ=="],
"@mintlify/scraping": ["@mintlify/scraping@4.0.467", "", { "dependencies": { "@mintlify/common": "1.0.607", "@mintlify/openapi-parser": "^0.0.8", "fs-extra": "^11.1.1", "hast-util-to-mdast": "^10.1.0", "js-yaml": "^4.1.0", "mdast-util-mdx-jsx": "^3.1.3", "neotraverse": "^0.6.18", "puppeteer": "^22.14.0", "rehype-parse": "^9.0.0", "remark-gfm": "^4.0.0", "remark-mdx": "^3.0.1", "remark-parse": "^11.0.0", "remark-stringify": "^11.0.0", "unified": "^11.0.5", "unist-util-visit": "^5.0.0", "yargs": "^17.6.0", "zod": "^3.20.6" }, "bin": { "mintlify-scrape": "bin/cli.js" } }, "sha512-UnanSRzG5gDef9NFlSO6F00JznCAEEb1onbuidfzQ9sBPzG/a+g+0K4Z6VdbeNCFKmirx2t1qm1gujkh8XIfog=="],
"@mintlify/validation": ["@mintlify/validation@0.1.471", "", { "dependencies": { "@mintlify/models": "0.0.229", "arktype": "^2.1.20", "lcm": "^0.0.3", "lodash": "^4.17.21", "openapi-types": "^12.0.0", "zod": "^3.20.6", "zod-to-json-schema": "^3.20.3" } }, "sha512-lf4zp9sJspXmDA9HH9VaJfK4ll+BaaH9XxuU2SVNuploKjRKmpHYFfN9YI42pA2bda/X32rkqDZSRI+JHdQcNg=="],
"@mintlify/validation": ["@mintlify/validation@0.1.521", "", { "dependencies": { "@mintlify/mdx": "^3.0.1", "@mintlify/models": "0.0.240", "arktype": "^2.1.20", "js-yaml": "^4.1.0", "lcm": "^0.0.3", "lodash": "^4.17.21", "object-hash": "^3.0.0", "openapi-types": "^12.0.0", "uuid": "^11.1.0", "zod": "^3.20.6", "zod-to-json-schema": "^3.20.3" } }, "sha512-8icZULy+5CXGucFNo7mTWEgzif/73Lvbb8pNuo7MBL81kbvixPWKX3j5TiSLkVCUjwUGIglr9IKc9+RXxwN09A=="],
"@nodelib/fs.scandir": ["@nodelib/fs.scandir@2.1.5", "", { "dependencies": { "@nodelib/fs.stat": "2.0.5", "run-parallel": "^1.1.9" } }, "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g=="],
@ -203,21 +209,21 @@
"@radix-ui/rect": ["@radix-ui/rect@1.1.1", "", {}, "sha512-HPwpGIzkl28mWyZqG52jiqDJ12waP11Pa1lGoiyUkIEuMLBP0oeK/C89esbXrxsky5we7dfd8U58nm0SgAWpVw=="],
"@shikijs/core": ["@shikijs/core@3.8.1", "", { "dependencies": { "@shikijs/types": "3.8.1", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-uTSXzUBQ/IgFcUa6gmGShCHr4tMdR3pxUiiWKDm8pd42UKJdYhkAYsAmHX5mTwybQ5VyGDgTjW4qKSsRvGSang=="],
"@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.8.1", "", { "dependencies": { "@shikijs/types": "3.8.1", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.3" } }, "sha512-rZRp3BM1llrHkuBPAdYAzjlF7OqlM0rm/7EWASeCcY7cRYZIrOnGIHE9qsLz5TCjGefxBFnwgIECzBs2vmOyKA=="],
"@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.3" } }, "sha512-Ty7xv32XCp8u0eQt8rItpMs6rU9Ki6LJ1dQOW3V/56PKDcpvfHPnYFbsx5FFUP2Yim34m/UkazidamMNVR4vKg=="],
"@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.8.1", "", { "dependencies": { "@shikijs/types": "3.8.1", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-KGQJZHlNY7c656qPFEQpIoqOuC4LrxjyNndRdzk5WKB/Ie87+NJCF1xo9KkOUxwxylk7rT6nhlZyTGTC4fCe1g=="],
"@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-O42rBGr4UDSlhT2ZFMxqM7QzIU+IcpoTMzb3W7AlziI1ZF7R8eS2M0yt5Ry35nnnTX/LTLXFPUjRFCIW+Operg=="],
"@shikijs/langs": ["@shikijs/langs@3.8.1", "", { "dependencies": { "@shikijs/types": "3.8.1" } }, "sha512-TjOFg2Wp1w07oKnXjs0AUMb4kJvujML+fJ1C5cmEj45lhjbUXtziT1x2bPQb9Db6kmPhkG5NI2tgYW1/DzhUuQ=="],
"@shikijs/langs": ["@shikijs/langs@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-672c3WAETDYHwrRP0yLy3W1QYB89Hbpj+pO4KhxK6FzIrDI2FoEXNiNCut6BQmEApYLfuYfpgOZaqbY+E9b8wQ=="],
"@shikijs/themes": ["@shikijs/themes@3.8.1", "", { "dependencies": { "@shikijs/types": "3.8.1" } }, "sha512-Vu3t3BBLifc0GB0UPg2Pox1naTemrrvyZv2lkiSw3QayVV60me1ujFQwPZGgUTmwXl1yhCPW8Lieesm0CYruLQ=="],
"@shikijs/themes": ["@shikijs/themes@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-Vxw1Nm1/Od8jyA7QuAenaV78BG2nSr3/gCGdBkLpfLscddCkzkL36Q5b67SrLLfvAJTOUzW39x4FHVCFriPVgg=="],
"@shikijs/transformers": ["@shikijs/transformers@3.8.1", "", { "dependencies": { "@shikijs/core": "3.8.1", "@shikijs/types": "3.8.1" } }, "sha512-nmTyFfBrhJk6HJi118jes0wuWdfKXeVUq1Nq+hm8h6wbk1KUfvtg+LY/uDfxZD2VDItHO3QoINIs3NtoKBmgxw=="],
"@shikijs/transformers": ["@shikijs/transformers@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/types": "3.13.0" } }, "sha512-833lcuVzcRiG+fXvgslWsM2f4gHpjEgui1ipIknSizRuTgMkNZupiXE5/TVJ6eSYfhNBFhBZKkReKWO2GgYmqA=="],
"@shikijs/twoslash": ["@shikijs/twoslash@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/types": "3.13.0", "twoslash": "^0.3.4" }, "peerDependencies": { "typescript": ">=5.5.0" } }, "sha512-OmNKNoZ8Hevt4VKQHfJL+hrsrqLSnW/Nz7RMutuBqXBCIYZWk80HnF9pcXEwRmy9MN0MGRmZCW2rDDP8K7Bxkw=="],
"@shikijs/types": ["@shikijs/types@3.8.1", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-5C39Q8/8r1I26suLh+5TPk1DTrbY/kn3IdWA5HdizR0FhlhD05zx5nKCqhzSfDHH3p4S0ZefxWd77DLV+8FhGg=="],
"@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@shikijs/vscode-textmate": ["@shikijs/vscode-textmate@10.0.2", "", {}, "sha512-83yeghZ2xxin3Nj8z1NMd/NCuca+gsYXswywDy5bHvwlWL8tpTQmzGeUuHd9FC3E/SBEMvzJRwWEOz5gGes9Qg=="],
@ -315,6 +321,8 @@
"address": ["address@1.2.2", "", {}, "sha512-4B/qKCfeE/ODUaAUpSwfzazo5x29WD4r3vXiWsB7I2mSDAihwEqKO+g8GELZUQSSAo5e1XTYh3ZVfLyxBc12nA=="],
"adm-zip": ["adm-zip@0.5.16", "", {}, "sha512-TGw5yVi4saajsSEgz25grObGHEUaDrniwvA2qwSC060KfqGPdglhvPMA2lPIoxs3PQIItj2iag35fONcQqgUaQ=="],
"agent-base": ["agent-base@7.1.4", "", {}, "sha512-MnA+YT8fwfJPgBx3m60MNqakm30XOkyIoH1y6huTQvC0PwZG7ki8NacLBcrPbNoo8vEZy7Jpuk7+jMO+CUovTQ=="],
"agentkeepalive": ["agentkeepalive@4.6.0", "", { "dependencies": { "humanize-ms": "^1.2.1" } }, "sha512-kja8j7PjmncONqaTsB8fQ+wE2mSU2DJ9D4XKoJ5PFWIdRMa6SLSN1ff4mOr4jCbfRSsxR4keIiySJU0N9T5hIQ=="],
@ -345,7 +353,9 @@
"aria-hidden": ["aria-hidden@1.2.6", "", { "dependencies": { "tslib": "^2.0.0" } }, "sha512-ik3ZgC9dY/lYVVM++OISsaYDeg1tb0VtP5uL3ouh1koGOaUMDPpbFIei4JkFimWUFPn90sbMNMXQAIVOlnYKJA=="],
"arktype": ["arktype@2.1.22", "", { "dependencies": { "@ark/schema": "0.49.0", "@ark/util": "0.49.0" } }, "sha512-xdzl6WcAhrdahvRRnXaNwsipCgHuNoLobRqhiP8RjnfL9Gp947abGlo68GAIyLtxbD+MLzNyH2YR4kEqioMmYQ=="],
"arkregex": ["arkregex@0.0.3", "", { "dependencies": { "@ark/util": "0.55.0" } }, "sha512-bU21QJOJEFJK+BPNgv+5bVXkvRxyAvgnon75D92newgHxkBJTgiFwQxusyViYyJkETsddPlHyspshDQcCzmkNg=="],
"arktype": ["arktype@2.1.27", "", { "dependencies": { "@ark/schema": "0.55.0", "@ark/util": "0.55.0", "arkregex": "0.0.3" } }, "sha512-enctOHxI4SULBv/TDtCVi5M8oLd4J5SVlPUblXDzSsOYQNMzmVbUosGBnJuZDKmFlN5Ie0/QVEuTE+Z5X1UhsQ=="],
"array-buffer-byte-length": ["array-buffer-byte-length@1.0.2", "", { "dependencies": { "call-bound": "^1.0.3", "is-array-buffer": "^3.0.5" } }, "sha512-LHE+8BuR7RYGDKvnrmcuSq3tDcKv9OFEXQt/HpbZhY7V6h0zlUXutnAD82GiFx9rdieCMjkvtcsPqBwgUl1Iiw=="],
@ -425,7 +435,7 @@
"ccount": ["ccount@2.0.1", "", {}, "sha512-eyrF0jiFpY+3drT6383f1qhkbGsLSifNAjA61IUjZjmLCWjItY6LB9ft9YhoDgwfmclB2zhu51Lc7+95b8NRAg=="],
"chalk": ["chalk@5.4.1", "", {}, "sha512-zgVZuo2WcZgfUEmsn6eO3kINexW8RAE4maiQ8QNs8CtpPCSyMiYsULR3HQYkm3w8FIA3SberyMJMSldGsW+U3w=="],
"chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
"character-entities": ["character-entities@2.0.2", "", {}, "sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ=="],
@ -435,7 +445,7 @@
"character-reference-invalid": ["character-reference-invalid@2.0.1", "", {}, "sha512-iBZ4F4wRbyORVsu0jPV7gXkOsGYjGHPmAyv+HiHG8gi5PtC9KI2j1+v8/tlibRvjoWX027ypmG/n0HtO5t7unw=="],
"chardet": ["chardet@0.7.0", "", {}, "sha512-mT8iDcrh03qDGRRmoA2hmBJnxpllMR+0/0qlzjqZES6NdiWDcZkCNAk4rPFZ9Q85r27unkiNNg8ZOiwZXBHwcA=="],
"chardet": ["chardet@2.1.1", "", {}, "sha512-PsezH1rqdV9VvyNhxxOW32/d75r01NY7TQCmOqomRo15ZSOKbpTFVsfjghxo6JloQUCGnH4k1LGu0R4yCLlWQQ=="],
"chokidar": ["chokidar@3.6.0", "", { "dependencies": { "anymatch": "~3.1.2", "braces": "~3.0.2", "glob-parent": "~5.1.2", "is-binary-path": "~2.1.0", "is-glob": "~4.0.1", "normalize-path": "~3.0.0", "readdirp": "~3.6.0" }, "optionalDependencies": { "fsevents": "~2.3.2" } }, "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw=="],
@ -463,6 +473,8 @@
"color": ["color@4.2.3", "", { "dependencies": { "color-convert": "^2.0.1", "color-string": "^1.9.0" } }, "sha512-1rXeuUUiGGrykh+CeBdu5Ie7OJwinCgQY0bc7GCRxy5xVHy+moaqkpL/jqQq0MtQOeYcrqEz4abc5f0KtU7W4A=="],
"color-blend": ["color-blend@4.0.0", "", {}, "sha512-fYODTHhI/NG+B5GnzvuL3kiFrK/UnkUezWFTgEPBTY5V+kpyfAn95Vn9sJeeCX6omrCOdxnqCL3CvH+6sXtIbw=="],
"color-convert": ["color-convert@2.0.1", "", { "dependencies": { "color-name": "~1.1.4" } }, "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ=="],
"color-name": ["color-name@1.1.4", "", {}, "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA=="],
@ -507,6 +519,10 @@
"debug": ["debug@4.4.1", "", { "dependencies": { "ms": "^2.1.3" } }, "sha512-KcKCqiftBJcZr++7ykoDIEwSa3XWowTfNPo92BYxjXiyYEVrUQh2aLyhxBCwww+heortUFxEJYcRzosstTEBYQ=="],
"decode-bmp": ["decode-bmp@0.2.1", "", { "dependencies": { "@canvas/image-data": "^1.0.0", "to-data-view": "^1.1.0" } }, "sha512-NiOaGe+GN0KJqi2STf24hfMkFitDUaIoUU3eKvP/wAbLe8o6FuW5n/x7MHPR0HKvBokp6MQY/j7w8lewEeVCIA=="],
"decode-ico": ["decode-ico@0.4.1", "", { "dependencies": { "@canvas/image-data": "^1.0.0", "decode-bmp": "^0.2.0", "to-data-view": "^1.1.0" } }, "sha512-69NZfbKIzux1vBOd31al3XnMnH+2mqDhEgLdpygErm4d60N+UwA5Sq5WFjmEDQzumgB9fElojGwWG0vybVfFmA=="],
"decode-named-character-reference": ["decode-named-character-reference@1.2.0", "", { "dependencies": { "character-entities": "^2.0.0" } }, "sha512-c6fcElNV6ShtZXmsgNgFFV5tVX2PaV4g+MOAkb8eXHvn6sryJBrZa9r0zV6+dtTyoCKxtDy5tyQ5ZwQuidtd+Q=="],
"decompress-response": ["decompress-response@6.0.0", "", { "dependencies": { "mimic-response": "^3.1.0" } }, "sha512-aW35yZM6Bb/4oJlZncMH2LCoZtJXTRxES17vE3hoRiowU2kWHaJKFkSBDnDR+cm9J+9QhXmREyIfv0pji9ejCQ=="],
@ -769,6 +785,8 @@
"hastscript": ["hastscript@9.0.1", "", { "dependencies": { "@types/hast": "^3.0.0", "comma-separated-tokens": "^2.0.0", "hast-util-parse-selector": "^4.0.0", "property-information": "^7.0.0", "space-separated-tokens": "^2.0.0" } }, "sha512-g7df9rMFX/SPi34tyGCyUBREQoKkapwdY/T04Qn9TDWfHhAYt4/I0gMVirzK5wEzeUqIjEB+LXC/ypb7Aqno5w=="],
"hex-rgb": ["hex-rgb@5.0.0", "", {}, "sha512-NQO+lgVUCtHxZ792FodgW0zflK+ozS9X9dwGp9XvvmPlH7pyxd588cn24TD3rmPm/N0AIRXF10Otah8yKqGw4w=="],
"honcho-ai": ["honcho-ai@0.0.11", "", { "dependencies": { "@types/node": "^18.11.18", "@types/node-fetch": "^2.6.4", "abort-controller": "^3.0.0", "agentkeepalive": "^4.2.1", "form-data-encoder": "1.7.2", "formdata-node": "^4.3.2", "node-fetch": "^2.6.7" } }, "sha512-SUl/PnMldTCz8G4S8faP00M2iFd9qWDkI5U8w0FQ7OC6SgKzTf1nJ/j3gyzctzR2IZ6LrOz/2d5OwO4f/PCMww=="],
"html-void-elements": ["html-void-elements@3.0.0", "", {}, "sha512-bEqo66MRXsUGxWHV5IP0PUiAWwoEjba4VCzg0LjFJBpchPaTfyfCKTG6bc5F8ucKec3q5y6qOdGyYTSBEvhCrg=="],
@ -785,7 +803,9 @@
"humanize-ms": ["humanize-ms@1.2.1", "", { "dependencies": { "ms": "^2.0.0" } }, "sha512-Fl70vYtsAFb/C06PTS9dZBo7ihau+Tu/DNCk/OyHhea07S+aeMWpFFkUaXRa8fI+ScZbEI8dfSxwY7gxZ9SAVQ=="],
"iconv-lite": ["iconv-lite@0.4.24", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3" } }, "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA=="],
"ico-endec": ["ico-endec@0.1.6", "", {}, "sha512-ZdLU38ZoED3g1j3iEyzcQj+wAkY2xfWNkymszfJPoxucIUhK7NayQ+/C4Kv0nDFMIsbtbEHldv3V8PU494/ueQ=="],
"iconv-lite": ["iconv-lite@0.7.0", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3.0.0" } }, "sha512-cf6L2Ds3h57VVmkZe+Pn+5APsT7FpqJtEhhieDCvrE2MK5Qk9MyffgQyuxQTm6BChfeZNtcOLHp9IcWRVcIcBQ=="],
"ieee754": ["ieee754@1.2.1", "", {}, "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA=="],
@ -819,7 +839,7 @@
"is-array-buffer": ["is-array-buffer@3.0.5", "", { "dependencies": { "call-bind": "^1.0.8", "call-bound": "^1.0.3", "get-intrinsic": "^1.2.6" } }, "sha512-DDfANUiiG2wC1qawP66qlTugJeL5HyzMpfr8lLK+jMQirGzNod0B12cFB/9q838Ru27sBwfw78/rdoU7RERz6A=="],
"is-arrayish": ["is-arrayish@0.2.1", "", {}, "sha512-zz06S8t0ozoDXMG+ube26zeCTNXcKIPJZJi8hBrF4idCLms4CG9QtK7qBl1boi5ODzFpjswb5JPmHCbMpjaYzg=="],
"is-arrayish": ["is-arrayish@0.3.2", "", {}, "sha512-eVRqCvVlZbuw3GrM63ovNSNAeA1K16kaR/LRY/92w0zxQ5/1YzwblUX652i4Xs9RwAGjW9d9y6X88t8OaAJfWQ=="],
"is-async-function": ["is-async-function@2.1.1", "", { "dependencies": { "async-function": "^1.0.0", "call-bound": "^1.0.3", "get-proto": "^1.0.1", "has-tostringtag": "^1.0.2", "safe-regex-test": "^1.1.0" } }, "sha512-9dgM/cZBnNvjzaMYHVoxxfPj2QXt22Ev7SuuPrs+xav0ukGB0S6d4ydZdEiM48kLx5kDV+QBPrpVnFyefL8kkQ=="],
@ -953,8 +973,6 @@
"math-intrinsics": ["math-intrinsics@1.1.0", "", {}, "sha512-/IXtbwEk5HTPyEwyKX6hGkYXxM9nbj64B+ilVJnC/R6B0pH5G4V3b0pVbL7DBj4tkhBAppbQUlf6F6Xl9LHu1g=="],
"mdast": ["mdast@3.0.0", "", {}, "sha512-xySmf8g4fPKMeC07jXGz971EkLbWAJ83s4US2Tj9lEdnZ142UP5grN73H1Xd3HzrdbU5o9GYYP/y8F9ZSwLE9g=="],
"mdast-util-find-and-replace": ["mdast-util-find-and-replace@3.0.2", "", { "dependencies": { "@types/mdast": "^4.0.0", "escape-string-regexp": "^5.0.0", "unist-util-is": "^6.0.0", "unist-util-visit-parents": "^6.0.0" } }, "sha512-Tmd1Vg/m3Xz43afeNxDIhWRtFZgM2VLyaf4vSTYwudTyeuTneoL3qtWMA5jeLyz/O1vDJmmV4QuScFCA2tBPwg=="],
"mdast-util-from-markdown": ["mdast-util-from-markdown@2.0.2", "", { "dependencies": { "@types/mdast": "^4.0.0", "@types/unist": "^3.0.0", "decode-named-character-reference": "^1.0.0", "devlop": "^1.0.0", "mdast-util-to-string": "^4.0.0", "micromark": "^4.0.0", "micromark-util-decode-numeric-character-reference": "^2.0.0", "micromark-util-decode-string": "^2.0.0", "micromark-util-normalize-identifier": "^2.0.0", "micromark-util-symbol": "^2.0.0", "micromark-util-types": "^2.0.0", "unist-util-stringify-position": "^4.0.0" } }, "sha512-uZhTV/8NBuw0WHkPTrCqDOl0zVe1BIng5ZtHoDk49ME1qqcjYmmLmOf0gELgcRMxN4w2iuIeVso5/6QymSrgmA=="],
@ -1091,7 +1109,7 @@
"minizlib": ["minizlib@2.1.2", "", { "dependencies": { "minipass": "^3.0.0", "yallist": "^4.0.0" } }, "sha512-bAxsR8BVfj60DWXHE3u30oHzfl4G7khkSuPW+qvpd7jFRHm7dLxOjUk1EHACJ/hxLY8phGJ0YhYHZo7jil7Qdg=="],
"mint": ["mint@4.2.123", "", { "dependencies": { "@mintlify/cli": "4.0.727" }, "bin": { "mint": "index.js", "mintlify": "index.js" } }, "sha512-md52nrIkMZdtFwWVxpa1vu9msyBMtDePRuMFsTOcdWqYq11JO07L4lyOTVcMe6IPtRbvhjbbKiWihKB2xLZecQ=="],
"mint": ["mint@4.2.204", "", { "dependencies": { "@mintlify/cli": "4.0.808" }, "bin": { "mint": "index.js", "mintlify": "index.js" } }, "sha512-qOfwgnDKmhzAV+y1b787P1Lv2vYIrurvZs0Q7Kwx7zpJ+uiXjzEhYAzlm0Rj/SITlhwllJrv30axEaSq37sYMA=="],
"mitt": ["mitt@3.0.1", "", {}, "sha512-vKivATfr97l2/QBCYAkXYDbrIWPM2IIKEl7YPhjCvKlG3kE2gm+uBo6nEXK3M5/Ffh/FLpKExzOQ3JJoJGFKBw=="],
@ -1373,11 +1391,13 @@
"sharp": ["sharp@0.33.5", "", { "dependencies": { "color": "^4.2.3", "detect-libc": "^2.0.3", "semver": "^7.6.3" }, "optionalDependencies": { "@img/sharp-darwin-arm64": "0.33.5", "@img/sharp-darwin-x64": "0.33.5", "@img/sharp-libvips-darwin-arm64": "1.0.4", "@img/sharp-libvips-darwin-x64": "1.0.4", "@img/sharp-libvips-linux-arm": "1.0.5", "@img/sharp-libvips-linux-arm64": "1.0.4", "@img/sharp-libvips-linux-s390x": "1.0.4", "@img/sharp-libvips-linux-x64": "1.0.4", "@img/sharp-libvips-linuxmusl-arm64": "1.0.4", "@img/sharp-libvips-linuxmusl-x64": "1.0.4", "@img/sharp-linux-arm": "0.33.5", "@img/sharp-linux-arm64": "0.33.5", "@img/sharp-linux-s390x": "0.33.5", "@img/sharp-linux-x64": "0.33.5", "@img/sharp-linuxmusl-arm64": "0.33.5", "@img/sharp-linuxmusl-x64": "0.33.5", "@img/sharp-wasm32": "0.33.5", "@img/sharp-win32-ia32": "0.33.5", "@img/sharp-win32-x64": "0.33.5" } }, "sha512-haPVm1EkS9pgvHrQ/F3Xy+hgcuMV0Wm9vfIBSiwZ05k+xgb0PkBQpGsAA/oWdDobNaZTH5ppvHtzCFbnSEwHVw=="],
"sharp-ico": ["sharp-ico@0.1.5", "", { "dependencies": { "decode-ico": "*", "ico-endec": "*", "sharp": "*" } }, "sha512-a3jODQl82NPp1d5OYb0wY+oFaPk7AvyxipIowCHk7pBsZCWgbe0yAkU2OOXdoH0ENyANhyOQbs9xkAiRHcF02Q=="],
"shebang-command": ["shebang-command@2.0.0", "", { "dependencies": { "shebang-regex": "^3.0.0" } }, "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA=="],
"shebang-regex": ["shebang-regex@3.0.0", "", {}, "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A=="],
"shiki": ["shiki@3.8.1", "", { "dependencies": { "@shikijs/core": "3.8.1", "@shikijs/engine-javascript": "3.8.1", "@shikijs/engine-oniguruma": "3.8.1", "@shikijs/langs": "3.8.1", "@shikijs/themes": "3.8.1", "@shikijs/types": "3.8.1", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-+MYIyjwGPCaegbpBeFN9+oOifI8CKiKG3awI/6h3JeT85c//H2wDW/xCJEGuQ5jPqtbboKNqNy+JyX9PYpGwNg=="],
"shiki": ["shiki@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/engine-javascript": "3.13.0", "@shikijs/engine-oniguruma": "3.13.0", "@shikijs/langs": "3.13.0", "@shikijs/themes": "3.13.0", "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-aZW4l8Og16CokuCLf8CF8kq+KK2yOygapU5m3+hoGw0Mdosc6fPitjM+ujYarppj5ZIKGyPDPP1vqmQhr+5/0g=="],
"side-channel": ["side-channel@1.1.0", "", { "dependencies": { "es-errors": "^1.3.0", "object-inspect": "^1.13.3", "side-channel-list": "^1.0.0", "side-channel-map": "^1.0.1", "side-channel-weakmap": "^1.0.2" } }, "sha512-ZX99e6tRweoUXqR+VBrslhda51Nh5MTQwou5tnUDgbtyM0dBgmhEDtWGP/xbKn6hqfPRHujUNwz5fy/wbbhnpw=="],
@ -1467,6 +1487,8 @@
"tmp": ["tmp@0.0.33", "", { "dependencies": { "os-tmpdir": "~1.0.2" } }, "sha512-jRCJlojKnZ3addtTOjdIqoRuPEKBvNXcGYqzO6zWZX8KfKEpnGY5jfggJQ3EjKuu8D4bJRr0y+cYJFmYbImXGw=="],
"to-data-view": ["to-data-view@1.1.0", "", {}, "sha512-1eAdufMg6mwgmlojAx3QeMnzB/BTVp7Tbndi3U7ftcT2zCZadjxkkmLmd97zmaxWi+sgGcgWrokmpEoy0Dn0vQ=="],
"to-regex-range": ["to-regex-range@5.0.1", "", { "dependencies": { "is-number": "^7.0.0" } }, "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ=="],
"toidentifier": ["toidentifier@1.0.1", "", {}, "sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA=="],
@ -1553,6 +1575,8 @@
"utils-merge": ["utils-merge@1.0.1", "", {}, "sha512-pMZTvIkT1d+TFGvDOqodOclx0QWkkgi6Tdoa8gC8ffGAAqz9pzPTZWAybbsHHoED/ztMtkv/VoYTYyShUn81hA=="],
"uuid": ["uuid@11.1.0", "", { "bin": { "uuid": "dist/esm/bin/uuid" } }, "sha512-0/A9rDy9P7cJ+8w1c9WD9V//9Wj15Ce2MPz8Ri6032usz+NfePxx5AcN3bN+r6ZL6jEo066/yNYB3tn4pQEx+A=="],
"vary": ["vary@1.1.2", "", {}, "sha512-BNGbWLfd0eUPabhkXUVm0j8uuvREyTh5ovRa/dyow/BqAbZJyC+5fU+IzQOzmAKzYqYRAISoRhdQr3eIZ/PXqg=="],
"vfile": ["vfile@6.0.3", "", { "dependencies": { "@types/unist": "^3.0.0", "vfile-message": "^4.0.0" } }, "sha512-KzIbH/9tXat2u30jf+smMwFCsno4wHVdNmzFyL+T/L3UGqqk6JKfVqOFOZEpZSHADH1k40ab6NUIXZq422ov3Q=="],
@ -1607,7 +1631,7 @@
"yauzl": ["yauzl@2.10.0", "", { "dependencies": { "buffer-crc32": "~0.2.3", "fd-slicer": "~1.1.0" } }, "sha512-p4a9I6X6nu6IhoGmBqAcbJy1mlC4j27vEPZX9F4L4/vZT3Lyq1VkFHw/V/PUcB9Buo+DG3iHkT0x3Qya58zc3g=="],
"yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"yoctocolors-cjs": ["yoctocolors-cjs@2.1.3", "", {}, "sha512-U/PBtDf35ff0D8X8D0jfdzHYEPFxAI7jJlxZXwCSez5M3190m+QobIfh+sWDWSHMCWWJN2AWamkegn6vr6YBTw=="],
"yoga-layout": ["yoga-layout@3.2.1", "", {}, "sha512-0LPOt3AxKqMdFBZA3HBAt/t/8vIKq7VaQYbuA8WxCgung+p9TVyKRYdpvCb80HcdTN2NkbIKbhNwKUfm3tQywQ=="],
@ -1623,7 +1647,15 @@
"@asyncapi/parser/node-fetch": ["node-fetch@2.6.7", "", { "dependencies": { "whatwg-url": "^5.0.0" }, "peerDependencies": { "encoding": "^0.1.0" }, "optionalPeers": ["encoding"] }, "sha512-ZjMPFEfVx5j+y2yF35Kzx5sF7kDzxuDj6ziH4FFbOp87zKDZNx8yExJIb05OGF4Nlt9IHFIMBkRl41VdvcNdbQ=="],
"@inquirer/checkbox/ansi-escapes": ["ansi-escapes@4.3.2", "", { "dependencies": { "type-fest": "^0.21.3" } }, "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ=="],
"@inquirer/checkbox/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/checkbox/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/confirm/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/confirm/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/core/@inquirer/figures": ["@inquirer/figures@1.0.13", "", {}, "sha512-lGPVU3yO9ZNqA7vTYz26jny41lE7yoQansmqdMLBEfqaGsmdg7V3W9mK9Pvb5IL4EVZ9GnSDGMO/cJXud5dMaw=="],
"@inquirer/core/ansi-escapes": ["ansi-escapes@4.3.2", "", { "dependencies": { "type-fest": "^0.21.3" } }, "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ=="],
@ -1631,9 +1663,39 @@
"@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/password/ansi-escapes": ["ansi-escapes@4.3.2", "", { "dependencies": { "type-fest": "^0.21.3" } }, "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ=="],
"@inquirer/core/yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"@inquirer/select/ansi-escapes": ["ansi-escapes@4.3.2", "", { "dependencies": { "type-fest": "^0.21.3" } }, "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ=="],
"@inquirer/editor/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/editor/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/expand/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/expand/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/input/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/input/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/number/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/number/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/password/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/password/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/rawlist/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/rawlist/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/search/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/search/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@inquirer/select/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
"@inquirer/select/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
"@isaacs/cliui/string-width": ["string-width@5.1.2", "", { "dependencies": { "eastasianwidth": "^0.2.0", "emoji-regex": "^9.2.2", "strip-ansi": "^7.0.1" } }, "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA=="],
@ -1641,36 +1703,14 @@
"@isaacs/cliui/wrap-ansi": ["wrap-ansi@8.1.0", "", { "dependencies": { "ansi-styles": "^6.1.0", "string-width": "^5.0.1", "strip-ansi": "^7.0.1" } }, "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ=="],
"@mintlify/cli/@mintlify/common": ["@mintlify/common@1.0.537", "", { "dependencies": { "@asyncapi/parser": "^3.4.0", "@mintlify/mdx": "2.0.11", "@mintlify/models": "0.0.229", "@mintlify/openapi-parser": "^0.0.7", "@mintlify/validation": "0.1.471", "@sindresorhus/slugify": "^2.1.1", "acorn": "^8.11.2", "acorn-jsx": "^5.3.2", "estree-util-to-js": "^2.0.0", "estree-walker": "^3.0.3", "gray-matter": "^4.0.3", "hast-util-from-html": "^2.0.3", "hast-util-to-html": "^9.0.4", "hast-util-to-text": "^4.0.2", "js-yaml": "^4.1.0", "lodash": "^4.17.21", "mdast": "^3.0.0", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.0.0", "mdast-util-mdx": "^3.0.0", "mdast-util-mdx-jsx": "^3.1.3", "micromark-extension-gfm": "^3.0.0", "micromark-extension-mdx-jsx": "^3.0.1", "micromark-extension-mdxjs": "^3.0.0", "openapi-types": "^12.0.0", "postcss": "^8.5.6", "remark": "^15.0.1", "remark-frontmatter": "^5.0.0", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-mdx": "^3.1.0", "remark-stringify": "^11.0.0", "tailwindcss": "^3.4.4", "unified": "^11.0.5", "unist-builder": "^4.0.0", "unist-util-map": "^4.0.0", "unist-util-remove": "^4.0.0", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.1", "vfile": "^6.0.3" } }, "sha512-Mqm9OuXhaL0mVxkbPZHTIYNH8cVZdh9lsi5GHSGl8U7Vc+qHfv0CS+fempV1RAg6zRBjdSwD5rh43RMrPJSl/Q=="],
"@mintlify/common/@mintlify/models": ["@mintlify/models@0.0.213", "", { "dependencies": { "axios": "^1.8.3", "openapi-types": "^12.0.0" } }, "sha512-fiAVlRwUJxeI8ikpuXdcQLapHGoFHdUebIQMrZEt/UB74fMEnmzvLU01edCKLClPfw+DsceVXD7E8inWfpZSnA=="],
"@mintlify/common/@mintlify/validation": ["@mintlify/validation@0.1.424", "", { "dependencies": { "@mintlify/models": "0.0.213", "lcm": "^0.0.3", "lodash": "^4.17.21", "openapi-types": "^12.0.0", "zod": "^3.20.6", "zod-to-json-schema": "^3.20.3" } }, "sha512-mA9MoYT78KtVf34jXh01j/eqbj5agYplUYt+YYVPzGXnWM/lISlNMvQVwXekZYOPbcxATIy68Rn/Zk9ARgMWcQ=="],
"@mintlify/link-rot/@mintlify/common": ["@mintlify/common@1.0.537", "", { "dependencies": { "@asyncapi/parser": "^3.4.0", "@mintlify/mdx": "2.0.11", "@mintlify/models": "0.0.229", "@mintlify/openapi-parser": "^0.0.7", "@mintlify/validation": "0.1.471", "@sindresorhus/slugify": "^2.1.1", "acorn": "^8.11.2", "acorn-jsx": "^5.3.2", "estree-util-to-js": "^2.0.0", "estree-walker": "^3.0.3", "gray-matter": "^4.0.3", "hast-util-from-html": "^2.0.3", "hast-util-to-html": "^9.0.4", "hast-util-to-text": "^4.0.2", "js-yaml": "^4.1.0", "lodash": "^4.17.21", "mdast": "^3.0.0", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.0.0", "mdast-util-mdx": "^3.0.0", "mdast-util-mdx-jsx": "^3.1.3", "micromark-extension-gfm": "^3.0.0", "micromark-extension-mdx-jsx": "^3.0.1", "micromark-extension-mdxjs": "^3.0.0", "openapi-types": "^12.0.0", "postcss": "^8.5.6", "remark": "^15.0.1", "remark-frontmatter": "^5.0.0", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-mdx": "^3.1.0", "remark-stringify": "^11.0.0", "tailwindcss": "^3.4.4", "unified": "^11.0.5", "unist-builder": "^4.0.0", "unist-util-map": "^4.0.0", "unist-util-remove": "^4.0.0", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.1", "vfile": "^6.0.3" } }, "sha512-Mqm9OuXhaL0mVxkbPZHTIYNH8cVZdh9lsi5GHSGl8U7Vc+qHfv0CS+fempV1RAg6zRBjdSwD5rh43RMrPJSl/Q=="],
"@mintlify/link-rot/unist-util-visit": ["unist-util-visit@4.1.2", "", { "dependencies": { "@types/unist": "^2.0.0", "unist-util-is": "^5.0.0", "unist-util-visit-parents": "^5.1.1" } }, "sha512-MSd8OUGISqHdVvfY9TPhyK2VdUrPgxkUtWSuMHF6XAAFuL4LokseigBnZtPnJMu+FbynTkFNnFlyjxpVKujMRg=="],
"@mintlify/mdx/react": ["react@18.3.1", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ=="],
"@mintlify/prebuild/@mintlify/common": ["@mintlify/common@1.0.537", "", { "dependencies": { "@asyncapi/parser": "^3.4.0", "@mintlify/mdx": "2.0.11", "@mintlify/models": "0.0.229", "@mintlify/openapi-parser": "^0.0.7", "@mintlify/validation": "0.1.471", "@sindresorhus/slugify": "^2.1.1", "acorn": "^8.11.2", "acorn-jsx": "^5.3.2", "estree-util-to-js": "^2.0.0", "estree-walker": "^3.0.3", "gray-matter": "^4.0.3", "hast-util-from-html": "^2.0.3", "hast-util-to-html": "^9.0.4", "hast-util-to-text": "^4.0.2", "js-yaml": "^4.1.0", "lodash": "^4.17.21", "mdast": "^3.0.0", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.0.0", "mdast-util-mdx": "^3.0.0", "mdast-util-mdx-jsx": "^3.1.3", "micromark-extension-gfm": "^3.0.0", "micromark-extension-mdx-jsx": "^3.0.1", "micromark-extension-mdxjs": "^3.0.0", "openapi-types": "^12.0.0", "postcss": "^8.5.6", "remark": "^15.0.1", "remark-frontmatter": "^5.0.0", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-mdx": "^3.1.0", "remark-stringify": "^11.0.0", "tailwindcss": "^3.4.4", "unified": "^11.0.5", "unist-builder": "^4.0.0", "unist-util-map": "^4.0.0", "unist-util-remove": "^4.0.0", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.1", "vfile": "^6.0.3" } }, "sha512-Mqm9OuXhaL0mVxkbPZHTIYNH8cVZdh9lsi5GHSGl8U7Vc+qHfv0CS+fempV1RAg6zRBjdSwD5rh43RMrPJSl/Q=="],
"@mintlify/prebuild/@mintlify/scraping": ["@mintlify/scraping@4.0.396", "", { "dependencies": { "@mintlify/common": "1.0.537", "@mintlify/openapi-parser": "^0.0.7", "fs-extra": "^11.1.1", "hast-util-to-mdast": "^10.1.0", "js-yaml": "^4.1.0", "mdast-util-mdx-jsx": "^3.1.3", "neotraverse": "^0.6.18", "puppeteer": "^22.14.0", "rehype-parse": "^9.0.0", "remark-gfm": "^4.0.0", "remark-mdx": "^3.0.1", "remark-parse": "^11.0.0", "remark-stringify": "^11.0.0", "unified": "^11.0.5", "unist-util-visit": "^5.0.0", "yargs": "^17.6.0", "zod": "^3.20.6" }, "bin": { "mintlify-scrape": "bin/cli.js" } }, "sha512-cPavXt7yrnyGLNb5QEY8C8anPfw9Tj8TL7CVE76Ey/+l7sae9inLd2f5E3vKYfWrqyIouxGmvA+pFuenOt66aw=="],
"@mintlify/prebuild/chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
"@mintlify/prebuild/unist-util-visit": ["unist-util-visit@4.1.2", "", { "dependencies": { "@types/unist": "^2.0.0", "unist-util-is": "^5.0.0", "unist-util-visit-parents": "^5.1.1" } }, "sha512-MSd8OUGISqHdVvfY9TPhyK2VdUrPgxkUtWSuMHF6XAAFuL4LokseigBnZtPnJMu+FbynTkFNnFlyjxpVKujMRg=="],
"@mintlify/previewing/@mintlify/common": ["@mintlify/common@1.0.537", "", { "dependencies": { "@asyncapi/parser": "^3.4.0", "@mintlify/mdx": "2.0.11", "@mintlify/models": "0.0.229", "@mintlify/openapi-parser": "^0.0.7", "@mintlify/validation": "0.1.471", "@sindresorhus/slugify": "^2.1.1", "acorn": "^8.11.2", "acorn-jsx": "^5.3.2", "estree-util-to-js": "^2.0.0", "estree-walker": "^3.0.3", "gray-matter": "^4.0.3", "hast-util-from-html": "^2.0.3", "hast-util-to-html": "^9.0.4", "hast-util-to-text": "^4.0.2", "js-yaml": "^4.1.0", "lodash": "^4.17.21", "mdast": "^3.0.0", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.0.0", "mdast-util-mdx": "^3.0.0", "mdast-util-mdx-jsx": "^3.1.3", "micromark-extension-gfm": "^3.0.0", "micromark-extension-mdx-jsx": "^3.0.1", "micromark-extension-mdxjs": "^3.0.0", "openapi-types": "^12.0.0", "postcss": "^8.5.6", "remark": "^15.0.1", "remark-frontmatter": "^5.0.0", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-mdx": "^3.1.0", "remark-stringify": "^11.0.0", "tailwindcss": "^3.4.4", "unified": "^11.0.5", "unist-builder": "^4.0.0", "unist-util-map": "^4.0.0", "unist-util-remove": "^4.0.0", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.1", "vfile": "^6.0.3" } }, "sha512-Mqm9OuXhaL0mVxkbPZHTIYNH8cVZdh9lsi5GHSGl8U7Vc+qHfv0CS+fempV1RAg6zRBjdSwD5rh43RMrPJSl/Q=="],
"@mintlify/previewing/chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
"@mintlify/previewing/unist-util-visit": ["unist-util-visit@4.1.2", "", { "dependencies": { "@types/unist": "^2.0.0", "unist-util-is": "^5.0.0", "unist-util-visit-parents": "^5.1.1" } }, "sha512-MSd8OUGISqHdVvfY9TPhyK2VdUrPgxkUtWSuMHF6XAAFuL4LokseigBnZtPnJMu+FbynTkFNnFlyjxpVKujMRg=="],
"@shikijs/twoslash/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@shikijs/twoslash/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@stoplight/better-ajv-errors/leven": ["leven@3.1.0", "", {}, "sha512-qsda+H8jTaUaN/x5vzW2rzc+8Rw4TAQ/4KjB46IwK5VH+IlVeeeje/EoZRpiXvIqjFgK84QffqPztGI3VBLG1A=="],
"@stoplight/json-ref-readers/tslib": ["tslib@1.14.1", "", {}, "sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg=="],
@ -1687,6 +1727,8 @@
"body-parser/debug": ["debug@2.6.9", "", { "dependencies": { "ms": "2.0.0" } }, "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA=="],
"body-parser/iconv-lite": ["iconv-lite@0.4.24", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3" } }, "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA=="],
"chokidar/glob-parent": ["glob-parent@5.1.2", "", { "dependencies": { "is-glob": "^4.0.1" } }, "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow=="],
"chromium-bidi/zod": ["zod@3.23.8", "", {}, "sha512-XBx9AXhXktjUqnepgTiE5flcKIYWi/rme0Eaj+5Y0lftuGBq+jyRu/md4WnuxqgP1ubdpNCsYEYPxrzVHD8d6g=="],
@ -1705,10 +1747,16 @@
"engine.io/ws": ["ws@8.17.1", "", { "peerDependencies": { "bufferutil": "^4.0.1", "utf-8-validate": ">=5.0.2" }, "optionalPeers": ["bufferutil", "utf-8-validate"] }, "sha512-6XQFvXTkbfUOZOKKILFG1PDK2NDQs4azKQl26T0YS5CxqWLgXajbPZ+h4gZekJyRqFU8pvnbAbbs/3TgRPy+GQ=="],
"error-ex/is-arrayish": ["is-arrayish@0.2.1", "", {}, "sha512-zz06S8t0ozoDXMG+ube26zeCTNXcKIPJZJi8hBrF4idCLms4CG9QtK7qBl1boi5ODzFpjswb5JPmHCbMpjaYzg=="],
"escodegen/source-map": ["source-map@0.6.1", "", {}, "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g=="],
"express/debug": ["debug@2.6.9", "", { "dependencies": { "ms": "2.0.0" } }, "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA=="],
"external-editor/chardet": ["chardet@0.7.0", "", {}, "sha512-mT8iDcrh03qDGRRmoA2hmBJnxpllMR+0/0qlzjqZES6NdiWDcZkCNAk4rPFZ9Q85r27unkiNNg8ZOiwZXBHwcA=="],
"external-editor/iconv-lite": ["iconv-lite@0.4.24", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3" } }, "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA=="],
"extract-zip/get-stream": ["get-stream@5.2.0", "", { "dependencies": { "pump": "^3.0.0" } }, "sha512-nBF+F1rAZVCu/p7rjzgA+Yb4lfYXrpl7a6VmJrU8wF9I1CKvP/QwPNZHnOlwbTkY6dvtFIzFMSyQXbLoTQPRpA=="],
"fast-glob/glob-parent": ["glob-parent@5.1.2", "", { "dependencies": { "is-glob": "^4.0.1" } }, "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow=="],
@ -1727,10 +1775,10 @@
"gray-matter/js-yaml": ["js-yaml@3.14.1", "", { "dependencies": { "argparse": "^1.0.7", "esprima": "^4.0.0" }, "bin": { "js-yaml": "bin/js-yaml.js" } }, "sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g=="],
"ink/chalk": ["chalk@5.6.2", "", {}, "sha512-7NzBL0rN6fMUW+f7A6Io4h40qQlG+xGmtMxfbnH/K7TAtt8JQWVQK+6g0UXKMeVJoyV5EkkNsErQ8pVD3bLHbA=="],
"ink/string-width": ["string-width@7.2.0", "", { "dependencies": { "emoji-regex": "^10.3.0", "get-east-asian-width": "^1.0.0", "strip-ansi": "^7.1.0" } }, "sha512-tsaTIkKW9b4N+AEj+SVA+WhJzV7/zMhcSu78mLKWSk7cXMOSHsBKFWUs0fWwq8QyK3MgJBQRX6Gbi4kYbdvGkQ=="],
"inquirer/@inquirer/prompts": ["@inquirer/prompts@7.7.1", "", { "dependencies": { "@inquirer/checkbox": "^4.2.0", "@inquirer/confirm": "^5.1.14", "@inquirer/editor": "^4.2.15", "@inquirer/expand": "^4.0.17", "@inquirer/input": "^4.2.1", "@inquirer/number": "^3.0.17", "@inquirer/password": "^4.0.17", "@inquirer/rawlist": "^4.1.5", "@inquirer/search": "^3.0.17", "@inquirer/select": "^4.3.1" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-XDxPrEWeWUBy8scAXzXuFY45r/q49R0g72bUzgQXZ1DY/xEFX+ESDMkTQolcb5jRBzaNJX2W8XQl6krMNDTjaA=="],
"inquirer/ansi-escapes": ["ansi-escapes@4.3.2", "", { "dependencies": { "type-fest": "^0.21.3" } }, "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ=="],
"ip-address/sprintf-js": ["sprintf-js@1.1.3", "", {}, "sha512-Oo+0REFV59/rz3gfJNKQiBlwfHaSESl1pcGyABQsnnIfWOFt6JNj5gCog2U6MLZ//IGYD+nA8nI+mTShREReaA=="],
@ -1751,6 +1799,8 @@
"public-ip/got": ["got@12.6.1", "", { "dependencies": { "@sindresorhus/is": "^5.2.0", "@szmarczak/http-timer": "^5.0.1", "cacheable-lookup": "^7.0.0", "cacheable-request": "^10.2.8", "decompress-response": "^6.0.0", "form-data-encoder": "^2.1.2", "get-stream": "^6.0.1", "http2-wrapper": "^2.1.10", "lowercase-keys": "^3.0.0", "p-cancelable": "^3.0.0", "responselike": "^3.0.0" } }, "sha512-mThBblvlAF1d4O5oqyvN+ZxLAYwIJK7bpMxgYqPD9okW0C3qm5FFn7k811QrcuEBwaogR3ngOFoCfs6mRv7teQ=="],
"raw-body/iconv-lite": ["iconv-lite@0.4.24", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3" } }, "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA=="],
"react-dom/react": ["react@18.3.1", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ=="],
"react-dom/scheduler": ["scheduler@0.23.2", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-UOShsPwz7NrMUqhR6t0hWjFduvOzbtv7toDH1/hIrfRNIDBnnBWd0CwJTGvTpngVlmwGCdP9/Zl/tVrDqcuYzQ=="],
@ -1759,8 +1809,6 @@
"send/encodeurl": ["encodeurl@1.0.2", "", {}, "sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w=="],
"simple-swizzle/is-arrayish": ["is-arrayish@0.3.2", "", {}, "sha512-eVRqCvVlZbuw3GrM63ovNSNAeA1K16kaR/LRY/92w0zxQ5/1YzwblUX652i4Xs9RwAGjW9d9y6X88t8OaAJfWQ=="],
"slice-ansi/is-fullwidth-code-point": ["is-fullwidth-code-point@5.0.0", "", { "dependencies": { "get-east-asian-width": "^1.0.0" } }, "sha512-OVa3u9kkBbw7b8Xw5F9P+D/T9X+Z4+JruYVNapTjPYZYUznQ5YfWeFkOj606XYYW8yugTfC8Pj0hYqvi4ryAhA=="],
"socket.io/debug": ["debug@4.3.7", "", { "dependencies": { "ms": "^2.1.3" } }, "sha512-Er2nc/H7RrMXZBFCEim6TCmMk02Z8vLC2Rbi1KEBggpo0fS6l0S1nnapwmIi3yW/+GOJap1Krg4w0Hg80oCqgQ=="],
@ -1781,48 +1829,66 @@
"wrap-ansi-cjs/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@inquirer/checkbox/ansi-escapes/type-fest": ["type-fest@0.21.3", "", {}, "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w=="],
"@inquirer/checkbox/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/checkbox/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/confirm/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/confirm/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/core/ansi-escapes/type-fest": ["type-fest@0.21.3", "", {}, "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w=="],
"@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@inquirer/password/ansi-escapes/type-fest": ["type-fest@0.21.3", "", {}, "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w=="],
"@inquirer/editor/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/select/ansi-escapes/type-fest": ["type-fest@0.21.3", "", {}, "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w=="],
"@inquirer/editor/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/expand/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/expand/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/input/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/input/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/number/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/number/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/password/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/password/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/rawlist/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/rawlist/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/search/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/search/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@inquirer/select/@inquirer/core/signal-exit": ["signal-exit@4.1.0", "", {}, "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw=="],
"@inquirer/select/@inquirer/core/wrap-ansi": ["wrap-ansi@6.2.0", "", { "dependencies": { "ansi-styles": "^4.0.0", "string-width": "^4.1.0", "strip-ansi": "^6.0.0" } }, "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA=="],
"@isaacs/cliui/string-width/emoji-regex": ["emoji-regex@9.2.2", "", {}, "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg=="],
"@isaacs/cliui/strip-ansi/ansi-regex": ["ansi-regex@6.1.0", "", {}, "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx": ["@mintlify/mdx@2.0.11", "", { "dependencies": { "@shikijs/transformers": "^3.11.0", "@shikijs/twoslash": "^3.12.2", "hast-util-to-string": "^3.0.1", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.1.0", "mdast-util-mdx-jsx": "^3.2.0", "mdast-util-to-hast": "^13.2.0", "next-mdx-remote-client": "^1.0.3", "rehype-katex": "^7.0.1", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-smartypants": "^3.0.2", "shiki": "^3.11.0", "unified": "^11.0.0", "unist-util-visit": "^5.0.0" }, "peerDependencies": { "@radix-ui/react-popover": "^1.1.15", "react": "^18.3.1", "react-dom": "^18.3.1" } }, "sha512-yXwuM0BNCxNaJetPrh89c5Q2lhzU2al4QrOM3zLUdrPOdjOpPmv8ewcdiXV/qIhZDpl5Ll9k47dsz33bZjVWTg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx": ["@mintlify/mdx@2.0.11", "", { "dependencies": { "@shikijs/transformers": "^3.11.0", "@shikijs/twoslash": "^3.12.2", "hast-util-to-string": "^3.0.1", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.1.0", "mdast-util-mdx-jsx": "^3.2.0", "mdast-util-to-hast": "^13.2.0", "next-mdx-remote-client": "^1.0.3", "rehype-katex": "^7.0.1", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-smartypants": "^3.0.2", "shiki": "^3.11.0", "unified": "^11.0.0", "unist-util-visit": "^5.0.0" }, "peerDependencies": { "@radix-ui/react-popover": "^1.1.15", "react": "^18.3.1", "react-dom": "^18.3.1" } }, "sha512-yXwuM0BNCxNaJetPrh89c5Q2lhzU2al4QrOM3zLUdrPOdjOpPmv8ewcdiXV/qIhZDpl5Ll9k47dsz33bZjVWTg=="],
"@mintlify/link-rot/@mintlify/common/unist-util-visit": ["unist-util-visit@5.0.0", "", { "dependencies": { "@types/unist": "^3.0.0", "unist-util-is": "^6.0.0", "unist-util-visit-parents": "^6.0.0" } }, "sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg=="],
"@mintlify/link-rot/unist-util-visit/@types/unist": ["@types/unist@2.0.11", "", {}, "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA=="],
"@mintlify/link-rot/unist-util-visit/unist-util-is": ["unist-util-is@5.2.1", "", { "dependencies": { "@types/unist": "^2.0.0" } }, "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw=="],
"@mintlify/link-rot/unist-util-visit/unist-util-visit-parents": ["unist-util-visit-parents@5.1.3", "", { "dependencies": { "@types/unist": "^2.0.0", "unist-util-is": "^5.0.0" } }, "sha512-x6+y8g7wWMyQhL1iZfhIPhDAs7Xwbn9nRosDXl7qoPTSCy0yNxnKc+hWokFifWQIDGi154rdUqKvbCa4+1kLhg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx": ["@mintlify/mdx@2.0.11", "", { "dependencies": { "@shikijs/transformers": "^3.11.0", "@shikijs/twoslash": "^3.12.2", "hast-util-to-string": "^3.0.1", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.1.0", "mdast-util-mdx-jsx": "^3.2.0", "mdast-util-to-hast": "^13.2.0", "next-mdx-remote-client": "^1.0.3", "rehype-katex": "^7.0.1", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-smartypants": "^3.0.2", "shiki": "^3.11.0", "unified": "^11.0.0", "unist-util-visit": "^5.0.0" }, "peerDependencies": { "@radix-ui/react-popover": "^1.1.15", "react": "^18.3.1", "react-dom": "^18.3.1" } }, "sha512-yXwuM0BNCxNaJetPrh89c5Q2lhzU2al4QrOM3zLUdrPOdjOpPmv8ewcdiXV/qIhZDpl5Ll9k47dsz33bZjVWTg=="],
"@mintlify/prebuild/@mintlify/common/unist-util-visit": ["unist-util-visit@5.0.0", "", { "dependencies": { "@types/unist": "^3.0.0", "unist-util-is": "^6.0.0", "unist-util-visit-parents": "^6.0.0" } }, "sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg=="],
"@mintlify/prebuild/@mintlify/scraping/unist-util-visit": ["unist-util-visit@5.0.0", "", { "dependencies": { "@types/unist": "^3.0.0", "unist-util-is": "^6.0.0", "unist-util-visit-parents": "^6.0.0" } }, "sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg=="],
"@mintlify/prebuild/unist-util-visit/@types/unist": ["@types/unist@2.0.11", "", {}, "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA=="],
"@mintlify/prebuild/unist-util-visit/unist-util-is": ["unist-util-is@5.2.1", "", { "dependencies": { "@types/unist": "^2.0.0" } }, "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw=="],
"@mintlify/prebuild/unist-util-visit/unist-util-visit-parents": ["unist-util-visit-parents@5.1.3", "", { "dependencies": { "@types/unist": "^2.0.0", "unist-util-is": "^5.0.0" } }, "sha512-x6+y8g7wWMyQhL1iZfhIPhDAs7Xwbn9nRosDXl7qoPTSCy0yNxnKc+hWokFifWQIDGi154rdUqKvbCa4+1kLhg=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx": ["@mintlify/mdx@2.0.11", "", { "dependencies": { "@shikijs/transformers": "^3.11.0", "@shikijs/twoslash": "^3.12.2", "hast-util-to-string": "^3.0.1", "mdast-util-from-markdown": "^2.0.2", "mdast-util-gfm": "^3.1.0", "mdast-util-mdx-jsx": "^3.2.0", "mdast-util-to-hast": "^13.2.0", "next-mdx-remote-client": "^1.0.3", "rehype-katex": "^7.0.1", "remark-gfm": "^4.0.0", "remark-math": "^6.0.0", "remark-smartypants": "^3.0.2", "shiki": "^3.11.0", "unified": "^11.0.0", "unist-util-visit": "^5.0.0" }, "peerDependencies": { "@radix-ui/react-popover": "^1.1.15", "react": "^18.3.1", "react-dom": "^18.3.1" } }, "sha512-yXwuM0BNCxNaJetPrh89c5Q2lhzU2al4QrOM3zLUdrPOdjOpPmv8ewcdiXV/qIhZDpl5Ll9k47dsz33bZjVWTg=="],
"@mintlify/previewing/@mintlify/common/unist-util-visit": ["unist-util-visit@5.0.0", "", { "dependencies": { "@types/unist": "^3.0.0", "unist-util-is": "^6.0.0", "unist-util-visit-parents": "^6.0.0" } }, "sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg=="],
"@mintlify/previewing/unist-util-visit/@types/unist": ["@types/unist@2.0.11", "", {}, "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA=="],
"@mintlify/previewing/unist-util-visit/unist-util-is": ["unist-util-is@5.2.1", "", { "dependencies": { "@types/unist": "^2.0.0" } }, "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw=="],
@ -1851,6 +1917,26 @@
"ink/string-width/strip-ansi": ["strip-ansi@7.1.0", "", { "dependencies": { "ansi-regex": "^6.0.1" } }, "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ=="],
"inquirer/@inquirer/prompts/@inquirer/checkbox": ["@inquirer/checkbox@4.2.0", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-fdSw07FLJEU5vbpOPzXo5c6xmMGDzbZE2+niuDHX5N6mc6V0Ebso/q3xiHra4D73+PMsC8MJmcaZKuAAoaQsSA=="],
"inquirer/@inquirer/prompts/@inquirer/confirm": ["@inquirer/confirm@5.1.14", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-5yR4IBfe0kXe59r1YCTG8WXkUbl7Z35HK87Sw+WUyGD8wNUx7JvY7laahzeytyE1oLn74bQnL7hstctQxisQ8Q=="],
"inquirer/@inquirer/prompts/@inquirer/editor": ["@inquirer/editor@4.2.15", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "external-editor": "^3.1.0" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-wst31XT8DnGOSS4nNJDIklGKnf+8shuauVrWzgKegWUe28zfCftcWZ2vktGdzJgcylWSS2SrDnYUb6alZcwnCQ=="],
"inquirer/@inquirer/prompts/@inquirer/expand": ["@inquirer/expand@4.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-PSqy9VmJx/VbE3CT453yOfNa+PykpKg/0SYP7odez1/NWBGuDXgPhp4AeGYYKjhLn5lUUavVS/JbeYMPdH50Mw=="],
"inquirer/@inquirer/prompts/@inquirer/input": ["@inquirer/input@4.2.1", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-tVC+O1rBl0lJpoUZv4xY+WGWY8V5b0zxU1XDsMsIHYregdh7bN5X5QnIONNBAl0K765FYlAfNHS2Bhn7SSOVow=="],
"inquirer/@inquirer/prompts/@inquirer/number": ["@inquirer/number@3.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-GcvGHkyIgfZgVnnimURdOueMk0CztycfC8NZTiIY9arIAkeOgt6zG57G+7vC59Jns3UX27LMkPKnKWAOF5xEYg=="],
"inquirer/@inquirer/prompts/@inquirer/password": ["@inquirer/password@4.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-DJolTnNeZ00E1+1TW+8614F7rOJJCM4y4BAGQ3Gq6kQIG+OJ4zr3GLjIjVVJCbKsk2jmkmv6v2kQuN/vriHdZA=="],
"inquirer/@inquirer/prompts/@inquirer/rawlist": ["@inquirer/rawlist@4.1.5", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/type": "^3.0.8", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-R5qMyGJqtDdi4Ht521iAkNqyB6p2UPuZUbMifakg1sWtu24gc2Z8CJuw8rP081OckNDMgtDCuLe42Q2Kr3BolA=="],
"inquirer/@inquirer/prompts/@inquirer/search": ["@inquirer/search@3.0.17", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-CuBU4BAGFqRYors4TNCYzy9X3DpKtgIW4Boi0WNkm4Ei1hvY9acxKdBdyqzqBCEe4YxSdaQQsasJlFlUJNgojw=="],
"inquirer/@inquirer/prompts/@inquirer/select": ["@inquirer/select@4.3.1", "", { "dependencies": { "@inquirer/core": "^10.1.15", "@inquirer/figures": "^1.0.13", "@inquirer/type": "^3.0.8", "ansi-escapes": "^4.3.2", "yoctocolors-cjs": "^2.1.2" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-Gfl/5sqOF5vS/LIrSndFgOh7jgoe0UXEizDqahFRkq5aJBLegZ6WjuMh/hVEJwlFQjyLq1z9fRtvUMkb7jM1LA=="],
"inquirer/ansi-escapes/type-fest": ["type-fest@0.21.3", "", {}, "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w=="],
"is-online/got/form-data-encoder": ["form-data-encoder@2.1.4", "", {}, "sha512-yDYSgNMraqvnxiEXO4hi88+YZxaHC6QKzb5N84iRCTDeRO7ZALpir/lVmf/uXUhnwUr2O4HU8s/n6x+yNjQkHw=="],
@ -1867,98 +1953,46 @@
"wrap-ansi/strip-ansi/ansi-regex": ["ansi-regex@6.1.0", "", {}, "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/@shikijs/transformers": ["@shikijs/transformers@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/types": "3.13.0" } }, "sha512-833lcuVzcRiG+fXvgslWsM2f4gHpjEgui1ipIknSizRuTgMkNZupiXE5/TVJ6eSYfhNBFhBZKkReKWO2GgYmqA=="],
"@inquirer/checkbox/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/react": ["react@18.3.1", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ=="],
"@inquirer/confirm/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki": ["shiki@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/engine-javascript": "3.13.0", "@shikijs/engine-oniguruma": "3.13.0", "@shikijs/langs": "3.13.0", "@shikijs/themes": "3.13.0", "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-aZW4l8Og16CokuCLf8CF8kq+KK2yOygapU5m3+hoGw0Mdosc6fPitjM+ujYarppj5ZIKGyPDPP1vqmQhr+5/0g=="],
"@inquirer/editor/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/@shikijs/transformers": ["@shikijs/transformers@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/types": "3.13.0" } }, "sha512-833lcuVzcRiG+fXvgslWsM2f4gHpjEgui1ipIknSizRuTgMkNZupiXE5/TVJ6eSYfhNBFhBZKkReKWO2GgYmqA=="],
"@inquirer/expand/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/react": ["react@18.3.1", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ=="],
"@inquirer/input/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki": ["shiki@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/engine-javascript": "3.13.0", "@shikijs/engine-oniguruma": "3.13.0", "@shikijs/langs": "3.13.0", "@shikijs/themes": "3.13.0", "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-aZW4l8Og16CokuCLf8CF8kq+KK2yOygapU5m3+hoGw0Mdosc6fPitjM+ujYarppj5ZIKGyPDPP1vqmQhr+5/0g=="],
"@inquirer/number/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/@shikijs/transformers": ["@shikijs/transformers@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/types": "3.13.0" } }, "sha512-833lcuVzcRiG+fXvgslWsM2f4gHpjEgui1ipIknSizRuTgMkNZupiXE5/TVJ6eSYfhNBFhBZKkReKWO2GgYmqA=="],
"@inquirer/password/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/react": ["react@18.3.1", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ=="],
"@inquirer/rawlist/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki": ["shiki@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/engine-javascript": "3.13.0", "@shikijs/engine-oniguruma": "3.13.0", "@shikijs/langs": "3.13.0", "@shikijs/themes": "3.13.0", "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-aZW4l8Og16CokuCLf8CF8kq+KK2yOygapU5m3+hoGw0Mdosc6fPitjM+ujYarppj5ZIKGyPDPP1vqmQhr+5/0g=="],
"@inquirer/search/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/@shikijs/transformers": ["@shikijs/transformers@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/types": "3.13.0" } }, "sha512-833lcuVzcRiG+fXvgslWsM2f4gHpjEgui1ipIknSizRuTgMkNZupiXE5/TVJ6eSYfhNBFhBZKkReKWO2GgYmqA=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/react": ["react@18.3.1", "", { "dependencies": { "loose-envify": "^1.1.0" } }, "sha512-wS+hAgJShR0KhEvPJArfuPVN1+Hz1t0Y6n5jLrGQbkb4urgPE/0Rve+1kMB1v/oWgHgm4WIcV+i7F2pTVj+2iQ=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki": ["shiki@3.13.0", "", { "dependencies": { "@shikijs/core": "3.13.0", "@shikijs/engine-javascript": "3.13.0", "@shikijs/engine-oniguruma": "3.13.0", "@shikijs/langs": "3.13.0", "@shikijs/themes": "3.13.0", "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-aZW4l8Og16CokuCLf8CF8kq+KK2yOygapU5m3+hoGw0Mdosc6fPitjM+ujYarppj5ZIKGyPDPP1vqmQhr+5/0g=="],
"@inquirer/select/@inquirer/core/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
"cli-truncate/string-width/strip-ansi/ansi-regex": ["ansi-regex@6.1.0", "", {}, "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA=="],
"ink/string-width/strip-ansi/ansi-regex": ["ansi-regex@6.1.0", "", {}, "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA=="],
"inquirer/@inquirer/prompts/@inquirer/checkbox/@inquirer/figures": ["@inquirer/figures@1.0.13", "", {}, "sha512-lGPVU3yO9ZNqA7vTYz26jny41lE7yoQansmqdMLBEfqaGsmdg7V3W9mK9Pvb5IL4EVZ9GnSDGMO/cJXud5dMaw=="],
"inquirer/@inquirer/prompts/@inquirer/checkbox/yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"inquirer/@inquirer/prompts/@inquirer/expand/yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"inquirer/@inquirer/prompts/@inquirer/rawlist/yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"inquirer/@inquirer/prompts/@inquirer/search/@inquirer/figures": ["@inquirer/figures@1.0.13", "", {}, "sha512-lGPVU3yO9ZNqA7vTYz26jny41lE7yoQansmqdMLBEfqaGsmdg7V3W9mK9Pvb5IL4EVZ9GnSDGMO/cJXud5dMaw=="],
"inquirer/@inquirer/prompts/@inquirer/search/yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"inquirer/@inquirer/prompts/@inquirer/select/@inquirer/figures": ["@inquirer/figures@1.0.13", "", {}, "sha512-lGPVU3yO9ZNqA7vTYz26jny41lE7yoQansmqdMLBEfqaGsmdg7V3W9mK9Pvb5IL4EVZ9GnSDGMO/cJXud5dMaw=="],
"inquirer/@inquirer/prompts/@inquirer/select/yoctocolors-cjs": ["yoctocolors-cjs@2.1.2", "", {}, "sha512-cYVsTjKl8b+FrnidjibDWskAv7UKOfcwaVZdp/it9n1s9fU3IkgDbhdIRKCW4JDsAlECJY0ytoVPT3sK6kideA=="],
"widest-line/string-width/strip-ansi/ansi-regex": ["ansi-regex@6.1.0", "", {}, "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.3" } }, "sha512-Ty7xv32XCp8u0eQt8rItpMs6rU9Ki6LJ1dQOW3V/56PKDcpvfHPnYFbsx5FFUP2Yim34m/UkazidamMNVR4vKg=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-O42rBGr4UDSlhT2ZFMxqM7QzIU+IcpoTMzb3W7AlziI1ZF7R8eS2M0yt5Ry35nnnTX/LTLXFPUjRFCIW+Operg=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki/@shikijs/langs": ["@shikijs/langs@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-672c3WAETDYHwrRP0yLy3W1QYB89Hbpj+pO4KhxK6FzIrDI2FoEXNiNCut6BQmEApYLfuYfpgOZaqbY+E9b8wQ=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki/@shikijs/themes": ["@shikijs/themes@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-Vxw1Nm1/Od8jyA7QuAenaV78BG2nSr3/gCGdBkLpfLscddCkzkL36Q5b67SrLLfvAJTOUzW39x4FHVCFriPVgg=="],
"@mintlify/cli/@mintlify/common/@mintlify/mdx/shiki/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.3" } }, "sha512-Ty7xv32XCp8u0eQt8rItpMs6rU9Ki6LJ1dQOW3V/56PKDcpvfHPnYFbsx5FFUP2Yim34m/UkazidamMNVR4vKg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-O42rBGr4UDSlhT2ZFMxqM7QzIU+IcpoTMzb3W7AlziI1ZF7R8eS2M0yt5Ry35nnnTX/LTLXFPUjRFCIW+Operg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki/@shikijs/langs": ["@shikijs/langs@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-672c3WAETDYHwrRP0yLy3W1QYB89Hbpj+pO4KhxK6FzIrDI2FoEXNiNCut6BQmEApYLfuYfpgOZaqbY+E9b8wQ=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki/@shikijs/themes": ["@shikijs/themes@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-Vxw1Nm1/Od8jyA7QuAenaV78BG2nSr3/gCGdBkLpfLscddCkzkL36Q5b67SrLLfvAJTOUzW39x4FHVCFriPVgg=="],
"@mintlify/link-rot/@mintlify/common/@mintlify/mdx/shiki/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.3" } }, "sha512-Ty7xv32XCp8u0eQt8rItpMs6rU9Ki6LJ1dQOW3V/56PKDcpvfHPnYFbsx5FFUP2Yim34m/UkazidamMNVR4vKg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-O42rBGr4UDSlhT2ZFMxqM7QzIU+IcpoTMzb3W7AlziI1ZF7R8eS2M0yt5Ry35nnnTX/LTLXFPUjRFCIW+Operg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki/@shikijs/langs": ["@shikijs/langs@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-672c3WAETDYHwrRP0yLy3W1QYB89Hbpj+pO4KhxK6FzIrDI2FoEXNiNCut6BQmEApYLfuYfpgOZaqbY+E9b8wQ=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki/@shikijs/themes": ["@shikijs/themes@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-Vxw1Nm1/Od8jyA7QuAenaV78BG2nSr3/gCGdBkLpfLscddCkzkL36Q5b67SrLLfvAJTOUzW39x4FHVCFriPVgg=="],
"@mintlify/prebuild/@mintlify/common/@mintlify/mdx/shiki/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/@shikijs/transformers/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki/@shikijs/core": ["@shikijs/core@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-3P8rGsg2Eh2qIHekwuQjzWhKI4jV97PhvYjYUzGqjvJfqdQPz+nMlfWahU24GZAyW1FxFI1sYjyhfh5CoLmIUA=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.3" } }, "sha512-Ty7xv32XCp8u0eQt8rItpMs6rU9Ki6LJ1dQOW3V/56PKDcpvfHPnYFbsx5FFUP2Yim34m/UkazidamMNVR4vKg=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki/@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-O42rBGr4UDSlhT2ZFMxqM7QzIU+IcpoTMzb3W7AlziI1ZF7R8eS2M0yt5Ry35nnnTX/LTLXFPUjRFCIW+Operg=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki/@shikijs/langs": ["@shikijs/langs@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-672c3WAETDYHwrRP0yLy3W1QYB89Hbpj+pO4KhxK6FzIrDI2FoEXNiNCut6BQmEApYLfuYfpgOZaqbY+E9b8wQ=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki/@shikijs/themes": ["@shikijs/themes@3.13.0", "", { "dependencies": { "@shikijs/types": "3.13.0" } }, "sha512-Vxw1Nm1/Od8jyA7QuAenaV78BG2nSr3/gCGdBkLpfLscddCkzkL36Q5b67SrLLfvAJTOUzW39x4FHVCFriPVgg=="],
"@mintlify/previewing/@mintlify/common/@mintlify/mdx/shiki/@shikijs/types": ["@shikijs/types@3.13.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-oM9P+NCFri/mmQ8LoFGVfVyemm5Hi27330zuOBp0annwJdKH1kOLndw3zCtAVDehPLg9fKqoEx3Ht/wNZxolfw=="],
}
}

244
docs/docs.json
View File

@ -217,6 +217,221 @@
}
]
},
{
"version": "v2.6.0-alpha",
"api": {
"openapi": [
"openapi.json"
]
},
"tabs": [
{
"tab": "Documentation",
"groups": [
{
"group": "Introduction",
"pages": [
"v2.6.0-alpha/documentation/introduction/overview",
"v2.6.0-alpha/documentation/introduction/quickstart",
"v2.6.0-alpha/documentation/introduction/vibecoding"
]
},
{
"group": "Core Concepts",
"pages": [
"v2.6.0-alpha/documentation/core-concepts/architecture",
"v2.6.0-alpha/documentation/core-concepts/reasoning",
"v2.6.0-alpha/documentation/core-concepts/representation"
]
},
{
"group": "Features",
"pages": [
"v2.6.0-alpha/documentation/features/get-context",
"v2.6.0-alpha/documentation/features/chat",
{
"group": "Advanced",
"pages": [
"v2.6.0-alpha/documentation/features/advanced/overview",
"v2.6.0-alpha/documentation/features/advanced/queue-status",
"v2.6.0-alpha/documentation/features/advanced/toggle-reasoning",
"v2.6.0-alpha/documentation/features/advanced/representation-scopes",
"v2.6.0-alpha/documentation/features/advanced/summarizer",
"v2.6.0-alpha/documentation/features/advanced/search",
"v2.6.0-alpha/documentation/features/advanced/using-filters",
"v2.6.0-alpha/documentation/features/advanced/streaming-response"
]
}
]
},
{
"group": "Reference",
"pages": [
"v2.6.0-alpha/documentation/reference/platform",
"v2.6.0-alpha/documentation/reference/sdk"
]
}
]
},
{
"tab": "Guides",
"groups": [
{
"group": "Overview",
"pages": [
"v2.6.0-alpha/guides/overview",
"v2.6.0-alpha/guides/file-uploads",
"v2.6.0-alpha/guides/storing-data"
]
},
{
"group": "Integrations",
"pages": [
"v2.6.0-alpha/guides/integrations/crewai",
"v2.6.0-alpha/guides/integrations/langgraph",
"v2.6.0-alpha/guides/integrations/mcp"
]
},
{
"group": "Migrations",
"pages": [
"v2.6.0-alpha/guides/migrations/mem0"
]
},
{
"group": "Chatbots",
"pages": [
"v2.6.0-alpha/guides/discord",
"v2.6.0-alpha/guides/telegram"
]
}
]
},
{
"tab": "Open Source",
"groups": [
{
"group": "Self-Hosting",
"pages": [
"v2.6.0-alpha/contributing/self-hosting",
"v2.6.0-alpha/contributing/configuration"
]
},
{
"group": "Contributing",
"pages": [
"v2.6.0-alpha/contributing/guidelines",
"v2.6.0-alpha/contributing/license"
]
}
]
},
{
"tab": "API Reference",
"groups": [
{
"group": "API Documentation",
"pages": [
"v2.6.0-alpha/api-reference/introduction"
]
},
{
"group": "workspaces",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/workspaces/get-or-create-workspace",
"v2.6.0-alpha/api-reference/endpoint/workspaces/get-all-workspaces",
"v2.6.0-alpha/api-reference/endpoint/workspaces/update-workspace",
"v2.6.0-alpha/api-reference/endpoint/workspaces/delete-workspace",
"v2.6.0-alpha/api-reference/endpoint/workspaces/search-workspace",
"v2.6.0-alpha/api-reference/endpoint/workspaces/get-deriver-status",
"v2.6.0-alpha/api-reference/endpoint/workspaces/trigger-dream"
]
},
{
"group": "peers",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/peers/get-peers",
"v2.6.0-alpha/api-reference/endpoint/peers/get-or-create-peer",
"v2.6.0-alpha/api-reference/endpoint/peers/update-peer",
"v2.6.0-alpha/api-reference/endpoint/peers/get-sessions-for-peer",
"v2.6.0-alpha/api-reference/endpoint/peers/chat",
"v2.6.0-alpha/api-reference/endpoint/peers/get-working-representation",
"v2.6.0-alpha/api-reference/endpoint/peers/get-peer-card",
"v2.6.0-alpha/api-reference/endpoint/peers/set-peer-card",
"v2.6.0-alpha/api-reference/endpoint/peers/get-peer-context",
"v2.6.0-alpha/api-reference/endpoint/peers/search-peer"
]
},
{
"group": "sessions",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/sessions/get-or-create-session",
"v2.6.0-alpha/api-reference/endpoint/sessions/get-sessions",
"v2.6.0-alpha/api-reference/endpoint/sessions/update-session",
"v2.6.0-alpha/api-reference/endpoint/sessions/delete-session",
"v2.6.0-alpha/api-reference/endpoint/sessions/clone-session",
"v2.6.0-alpha/api-reference/endpoint/sessions/get-session-peers",
"v2.6.0-alpha/api-reference/endpoint/sessions/set-session-peers",
"v2.6.0-alpha/api-reference/endpoint/sessions/add-peers-to-session",
"v2.6.0-alpha/api-reference/endpoint/sessions/remove-peers-from-session",
"v2.6.0-alpha/api-reference/endpoint/sessions/get-peer-config",
"v2.6.0-alpha/api-reference/endpoint/sessions/set-peer-config",
"v2.6.0-alpha/api-reference/endpoint/sessions/get-session-context",
"v2.6.0-alpha/api-reference/endpoint/sessions/get-session-summaries",
"v2.6.0-alpha/api-reference/endpoint/sessions/search-session"
]
},
{
"group": "messages",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/messages/create-messages-for-session",
"v2.6.0-alpha/api-reference/endpoint/messages/get-messages",
"v2.6.0-alpha/api-reference/endpoint/messages/get-message",
"v2.6.0-alpha/api-reference/endpoint/messages/update-message",
"v2.6.0-alpha/api-reference/endpoint/messages/create-messages-with-file"
]
},
{
"group": "observations",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/observations/create-observations",
"v2.6.0-alpha/api-reference/endpoint/observations/list-observations",
"v2.6.0-alpha/api-reference/endpoint/observations/query-observations",
"v2.6.0-alpha/api-reference/endpoint/observations/delete-observation"
]
},
{
"group": "webhooks",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/webhooks/list-webhook-endpoints",
"v2.6.0-alpha/api-reference/endpoint/webhooks/get-or-create-webhook-endpoint",
"v2.6.0-alpha/api-reference/endpoint/webhooks/delete-webhook-endpoint",
"v2.6.0-alpha/api-reference/endpoint/webhooks/test-emit"
]
},
{
"group": "miscellaneous",
"pages": [
"v2.6.0-alpha/api-reference/endpoint/keys/create-key",
"v2.6.0-alpha/api-reference/endpoint/metrics"
]
}
]
},
{
"tab": "Changelog",
"groups": [
{
"group": "Overview",
"pages": [
"changelog/introduction",
"changelog/compatibility-guide"
]
}
]
}
]
},
{
"version": "v1.1.0",
"api": {
@ -378,26 +593,7 @@
}
]
}
],
"global": {
"anchors": [
{
"anchor": "Dashboard",
"href": "https://app.honcho.dev",
"icon": "table-columns"
},
{
"anchor": "Community",
"href": "https://discord.gg/honcho",
"icon": "discord"
},
{
"anchor": "Blog",
"href": "https://blog.plasticlabs.ai",
"icon": "newspaper"
}
]
}
]
},
"logo": {
"light": "/logo/honcho-dark.svg",
@ -411,9 +607,11 @@
},
"footer": {
"socials": {
"twitter": "https://twitter.com/plastic_labs",
"github": "https://github.com/plastic-labs",
"linkedin": "https://www.linkedin.com/company/plasticlabs"
"twitter": "https://x.com/honchodotdev",
"github": "https://github.com/plastic-labs/honcho",
"discord": "https://discord.gg/honcho",
"linkedin": "https://www.linkedin.com/company/plasticlabs",
"youtube": "https://www.youtube.com/@plasticlabs"
}
},
"integrations": {

BIN
docs/images/architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 172 KiB

BIN
docs/images/observe_config.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 235 KiB

BIN
docs/images/perspectives.jpeg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 63 KiB

BIN
docs/images/reasoning.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 323 KiB

4
docs/package.json
View File

@ -11,10 +11,10 @@
"author": "",
"license": "ISC",
"dependencies": {
"@mintlify/scraping": "^4.0.284",
"@mintlify/scraping": "^4.0.467",
"honcho-ai": "^0.0.11"
},
"devDependencies": {
"mint": "^4.2.123"
"mint": "^4.2.204"
}
}

1
docs/v2.6.0-alpha/README.md Normal file
View File

@ -0,0 +1 @@
This subdirectory contains the peer-paradigm documentation for Honcho (Honcho v2.0.0 onwards).

3
docs/v2.6.0-alpha/api-reference/endpoint/keys/create-key.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/keys
---

3
docs/v2.6.0-alpha/api-reference/endpoint/messages/create-messages-for-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/
---

3
docs/v2.6.0-alpha/api-reference/endpoint/messages/create-messages-with-file.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/upload
---

3
docs/v2.6.0-alpha/api-reference/endpoint/messages/get-message.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/{message_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/messages/get-messages.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/list
---

3
docs/v2.6.0-alpha/api-reference/endpoint/messages/update-message.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: put /v2/workspaces/{workspace_id}/sessions/{session_id}/messages/{message_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/metrics.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /metrics
---

3
docs/v2.6.0-alpha/api-reference/endpoint/observations/create-observations.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/observations
---

3
docs/v2.6.0-alpha/api-reference/endpoint/observations/delete-observation.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: delete /v2/workspaces/{workspace_id}/observations/{observation_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/observations/list-observations.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/observations/list
---

3
docs/v2.6.0-alpha/api-reference/endpoint/observations/query-observations.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/observations/query
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/chat.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/chat
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/get-or-create-peer.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/peers
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/get-peer-card.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/peers/{peer_id}/card
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/get-peer-context.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/peers/{peer_id}/context
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/get-peers.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/peers/list
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/get-sessions-for-peer.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/sessions
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/get-working-representation.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/representation
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/search-peer.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/peers/{peer_id}/search
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/set-peer-card.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: put /v2/workspaces/{workspace_id}/peers/{peer_id}/card
---

3
docs/v2.6.0-alpha/api-reference/endpoint/peers/update-peer.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: put /v2/workspaces/{workspace_id}/peers/{peer_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/add-peers-to-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/clone-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/clone
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/delete-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: delete /v2/workspaces/{workspace_id}/sessions/{session_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/get-or-create-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/get-peer-config.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/peers/{peer_id}/config
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/get-session-context.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/context
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/get-session-peers.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/get-session-summaries.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/sessions/{session_id}/summaries
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/get-sessions.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/list
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/remove-peers-from-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: delete /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/search-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/search
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/set-peer-config.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/sessions/{session_id}/peers/{peer_id}/config
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/set-session-peers.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: put /v2/workspaces/{workspace_id}/sessions/{session_id}/peers
---

3
docs/v2.6.0-alpha/api-reference/endpoint/sessions/update-session.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: put /v2/workspaces/{workspace_id}/sessions/{session_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/webhooks/delete-webhook-endpoint.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: delete /v2/workspaces/{workspace_id}/webhooks/{endpoint_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/webhooks/get-or-create-webhook-endpoint.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/webhooks
---

3
docs/v2.6.0-alpha/api-reference/endpoint/webhooks/list-webhook-endpoints.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/webhooks
---

3
docs/v2.6.0-alpha/api-reference/endpoint/webhooks/test-emit.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/webhooks/test
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/delete-workspace.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: delete /v2/workspaces/{workspace_id}
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/get-all-workspaces.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/list
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/get-deriver-status.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: get /v2/workspaces/{workspace_id}/deriver/status
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/get-or-create-workspace.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/search-workspace.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/search
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/trigger-dream.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: post /v2/workspaces/{workspace_id}/trigger_dream
---

3
docs/v2.6.0-alpha/api-reference/endpoint/workspaces/update-workspace.mdx Normal file
View File

@ -0,0 +1,3 @@
---
openapi: put /v2/workspaces/{workspace_id}
---

27
docs/v2.6.0-alpha/api-reference/introduction.mdx Normal file
View File

@ -0,0 +1,27 @@
---
title: 'Introduction'
---
This section documents all available API endpoints in the Honcho Server. Each
endpoint provides CRUD operations for our core primitives. For information
about these primitives, see
[Architecture](/v2/documentation/core-concepts/architecture).
<Warning>
We strongly recommend using our official SDKs instead of calling these APIs directly. The SDKs provide better error handling, type safety, and developer experience.
</Warning>
## Recommended approach
Use our official SDKs for the best development experience:
- [Python SDK](https://pypi.org/project/honcho-ai/)
- [TypeScript SDK](https://www.npmjs.com/package/@honcho-ai/sdk)
## When to use this API reference
This reference is primarily useful for:
- Debugging SDK behavior
- Building integrations in unsupported languages
- Understanding the underlying data structures
The endpoints pages are autogenerated and include interactive examples for testing.

638
docs/v2.6.0-alpha/contributing/configuration.mdx Normal file
View File

@ -0,0 +1,638 @@
---
title: "Configuration Guide"
description: "Complete guide to configuring Honcho for development and production"
icon: "gear"
---
Honcho uses a flexible configuration system that supports both TOML files and environment variables. Configuration values are loaded in the following priority order (highest to lowest):
1. Environment variables (always take precedence)
2. `.env` file (for local development)
3. `config.toml` file (base configuration)
4. Default values
## Recommended Configuration Approaches
### Option 1: Environment Variables Only (Production)
- Use environment variables for all configuration
- No config files needed
- Ideal for containerized deployments (Docker, Kubernetes)
- Secrets managed by your deployment platform
### Option 2: config.toml (Development/Simple Deployments)
- Use config.toml for base configuration
- Override sensitive values with environment variables
- Good for development and simple deployments
### Option 3: Hybrid Approach
- Use config.toml for non-sensitive base settings
- Use .env file for sensitive values (API keys, secrets)
- Good for development teams
### Option 4: .env Only (Local Development)
- Use .env file for all configuration
- Simple for local development
- Never commit .env files to version control
## Configuration Methods
### Using config.toml
Copy the example configuration file to get started:
```bash
cp config.toml.example config.toml
```
Then modify the values as needed. The TOML file is organized into sections:
- `[app]` - Application-level settings (log level, session limits, embedding settings, Langfuse integration, local metrics collection)
- `[db]` - Database connection and pool settings (connection URI, pool size, timeouts, connection recycling)
- `[auth]` - Authentication configuration (enable/disable auth, JWT secret)
- `[cache]` - Redis cache configuration (enable/disable caching, Redis URL, TTL settings, lock configuration for cache stampede prevention)
- `[llm]` - LLM provider API keys (Anthropic, OpenAI, Gemini, Groq, OpenAI-compatible endpoints) and general LLM settings
- `[dialectic]` - Dialectic API configuration (provider, model, query generation settings, semantic search parameters, context window size)
- `[deriver]` - Background worker settings (worker count, polling intervals, queue management) and theory of mind configuration (model, tokens, observation limits)
- `[peer_card]` - Peer card generation settings (provider, model, token limits)
- `[summary]` - Session summarization settings (frequency thresholds, provider, model, token limits for short and long summaries)
- `[dream]` - Dream processing configuration (enable/disable, thresholds, idle timeouts, dream types, LLM settings)
- `[webhook]` - Webhook configuration (webhook secret, workspace limits)
- `[metrics]` - Metrics collection settings (enable/disable metrics, namespace)
- `[sentry]` - Error tracking and monitoring settings (enable/disable, DSN, environment, sample rates)
### Using Environment Variables
All configuration values can be overridden using environment variables. The environment variable names follow this pattern:
- `{SECTION}_{KEY}` for nested settings
- Just `{KEY}` for app-level settings
Examples:
- `DB_CONNECTION_URI` → `[db].CONNECTION_URI`
- `DB_POOL_SIZE` → `[db].POOL_SIZE`
- `AUTH_JWT_SECRET` → `[auth].JWT_SECRET`
- `DIALECTIC_MODEL` → `[dialectic].MODEL`
- `LOG_LEVEL` (no section) → `[app].LOG_LEVEL`
### Configuration Priority
When a configuration value is set in multiple places, Honcho uses this priority:
1. **Environment variables** - Always take precedence
2. **.env file** - Loaded for local development
3. **config.toml** - Base configuration
4. **Default values** - Built-in defaults
This allows you to:
- Use `config.toml` for base configuration
- Override specific values with environment variables in production
- Use `.env` files for local development without modifying config.toml
### Example
If you have this in `config.toml`:
```toml
[db]
CONNECTION_URI = "postgresql://localhost/honcho_dev"
POOL_SIZE = 10
```
You can override just the connection URI in production:
```bash
export DB_CONNECTION_URI="postgresql://prod-server/honcho_prod"
```
The application will use the production connection URI while keeping the pool size from config.toml.
## Core Configuration
### Application Settings
Application-level settings control core behavior of the Honcho server including logging, session limits, message handling, and optional integrations.
**Basic Application Configuration:**
```bash
# Logging and server settings
LOG_LEVEL=INFO # DEBUG, INFO, WARNING, ERROR, CRITICAL
# Session and context limits
SESSION_OBSERVERS_LIMIT=10 # Maximum number of observers per session
GET_CONTEXT_MAX_TOKENS=100000 # Maximum tokens for context retrieval
MAX_MESSAGE_SIZE=25000 # Maximum message size in characters
# Embedding settings
EMBED_MESSAGES=true # Enable vector embeddings for messages
MAX_EMBEDDING_TOKENS=8192 # Maximum tokens per embedding
MAX_EMBEDDING_TOKENS_PER_REQUEST=300000 # Batch embedding limit
```
**Optional Integrations:**
```bash
# Langfuse integration for LLM observability
LANGFUSE_HOST=https://cloud.langfuse.com
LANGFUSE_PUBLIC_KEY=your-langfuse-public-key
# Local metrics collection
COLLECT_METRICS_LOCAL=false
LOCAL_METRICS_FILE=metrics.jsonl
```
### Database Configuration
**Required Database Settings:**
```bash
# PostgreSQL connection string (required)
DB_CONNECTION_URI=postgresql+psycopg://username:password@host:port/database
# Example for local development
DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/honcho
# Example for production
DB_CONNECTION_URI=postgresql+psycopg://honcho_user:secure_password@db.example.com:5432/honcho_prod
```
**Database Pool Settings:**
```bash
# Connection pool configuration
DB_SCHEMA=public
DB_POOL_SIZE=10
DB_MAX_OVERFLOW=20
DB_POOL_TIMEOUT=30
DB_POOL_RECYCLE=300
DB_POOL_PRE_PING=true
DB_SQL_DEBUG=false
DB_TRACING=false
```
**Docker Compose for PostgreSQL:**
```yaml
# docker-compose.yml
version: '3.8'
services:
database:
image: pgvector/pgvector:pg15
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
POSTGRES_DB: honcho
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
volumes:
postgres_data:
```
### Authentication Configuration
**JWT Authentication:**
```bash
# Enable/disable authentication
AUTH_USE_AUTH=false # Set to true for production
# JWT settings (required if AUTH_USE_AUTH is true)
AUTH_JWT_SECRET=your-super-secret-jwt-key
```
**Generate JWT Secret:**
```bash
# Generate a secure JWT secret
python scripts/generate_jwt_secret.py
```
### Cache Configuration
Honcho supports Redis caching to improve performance by caching frequently accessed data like peers, sessions, and working representations. Caching also includes lock mechanisms to prevent cache stampede scenarios.
**Redis Cache Settings:**
```bash
# Enable/disable Redis caching
CACHE_ENABLED=false # Set to true to enable caching
# Redis connection
CACHE_URL=redis://localhost:6379/0?suppress=true
# Cache namespace and TTL
CACHE_NAMESPACE=honcho # Prefix for all cache keys
CACHE_DEFAULT_TTL_SECONDS=300 # How long items stay in cache (5 minutes)
# Lock settings for preventing cache stampede
CACHE_DEFAULT_LOCK_TTL_SECONDS=5 # Lock duration when fetching from DB on cache miss
```
**When to Enable Caching:**
- High-traffic production environments
- Applications with many repeated reads of the same data
- When you need to reduce database load
**Note:** Caching requires a Redis instance. You can run Redis locally with Docker:
```bash
docker run -d -p 6379:6379 redis:latest
```
## LLM Provider Configuration
Honcho supports multiple LLM providers for different tasks. API keys are configured in the `[llm]` section, while specific features use their own configuration sections.
### API Keys
All provider API keys use the `LLM_` prefix:
```bash
# Provider API Keys
LLM_ANTHROPIC_API_KEY=your-anthropic-api-key
LLM_OPENAI_API_KEY=your-openai-api-key
LLM_GEMINI_API_KEY=your-gemini-api-key
LLM_GROQ_API_KEY=your-groq-api-key
# OpenAI-compatible endpoints
LLM_OPENAI_COMPATIBLE_API_KEY=your-api-key
LLM_OPENAI_COMPATIBLE_BASE_URL=https://your-openai-compatible-endpoint.com
```
### General LLM Settings
```bash
# Default settings for all LLM calls
LLM_DEFAULT_MAX_TOKENS=2500
# Embedding provider (used when EMBED_MESSAGES=true)
LLM_EMBEDDING_PROVIDER=openai # Options: openai, gemini
```
### Feature-Specific Model Configuration
Different features can use different providers and models:
**Dialectic API:**
The Dialectic API provides theory-of-mind informed responses by integrating long-term facts with current context.
```bash
# Main dialectic model (default: Anthropic)
DIALECTIC_PROVIDER=anthropic
DIALECTIC_MODEL=claude-sonnet-4-20250514
DIALECTIC_MAX_OUTPUT_TOKENS=2500
DIALECTIC_THINKING_BUDGET_TOKENS=1024 # Only used with Anthropic provider
DIALECTIC_CONTEXT_WINDOW_SIZE=100000 # Maximum context window tokens
# Query generation for dialectic searches
DIALECTIC_PERFORM_QUERY_GENERATION=false # Enable query generation for semantic search
DIALECTIC_QUERY_GENERATION_PROVIDER=groq
DIALECTIC_QUERY_GENERATION_MODEL=llama-3.1-8b-instant
# Semantic search settings
DIALECTIC_SEMANTIC_SEARCH_TOP_K=10 # Number of results to retrieve
DIALECTIC_SEMANTIC_SEARCH_MAX_DISTANCE=0.85 # Maximum distance for relevance
```
**Deriver (Theory of Mind):**
The Deriver is a background processing system that extracts facts from messages and builds theory-of-mind representations of peers.
```bash
# LLM settings for deriver
DERIVER_PROVIDER=google
DERIVER_MODEL=gemini-2.5-flash-lite
DERIVER_MAX_OUTPUT_TOKENS=10000
DERIVER_THINKING_BUDGET_TOKENS=1024 # Only used with Anthropic provider
DERIVER_MAX_INPUT_TOKENS=23000 # Maximum input tokens for deriver
# Worker settings
DERIVER_WORKERS=1 # Number of background worker processes
DERIVER_POLLING_SLEEP_INTERVAL_SECONDS=1.0 # Time between queue checks
DERIVER_STALE_SESSION_TIMEOUT_MINUTES=5 # Timeout for stale sessions
# Queue management
DERIVER_QUEUE_ERROR_RETENTION_SECONDS=2592000 # Keep errored items for 30 days
# Working representation settings
DERIVER_WORKING_REPRESENTATION_MAX_OBSERVATIONS=50 # Max observations stored
DERIVER_REPRESENTATION_BATCH_MAX_TOKENS=4096 # Max tokens per batch
```
**Peer Card:**
Peer cards are short, structured summaries of peer identity and characteristics.
```bash
# Enable/disable peer card generation
PEER_CARD_ENABLED=true
# LLM settings for peer card generation
PEER_CARD_PROVIDER=openai
PEER_CARD_MODEL=gpt-5-nano-2025-08-07
PEER_CARD_MAX_OUTPUT_TOKENS=4000 # Includes thinking tokens for GPT-5 models
```
**Summary Generation:**
Session summaries provide compressed context for long conversations. Honcho creates two types: short summaries (frequent) and long summaries (comprehensive).
```bash
# Enable/disable summarization
SUMMARY_ENABLED=true
# LLM settings for summary generation
SUMMARY_PROVIDER=openai
SUMMARY_MODEL=gpt-4o-mini-2024-07-18
SUMMARY_MAX_TOKENS_SHORT=1000 # Max tokens for short summaries
SUMMARY_MAX_TOKENS_LONG=4000 # Max tokens for long summaries
SUMMARY_THINKING_BUDGET_TOKENS=512 # Only used with Anthropic provider
# Summary frequency thresholds
SUMMARY_MESSAGES_PER_SHORT_SUMMARY=20 # Create short summary every N messages
SUMMARY_MESSAGES_PER_LONG_SUMMARY=60 # Create long summary every N messages
```
### Default Provider Usage
By default, Honcho uses:
- **Anthropic** (Claude) for dialectic API responses
- **Groq** for query generation (fast, cost-effective)
- **Google** (Gemini) for theory of mind derivation
- **OpenAI** (GPT) for peer cards and summarization
- **OpenAI** for embeddings (if `EMBED_MESSAGES=true`)
You only need to set the API keys for the providers you plan to use. All providers are configurable per feature.
## Additional Features Configuration
### Dream Processing
Dream processing consolidates and refines peer representations during idle periods, similar to how human memory consolidation works during sleep.
**Dream Settings:**
```bash
# Enable/disable dream processing
DREAM_ENABLED=true
# Trigger thresholds
DREAM_DOCUMENT_THRESHOLD=50 # Minimum documents to trigger a dream
DREAM_IDLE_TIMEOUT_MINUTES=60 # Minutes of inactivity before dream can start
DREAM_MIN_HOURS_BETWEEN_DREAMS=8 # Minimum hours between dreams for a peer
# Dream types to enable
DREAM_ENABLED_TYPES=["consolidate"] # Currently supported: consolidate
# LLM settings for dream processing
DREAM_PROVIDER=openai
DREAM_MODEL=gpt-4o-mini-2024-07-18
DREAM_MAX_OUTPUT_TOKENS=2000
```
### Webhook Configuration
Webhooks allow you to receive real-time notifications when events occur in Honcho (e.g., new messages, session updates).
**Webhook Settings:**
```bash
# Webhook secret for signing payloads (optional but recommended)
WEBHOOK_SECRET=your-webhook-signing-secret
# Limit on webhooks per workspace
WEBHOOK_MAX_WORKSPACE_LIMIT=10
```
### Metrics Collection
Enable metrics collection for monitoring Honcho performance and usage.
**Metrics Settings:**
```bash
# Enable/disable metrics collection
METRICS_ENABLED=false
# Namespace for metrics (used in metric names)
METRICS_NAMESPACE=honcho
```
## Monitoring Configuration
### Sentry Error Tracking
**Sentry Settings:**
```bash
# Enable/disable Sentry error tracking
SENTRY_ENABLED=false
# Sentry configuration
SENTRY_DSN=https://your-sentry-dsn@sentry.io/project-id
SENTRY_RELEASE=2.4.0 # Optional: track which version errors come from
SENTRY_ENVIRONMENT=production # Environment name (development, staging, production)
# Sampling rates (0.0 to 1.0)
SENTRY_TRACES_SAMPLE_RATE=0.1 # 10% of transactions tracked
SENTRY_PROFILES_SAMPLE_RATE=0.1 # 10% of transactions profiled
```
## Environment-Specific Examples
### Development Configuration
**config.toml for development:**
```toml
[app]
LOG_LEVEL = "DEBUG"
SESSION_OBSERVERS_LIMIT = 10
EMBED_MESSAGES = false
[db]
CONNECTION_URI = "postgresql+psycopg://postgres:postgres@localhost:5432/honcho_dev"
POOL_SIZE = 5
[auth]
USE_AUTH = false
[cache]
ENABLED = false
[dialectic]
PROVIDER = "anthropic"
MODEL = "claude-sonnet-4-20250514"
PERFORM_QUERY_GENERATION = false
MAX_OUTPUT_TOKENS = 2500
[deriver]
WORKERS = 1
PROVIDER = "google"
MODEL = "gemini-2.5-flash-lite"
[peer_card]
ENABLED = true
PROVIDER = "openai"
MODEL = "gpt-5-nano-2025-08-07"
[summary]
ENABLED = true
PROVIDER = "openai"
MODEL = "gpt-4o-mini-2024-07-18"
MAX_TOKENS_SHORT = 1000
MAX_TOKENS_LONG = 4000
[dream]
ENABLED = true
[webhook]
MAX_WORKSPACE_LIMIT = 10
[metrics]
ENABLED = false
[sentry]
ENABLED = false
```
**Environment variables for development:**
```bash
# .env.development
LOG_LEVEL=DEBUG
DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/honcho_dev
AUTH_USE_AUTH=false
CACHE_ENABLED=false
# LLM Provider API Keys
LLM_ANTHROPIC_API_KEY=your-dev-anthropic-key
LLM_OPENAI_API_KEY=your-dev-openai-key
LLM_GEMINI_API_KEY=your-dev-gemini-key
```
### Production Configuration
**config.toml for production:**
```toml
[app]
LOG_LEVEL = "WARNING"
SESSION_OBSERVERS_LIMIT = 10
EMBED_MESSAGES = true
[db]
CONNECTION_URI = "postgresql+psycopg://honcho_user:secure_password@prod-db:5432/honcho_prod"
POOL_SIZE = 20
MAX_OVERFLOW = 40
[auth]
USE_AUTH = true
[cache]
ENABLED = true
URL = "redis://redis:6379/0"
DEFAULT_TTL_SECONDS = 300
[dialectic]
PROVIDER = "anthropic"
MODEL = "claude-sonnet-4-20250514"
PERFORM_QUERY_GENERATION = false
MAX_OUTPUT_TOKENS = 2500
[deriver]
WORKERS = 4
PROVIDER = "google"
MODEL = "gemini-2.5-flash-lite"
[peer_card]
ENABLED = true
PROVIDER = "openai"
MODEL = "gpt-5-nano-2025-08-07"
[summary]
ENABLED = true
PROVIDER = "openai"
MODEL = "gpt-4o-mini-2024-07-18"
MAX_TOKENS_SHORT = 1000
MAX_TOKENS_LONG = 4000
[dream]
ENABLED = true
PROVIDER = "openai"
MODEL = "gpt-4o-mini-2024-07-18"
[webhook]
MAX_WORKSPACE_LIMIT = 10
[metrics]
ENABLED = true
[sentry]
ENABLED = true
ENVIRONMENT = "production"
TRACES_SAMPLE_RATE = 0.1
PROFILES_SAMPLE_RATE = 0.1
```
**Environment variables for production:**
```bash
# .env.production
LOG_LEVEL=WARNING
DB_CONNECTION_URI=postgresql+psycopg://honcho_user:secure_password@prod-db:5432/honcho_prod
# Authentication
AUTH_USE_AUTH=true
AUTH_JWT_SECRET=your-super-secret-jwt-key
# Cache
CACHE_ENABLED=true
CACHE_URL=redis://redis:6379/0
# LLM Provider API Keys
LLM_ANTHROPIC_API_KEY=your-prod-anthropic-key
LLM_OPENAI_API_KEY=your-prod-openai-key
LLM_GEMINI_API_KEY=your-prod-gemini-key
LLM_GROQ_API_KEY=your-prod-groq-key
# Webhooks
WEBHOOK_SECRET=your-webhook-signing-secret
# Monitoring
SENTRY_DSN=https://your-sentry-dsn@sentry.io/project-id
SENTRY_ENVIRONMENT=production
```
## Migration Management
**Running Database Migrations:**
```bash
# Check current migration status
uv run alembic current
# Upgrade to latest
uv run alembic upgrade head
# Downgrade to specific revision
uv run alembic downgrade revision_id
# Create new migration
uv run alembic revision --autogenerate -m "Description of changes"
```
## Troubleshooting
**Common Configuration Issues:**
1. **Database Connection Errors**
- Ensure `DB_CONNECTION_URI` uses `postgresql+psycopg://` prefix
- Verify database is running and accessible
- Check pgvector extension is installed
2. **Authentication Issues**
- Set `AUTH_USE_AUTH=true` for production
- Generate and set `AUTH_JWT_SECRET` if authentication is enabled
- Use `python scripts/generate_jwt_secret.py` to create a secure secret
3. **LLM Provider Issues**
- Verify API keys are set correctly
- Check model names match provider specifications
- Ensure provider is enabled in configuration
4. **Deriver Issues**
- Increase `DERIVER_WORKERS` for better performance
- Check `DERIVER_STALE_SESSION_TIMEOUT_MINUTES` for session cleanup
- Monitor background processing logs
This configuration guide covers all the settings available in Honcho. Always use environment-specific configuration files and never commit sensitive values like API keys or JWT secrets to version control.

172
docs/v2.6.0-alpha/contributing/guidelines.mdx Normal file
View File

@ -0,0 +1,172 @@
---
title: 'Contributing Guidelines'
icon: 'handshake'
---
Thank you for your interest in contributing to Honcho! This guide outlines the process for contributing to the project and our development conventions.
## Getting Started
Before you start contributing, please:
1. **Set up your development environment** - Follow the [Local Development guide](https://github.com/plastic-labs/honcho/blob/main/CONTRIBUTING.md#local-development) in the Honcho repository to get Honcho running locally.
2. **Join our community** - Feel free to join us in our [Discord](http://discord.gg/plasticlabs) to discuss your changes, get help, or ask questions.
3. **Review existing issues** - Check the [issues tab](https://github.com/plastic-labs/honcho/issues) to see what's already being worked on or to find something to contribute to.
## Contribution Workflow
### 1. Fork and Clone
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
```
### 2. Create a Branch
Create a new branch for your feature or bug fix:
```bash
git checkout -b feature/your-feature-name
# or
git checkout -b fix/your-bug-fix-name
```
**Branch naming conventions:**
- `feature/description` - for new features
- `fix/description` - for bug fixes
- `docs/description` - for documentation updates
- `refactor/description` - for code refactoring
- `test/description` - for adding or updating tests
### 3. Make Your Changes
- Write clean, readable code that follows our coding standards (see below)
- Add tests for new functionality
- Update documentation as needed
- Make sure your changes don't break existing functionality
### 4. Commit Your Changes
We follow conventional commit standards. Format your commit messages as:
```
type(scope): description
[optional body]
[optional footer]
```
**Types:**
- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation only changes
- `style`: Changes that do not affect the meaning of the code
- `refactor`: A code change that neither fixes a bug nor adds a feature
- `test`: Adding missing tests or correcting existing tests
- `chore`: Changes to the build process or auxiliary tools
**Examples:**
```bash
git commit -m "feat(api): add new dialectic endpoint for user insights"
git commit -m "fix(db): resolve connection pool timeout issue"
git commit -m "docs(readme): update installation instructions"
```
### 5. Submit a Pull Request
1. Push your branch to your fork:
```bash
git push origin your-branch-name
```
2. Create a pull request on GitHub from your branch to the `main` branch
3. Fill out the pull request template with:
- A clear description of what changes you've made
- The motivation for the changes
- Any relevant issue numbers (use "Closes #123" to auto-close issues)
- Screenshots or examples if applicable
## Coding Standards
### Python Code Style
- Follow [PEP 8](https://www.python.org/dev/peps/pep-0008/) style guidelines
- Use [Black](https://black.readthedocs.io/) for code formatting (we may add this to CI in the future)
- Use type hints where possible
- Write docstrings for functions and classes using Google style docstrings
### Code Organization
- Keep functions focused and single-purpose
- Use meaningful variable and function names
- Add comments for complex logic
- Follow existing patterns in the codebase
### Testing
- Write unit tests for new functionality
- Ensure existing tests pass before submitting
- Use descriptive test names that explain what is being tested
- Mock external dependencies appropriately
### Documentation
- Update relevant documentation for new features
- Include examples in docstrings where helpful
- Keep README and other docs up to date with changes
## Review Process
1. **Automated checks** - Your PR will run through automated checks including tests and linting
2. **Project maintainer review** - A project maintainer will review your code for:
- Code quality and adherence to standards
- Functionality and correctness
- Test coverage
- Documentation completeness
3. **Discussion and iteration** - You may be asked to make changes or clarifications
4. **Approval and merge** - Once approved, your PR will be merged into `main`
## Types of Contributions
We welcome various types of contributions:
- **Bug fixes** - Help us squash bugs and improve stability
- **New features** - Add functionality that benefits the community
- **Documentation** - Improve or expand our documentation
- **Tests** - Increase test coverage and reliability
- **Performance improvements** - Help make Honcho faster and more efficient
- **Examples and tutorials** - Help other developers use Honcho
## Issue Reporting
When reporting bugs or requesting features:
1. Check if the issue already exists
2. Use the appropriate issue template
3. Provide clear reproduction steps for bugs
4. Include relevant environment information
5. Be specific about expected vs actual behavior
## Questions and Support
- **General questions** - Join our [Discord](http://discord.gg/plasticlabs)
- **Bug reports** - Use GitHub issues
- **Feature requests** - Use GitHub issues with the feature request template
- **Security issues** - Please email us privately rather than opening a public issue
## License
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! 🫡

671
docs/v2.6.0-alpha/contributing/license.mdx Normal file
View File

@ -0,0 +1,671 @@
---
title: 'License'
icon: 'scroll'
---
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)
```
GNU AFFERO GENERAL PUBLIC LICENSE
Version 3, 19 November 2007
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU Affero General Public License is a free, copyleft license for
software and other kinds of works, specifically designed to ensure
cooperation with the community in the case of network server software.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
our General Public Licenses are intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
Developers that use our General Public Licenses protect your rights
with two steps: (1) assert copyright on the software, and (2) offer
you this License which gives you legal permission to copy, distribute
and/or modify the software.
A secondary benefit of defending all users' freedom is that
improvements made in alternate versions of the program, if they
receive widespread use, become available for other developers to
incorporate. Many developers of free software are heartened and
encouraged by the resulting cooperation. However, in the case of
software used on network servers, this result may fail to come about.
The GNU General Public License permits making a modified version and
letting the public access it on a server without ever releasing its
source code to the public.
The GNU Affero General Public License is designed specifically to
ensure that, in such cases, the modified source code becomes available
to the community. It requires the operator of a network server to
provide the source code of the modified version running there to the
users of that server. Therefore, public use of a modified version, on
a publicly accessible server, gives the public access to the source
code of the modified version.
An older license, called the Affero General Public License and
published by Affero, was designed to accomplish similar goals. This is
a different license, not a version of the Affero GPL, but Affero has
released a new version of the Affero GPL which permits relicensing under
this license.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU Affero General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the work with which it is combined will remain governed by version
3 of the GNU General Public License.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU Affero General Public License from time to time. Such new versions
will be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU Affero General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU Affero General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU Affero General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published
by the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If your software can interact with users remotely through a computer
network, you should also make sure that it provides a way for users to
get its source. For example, if your program is a web application, its
interface could display a "Source" link that leads users to an archive
of the code. There are many ways you could offer source, and different
solutions will be better for different programs; see section 13 for the
specific requirements.
You should also get your employer (if you work as a programmer) or school,
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/>.
```

324
docs/v2.6.0-alpha/contributing/self-hosting.mdx Normal file
View File

@ -0,0 +1,324 @@
---
title: 'Local Environment Setup'
sidebarTitle: 'Local Environment'
description: 'Set up a local environment to run Honcho for development, testing, or self-hosting'
icon: 'computer'
---
This guide helps you set up a local environment to run Honcho for development, testing, or self-hosting.
## Overview
By the end of this guide, you'll have:
- A local Honcho server running on your machine
- A PostgreSQL database with pgvector extension
- Basic configuration to connect your applications
- A working environment for development or testing
## Prerequisites
Before you begin, ensure you have the following installed:
### Required Software
- **uv** - Python package manager: `pip install uv` (manages Python installations automatically)
- **Git** - [Download from git-scm.com](https://git-scm.com/downloads)
- **Docker** (optional) - [Download from docker.com](https://www.docker.com/products/docker-desktop/)
### Database Options
You'll need a PostgreSQL database with the pgvector extension. Choose one:
- **Local PostgreSQL** - Install locally or use Docker
- **Supabase** - Free cloud PostgreSQL with pgvector
- **Railway** - Simple cloud PostgreSQL hosting
- **Your own PostgreSQL server**
## Docker Setup (Recommended)
The easiest way to get started is using Docker Compose, which handles both the database and Honcho server.
### 1. Clone the Repository
```bash
git clone https://github.com/plastic-labs/honcho.git
cd honcho
```
### 2. Set Up Environment Variables
Copy the example environment file and configure it:
```bash
cp .env.template .env
```
Edit `.env` and set your API keys (if using LLM features):
```bash
# Optional API keys (required for LLM features)
OPENAI_API_KEY=your-openai-api-key
ANTHROPIC_API_KEY=your-anthropic-api-key
# Database will be created automatically by Docker
DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@database:5432/honcho
# Disable auth for local development
AUTH_USE_AUTH=false
```
### 3. Start the Services
```bash
# Copy the example docker-compose file
cp docker-compose.yml.example docker-compose.yml
# Start PostgreSQL and Honcho
docker compose up -d
```
### 4. Verify It's Working
Check that both services are running:
```bash
docker compose ps
```
Test the Honcho API:
```bash
curl http://localhost:8000/health
```
You should see a response indicating the service is healthy.
## Manual Setup
For more control over your environment, you can set up everything manually.
### 1. Clone and Install Dependencies
```bash
git clone https://github.com/plastic-labs/honcho.git
cd honcho
# Install dependencies using uv (this will also set up Python if needed)
uv sync
# Activate the virtual environment
source .venv/bin/activate # On Windows: .venv\Scripts\activate
```
### 2. Set Up PostgreSQL
#### Option A: Local PostgreSQL Installation
Install PostgreSQL and pgvector on your system:
**macOS (using Homebrew):**
```bash
brew install postgresql
brew install pgvector
```
**Ubuntu/Debian:**
```bash
sudo apt update
sudo apt install postgresql postgresql-contrib
# Install pgvector extension (see pgvector docs for your version)
```
**Windows:**
Download from [postgresql.org](https://www.postgresql.org/download/windows/)
#### Option B: Docker PostgreSQL
```bash
docker run --name honcho-db \
-e POSTGRES_DB=honcho \
-e POSTGRES_USER=postgres \
-e POSTGRES_PASSWORD=postgres \
-p 5432:5432 \
-d pgvector/pgvector:pg15
```
### 3. Create Database and Enable Extensions
Connect to PostgreSQL and set up the database:
```bash
# Connect to PostgreSQL
psql -U postgres
# Create database and enable extensions
CREATE DATABASE honcho;
\c honcho
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
\q
```
### 4. Configure Environment
Create a `.env` file with your settings:
```bash
cp .env.template .env
```
Edit `.env` with your configuration:
```bash
# Database connection
DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/honcho
# Optional API keys (required for LLM features)
OPENAI_API_KEY=your-openai-api-key
ANTHROPIC_API_KEY=your-anthropic-api-key
# Development settings
AUTH_USE_AUTH=false
LOG_LEVEL=DEBUG
```
### 5. Run Database Migrations
```bash
# Run migrations to create tables
uv run alembic upgrade head
```
### 6. Start the Server
```bash
# Start the development server
fastapi dev src/main.py
```
The server will be available at `http://localhost:8000`.
## Cloud Database Setup
If you prefer to use a managed PostgreSQL service:
### Supabase (Recommended)
1. **Create a Supabase project** at [supabase.com](https://supabase.com)
2. **Enable pgvector extension** in the SQL editor:
```sql
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
```
3. **Get your connection string** from Settings > Database
4. **Update your `.env` file** with the connection string
### Railway
1. **Create a Railway project** at [railway.app](https://railway.app)
2. **Add a PostgreSQL service**
3. **Enable pgvector** in the PostgreSQL console
4. **Get your connection string** from the service variables
5. **Update your `.env` file**
## Verify Your Setup
Once your Honcho server is running, verify everything is working:
### 1. Health Check
```bash
curl http://localhost:8000/health
```
### 2. API Documentation
Visit `http://localhost:8000/docs` to see the interactive API documentation.
### 3. Test with SDK
Create a simple test script:
```python
from honcho import Honcho
# Connect to your local instance
client = Honcho(base_url="http://localhost:8000")
# Create a test peer
peer = client.peer("test-user")
print(f"Created peer: {peer.id}")
```
## Connect Your Application
Now that Honcho is running locally, you can connect your applications:
### Update SDK Configuration
```python
# Python SDK
from honcho import Honcho
client = Honcho(
base_url="http://localhost:8000", # Your local instance
api_key="your-api-key" # If auth is enabled
)
```
```typescript
// TypeScript SDK
import { Honcho } from '@honcho-ai/sdk';
const client = new Honcho({
baseUrl: 'http://localhost:8000', // Your local instance
apiKey: 'your-api-key' // If auth is enabled
});
```
### Next Steps
- **Explore the API**: Check out the [API Reference](/v2/api-reference/introduction)
- **Try the SDKs**: See our [guides](/v2/guides) for examples
- **Configure Honcho**: Visit the [Configuration Guide](./configuration) for detailed settings
- **Join the community**: [Discord](https://discord.gg/plasticlabs)
## Troubleshooting
### Common Issues
**Database Connection Errors**
- Ensure PostgreSQL is running
- Verify the connection string format: `postgresql+psycopg://...`
- Check that pgvector extension is installed
**API Key Issues**
- Verify your OpenAI and Anthropic API keys are valid
- Check that the keys have sufficient credits/quota
**Port Already in Use**
- Pass a different port to FastAPI or stop other services using port 8000
**Docker Issues**
- Ensure Docker is running
- Check container logs: `docker compose logs`
- Restart containers: `docker compose down && docker compose up -d`
**Migration Errors**
- Ensure the database exists and pgvector is enabled
- Check database permissions
- Run migrations manually: `uv run alembic upgrade head`
### Getting Help
- **GitHub Issues**: [Report bugs](https://github.com/plastic-labs/honcho/issues)
- **Discord**: [Join our community](https://discord.gg/plasticlabs)
- **Documentation**: Check the [Configuration Guide](./configuration) for detailed settings
## Production Considerations
When self-hosting for production, consider:
- **Security**: Enable authentication, use HTTPS, secure your database
- **Scaling**: Use connection pooling, consider load balancing
- **Monitoring**: Set up logging, error tracking, health checks
- **Backups**: Regular database backups, disaster recovery plan
- **Updates**: Keep Honcho and dependencies updated

102
docs/v2.6.0-alpha/documentation/core-concepts/architecture.mdx Normal file
View File

@ -0,0 +1,102 @@
---
title: "Architecture & Intuition"
description: "Understanding Honcho's core concepts and data model."
icon: "sitemap"
sidebarTitle: "Architecture"
---
Honcho is memory infrastructure that continuously [*reasons*](/v2/documentation/core-concepts/reasoning) about data to build rich representations of peers (users, agents, or any entity) over time. This document explains the data model, system components, and how data flows through Honcho.
## Data Model
Honcho has a hierarchical data model centered around the entities below.
```mermaid
graph LR
W[Workspaces] -->|have| P[Peers]
W -->|have| S[Sessions]
S -->|have| SM[Messages]
P <-.->|many-to-many| S
style W fill:#B6DBFF,stroke:#333,color:#000
style P fill:#B6DBFF,stroke:#333,color:#000
style S fill:#B6DBFF,stroke:#333,color:#000
style SM fill:#B6DBFF,stroke:#333,color:#000
```
- A Workspace has Peers & Sessions
- A Peer can be in multiple Sessions and can send Messages in a Session
- A Session can have many Peers and stores Messages sent by its Peers
### <Icon icon="building" /> Workspaces
Workspaces are the top-level containers in Honcho. They provide complete isolation between different applications or environments, essentially serving as a namespace to keep different workloads separate. You might use separate workspaces for development, staging, and production environments, or to isolate different product lines. They also enable multi-tenant SaaS applications where each customer gets their own isolated workspace with complete data separation.
Authentication is scoped to the workspace level, and configuration settings can be applied workspace-wide to control behavior across all peers and sessions within that workspace.
---
### <Icon icon="user" /> Peers
Peers are the most important entity in Honcho--everything revolves around building and maintaining their [*representations*](/v2/documentation/core-concepts/representation). A peer represents any individual user, agent, or entity in a workspace. Treating humans and agents the same way lets you build arbitrary combinations for multi-agent or group chat scenarios.
Each peer has a unique identifier within a workspace and is a container for reasoning across all their sessions. This cross-session context means conclusions drawn about a peer in one session can inform interactions in completely different sessions. Peers can be configured to control whether Honcho reasons about them.
You can use peers for any entity that persists over time--individual users in chatbot applications, AI agents interacting with users or other agents, customer profiles in support systems, student profiles in educational platforms, or even NPCs in role-playing games.
---
### <Icon icon="message" /> Sessions
Sessions represent interaction threads or contexts between peers. A session can involve multiple peers and provides temporal boundaries for when a set of interactions starts and ends. This lets you scope context and memory to specific interactions while still maintaining longer-term peer representations that span sessions.
Use sessions to scope things like support tickets, meeting transcripts, learning sessions, or conversations. You can also use single-peer sessions as a way to import external data--create a session with just one peer and structure emails, documents, or files as messages to enrich that peer's representation.
Session-level configuration gives you fine-grained control over perspective-taking behavior. You can configure whether a peer should form representations of other peers in the session, and whether other peers should form representations of them.
---
### <Icon icon="envelope" /> Messages
Messages are the fundamental units of interaction within sessions. While they typically represent back-and-forth communication between peers, you can also use messages to ingest any information that provides context--emails, documents, files, user actions, system notifications, or rich media content.
Every message is attributed to a specific peer and ordered chronologically within its session. When messages are created, they trigger automatic background reasoning that updates peer representations. Messages support rich metadata and structured data through JSONB fields, making them flexible enough to capture whatever information matters for your use case.
## Data Flow
Understanding how data moves through Honcho helps clarify the architecture.
When you create messages, they're immediately written to PostgreSQL and reasoning tasks are added to background queues. Background workers then generate logic, summaries, and new insights to improve representations. These conclusions and insights get stored in vector collections for retrieval. This async approach ensures fast writes while still providing rich reasoning capabilities.
When you need context from Honcho, you query through the "Chat" endpoint or "Get Context" endpoint. Honcho retrieves relevant conclusions from vector storage along with recent messages, then assembles everything into coherent context ready to inject into agent prompts.
![Honcho Architecture](/images/architecture.png)
The diagram above shows how agents write messages to Honcho, which triggers reasoning that updates peer representations. Agents can then query representations to get additional context for their next response. Black arrows represent read/write of regular data (messages, storage), while red arrows represent read/write of reasoned-over data (logic, peer representations).
## Configuration & Extensibility
Honcho is designed to be flexible. Settings cascade hierarchically from workspace to peer to session, so you can set defaults at the workspace level and override them for specific peers or sessions. Feature flags let you enable or disable reasoning modes, perspective tracking, and other capabilities. You can bring your own LLM provider--OpenAI, Anthropic, or custom endpoints--and metadata fields let you extend any primitive with custom JSON data. Batch operations let you create up to 100 messages in a single API call for efficient bulk ingestion.
## Design Principles
Honcho's architecture follows a few core principles. Everything revolves around building representations of peers (peer-centric). Memory isn't just storage--it's continual learning (reasoning-first). Long-lived operations happen in the background so they don't block user interactions (async by default). The system works with any LLM provider (provider-agnostic) and is built for isolation and scalability from the ground up (multi-tenant). Users and agents are both represented as peers, which enables flexible scenarios you couldn't easily model with a traditional user-assistant paradigm (unified paradigm).
## Next Steps
<CardGroup cols={2}>
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
Sign up for the Honcho platform and start building
</Card>
<Card title="Quickstart" icon="rocket" href="/v2/documentation/introduction/quickstart">
Get started with your first integration
</Card>
<Card title="Reasoning" icon="gears" href="/v2/documentation/core-concepts/reasoning">
Learn how Honcho reasons about messages to build memory
</Card>
<Card title="Peer Representations" icon="user-magnifying-glass" href="/v2/documentation/core-concepts/representation">
Understand what peer representations are and how they work
</Card>
</CardGroup>

96
docs/v2.6.0-alpha/documentation/core-concepts/reasoning.mdx Normal file
View File

@ -0,0 +1,96 @@
---
title: "Honcho Reasoning"
icon: "gears"
sidebarTitle: "Reasoning"
---
Honcho is a memory system that *reasons*. You can read more on the philosophy behind the approach [here](https://blog.plasticlabs.ai/blog/Memory-as-Reasoning), but practically speaking, the system runs inference on data in the background to produce the highest quality context for simulating statefulness. This document explains why reasoning is necessary and how Honcho implements it.
<Note>
If you'd like to experience this methodology first-hand, try out [Honcho Chat](https://honcho.chat)--an interface to your personal memory. Read more [here](https://blog.plasticlabs.ai/blog/Introducing-Honcho-Chat)!
</Note>
## Why Reasoning?
Traditional RAG systems treat memory as static storage--they retrieve what was explicitly said when semantically similar queries appear. Other solutions take an opinion for you on what's important to store, whether through structured facts in databases or predefined knowledge graphs. Honcho takes a different approach: we extract all latent information by reasoning about everything, so it's there when you need it. Our job is to produce the most robust reasoning possible--it's your job as a developer to decide what's relevant for your use case.
We extract this latent information through formal logic. Formal logical reasoning is AI-native--LLMs perform the rigorous, compute-intensive thinking that humans struggle with, instantly and consistently. This unlocks insights that are only accessible by *rigorously thinking* about your data, generating new understanding that goes beyond simple recall.
## Formal Logic Framework
Honcho's memory system is powered by custom models trained to perform formal logical reasoning. The system extracts what was explicitly stated, draws certain conclusions from those, identifies patterns across multiple conclusions, and infers the simplest explanations for behavior.
Why formal logic specifically? LLMs are uniquely well-suited for this reasoning task--it's well-represented in the pretraining data. LLMs can maintain consistent reasoning across thousands of conclusions without cognitive fatigue or belief resistance--which is extremely hard for humans to do reliably. The outputs are also composable, meaning logical conclusions can be stored, retrieved, and combined programmatically for dynamic context assembly.
Here's an example of a data structure the reasoning models generate:
```json
{
"explicit": [
{
"content": "premise 1"
},
...
{
"content": "premise n"
}
],
"deductive": [
{
"premises": [
"premise 1",
...
"premise n"
],
"conclusion": "conclusion 1"
},
...
]
}
```
The explicit reasoning model ([Neuromancer XR](https://blog.plasticlabs.ai/research/Introducing-Neuromancer-XR)) outputs its "thinking" followed by things that were explicitly stated, which serve as premises to scaffold deductive conclusions. It's on top of this reasoning foundation that further reasoning is scaffolded. Currently that includes peer cards (key biographical information about the peer), consolidation (identifying redundant or contradictory information), induction (pattern recognition across multiple messages), and abduction (inferring the simplest explanations for observed behavior).
The reasoning that Honcho does is something we're constantly iterating and improving on. Our goal is simple--provide the richest, most relevant context in the fastest, cheapest way possible in order to simulate statefulness in whatever setting you need.
## How It Works
When you write messages to Honcho, they're stored immediately and enqueued for background processing. Reasoning asynchronously ensures fast writes while still providing rich reasoning capabilities. Messages are stored immediately without blocking, and session-based queues maintain chronological consistency so reasoning tasks affecting the same peer representation are always processed in order.
The reasoning outputs--conclusions, summaries, peer cards--are stored as part of peer representations, indexed in vector collections for retrieval.
![Diagram for reasoning in Honcho](/images/reasoning.png)
The diagram above shows how agents write messages to Honcho, which triggers reasoning that updates peer representations. Agents can then query representations to get additional context for their next response.
## Balances & Design Choices
Off-the-shelf LLMs can perform formal logical reasoning, but they aren't optimized for it. Honcho uses custom models trained specifically for logical rigor (following formal reasoning rules rather than plausible-sounding text), structured output (consistent JSON schema with premises and conclusions), and efficiency (smaller, faster models tuned for this specific task). This allows Honcho to reason more reliably and at lower cost than general-purpose frontier LLMs.
The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, scaffolded conclusions are more token-efficient than raw conversation history, and we batch where appropriate to optimize update frequency.
Honcho's reasoning capabilities are actively being improved. Current areas of development include enhanced inductive and abductive reasoning, multi-hop and temporal reasoning, and expanded file types and modalities. The system is designed to be extensible--new reasoning capabilities can be added without breaking existing functionality.
<Note>
If you find that the data you're uploading to Honcho isn't being reasoned over to your liking, we'd love to improve it for you and ingest your data for free--reach out via [Discord](https://discord.gg/plasticlabs) or [email](mailto:support@plasticlabs.ai)!
</Note>
## Next Steps
Without exhaustive reasoning, you're stuck with surface-level retrieval or someone else's opinion on what matters. You can't effectively simulate statefulness if you're not reasoning about everything in the present--coherence plummets, trust falls, and users churn. Don't leave key information on the table. Use Honcho to give your agents the context they need to reconstruct the past as comprehensively as possible and maintain coherence--for your use case.
<CardGroup cols={2}>
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
Sign up for the Honcho platform and start building
</Card>
<Card title="Quickstart" icon="rocket" href="/v2/documentation/introduction/quickstart">
Get started with your first integration
</Card>
<Card title="Architecture" icon="sitemap" href="/v2/documentation/core-concepts/architecture">
See how reasoning fits into Honcho's overall architecture
</Card>
<Card title="Peer Representations" icon="user-magnifying-glass" href="/v2/documentation/core-concepts/representation">
Learn how reasoning produces peer representations
</Card>
</CardGroup>

66
docs/v2.6.0-alpha/documentation/core-concepts/representation.mdx Normal file
View File

@ -0,0 +1,66 @@
---
title: "Peer Representations"
icon: "user-magnifying-glass"
sidebarTitle: "Representations"
---
A representation is the collection of reasoning Honcho has done about a peer over time. It's the continual learning about a peer over every message that's been written to it. Representations evolve dynamically as new messages come in, with Honcho reasoning about them in the background.
When you write messages to Honcho, the reasoning models extract premises, draw conclusions, and scaffold new conclusions as well. All of that reasoning gets stored as the peer's representation. Think of it as Honcho's understanding of who that peer is, what they care about, and how they behave, built through formal logic rather than simple storage.
## What's in a Representation?
A peer representation is made up of several types of artifacts that Honcho generates through [*reasoning*](/v2/documentation/core-concepts/reasoning):
**Conclusions** are insights derived through formal logic. Deductive conclusions are things Honcho can be certain about based on extracted premises. Inductive conclusions identify patterns across multiple messages. Abductive conclusions infer the simplest explanations for observed behavior. For example, if a user frequently mentions work deadlines and rarely mentions hobbies, Honcho might inductively conclude they're time-constrained or career-focused.
**Summaries** capture the essence of sessions. Short summaries are generated every 20 messages by default, and long summaries every 60 messages. These help compress conversation history into dense, queryable context.
**Peer cards** contain key biographical information. They essentially cache the most basic information about a peer (name, occupation, interests) to ensure the model never loses its grounding.
These enable continuous improvement. Each new message refines conclusions, updates summaries, and keeps peer cards current—building a more accurate representation over time.
## Observation & Perspective-Taking
Honcho can build different representations based on what each peer observes. This enables sophisticated multi-peer scenarios where understanding is relative to what was actually witnessed.
There are two observation modes controlled by [configuration](/v2/documentation/features/advanced/configuration):
**Honcho observing peers** (`observe_me`): When enabled (default), Honcho forms a representation of the peer based on all messages they've sent across all sessions. This is Honcho's understanding of that peer, built from everything they've said and done in your system. Set `observe_me: false` if you don't want Honcho to reason about that peer at all.
**Peers observing others** (`observe_others`): When enabled at the session level, a peer will form representations of other peers in that session based only on messages they've observed. If Alice and Bob are in a session together and Alice has `observe_others: true`, Alice will form a representation of Bob based solely on what Bob said in sessions Alice participated in. Alice's representation of Bob will be completely different from Charlie's representation of Bob if they've observed different interactions.
In the diagram below, assume `observe_me` isn't turned off (again, default behavior) and `observe_others` is turned on for both peers in a session that contains the peers Alice and Bob.
![](/images/observe_config.png)
The shared session that Alice and Bob have informs their respective representations of each other. Alice has a small set of conclusions that pertain to Bob, and Bob has a small set of conclusions that pertain to Alice. Honcho can observe the totality of each peer's interactions, forming representations of the peers themselves, and enable peers to store conclusions about peers they interact with based only on what they witness in shared sessions.
Why would you want peers observing others? So you can simulate stateful *perspectives*. If Bob participates with Alice in sessions 1 and 2, while Charlie participates with Alice in session 3, Bob's representation of Alice will be built from sessions 1 and 2, while Charlie's representation will only include what happened in session 3. Bob can reference shared history, inside jokes, or past conflicts that Charlie knows nothing about. Without perspective-based segmentation, all agents are omniscient--the simulation breaks down, trust falls apart, and users churn.
## Why Representations Work
Statefulness is simulated through reconstruction of the past. Traditional systems reconstruct by retrieving stored facts, querying semantically similar items, and hoping the LLM does the rest. Honcho reconstructs through reasoning about the past exhaustively, leaving much less to chance.
Reasoning can surface insights never explicitly stated. If a user mentions they're saving for a house in one session and complains about subscription costs in another, Honcho can conclude they're budget-conscious without anyone saying it. Reasoning handles contradictions gracefully--when new information conflicts with old conclusions, it reconciles them instead of just accumulating more data. And reasoning enables prediction under uncertainty, inferring what's likely true based on patterns even when data is incomplete.
Humans reconstruct the past from imperfect recollections, then act on those reconstructions as if they were complete. Representations enable agents to do the same with far greater fidelity. Reasoning produces an exhaustive, explicit record of what can be concluded about a peer--giving agents complete recollection that humans can only pretend to have. That's what makes truly stateful agents possible.
## Next Steps
<CardGroup cols={2}>
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
Sign up for the Honcho platform and start building
</Card>
<Card title="Quickstart" icon="rocket" href="/v2/documentation/introduction/quickstart">
See representations in action with a working example
</Card>
<Card title="Architecture" icon="sitemap" href="/v2/documentation/core-concepts/architecture">
Understand how representations fit into Honcho's architecture
</Card>
<Card title="Chat Endpoint" icon="comments" href="/v2/documentation/features/chat">
Learn how to query representations with natural language
</Card>
</CardGroup>

20
docs/v2.6.0-alpha/documentation/features/advanced/overview.mdx Normal file
View File

@ -0,0 +1,20 @@
---
title: "Advanced Features"
icon: "brain"
description: "Advanced configuration and monitoring options for Honcho"
sidebarTitle: "Overview"
---
Advanced features give you fine-grained control over Honcho's behavior and implementation.
## Configuration & Monitoring
- [Queue Status](/v2/documentation/features/advanced/queue-status) - Monitor background processing and reasoning tasks
- [Configuration](/v2/documentation/features/advanced/toggle-reasoning) - Configure reasoning models and behavior
- [Summarizer](/v2/documentation/features/advanced/summarizer) - Automatic session summarization
## Querying & Filtering
- [Search](/v2/documentation/features/advanced/search) - Search across peers, sessions, and messages
- [Filters](/v2/documentation/features/advanced/using-filters) - Filter queries with advanced parameters
- [Streaming Responses](/v2/documentation/features/advanced/streaming-response) - Stream dialectic responses in real-time

130
docs/v2.6.0-alpha/documentation/features/advanced/queue-status.mdx Normal file
View File

@ -0,0 +1,130 @@
---
title: Queue Status
description: Learn how to check the status of Honcho's reasoning
icon: "lines-leaning"
---
Whenever messages are stored in Honcho, a background process kicks off to [reason](/v2/documentation/core-concepts/reasoning) about the conversation and generate insights.
Reasoning is an asynchronous process and, depending on load, may not immediately
generate insights for the latest message you've sent. To help with this, Honcho
provides several utilities to check the status of the queue.
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho()
status = honcho.get_queue_status()
honcho.poll_queue_status()
```
```typescript typescript
import { Honcho } from '@honcho-ai/sdk';
const honcho = new Honcho({});
const status = await honcho.getQueueStatus();
await honcho.pollQueueStatus();
```
</CodeGroup>
Output types
<CodeGroup>
```python Python
class QueueStatus(BaseModel):
completed_work_units: int
"""Completed work units"""
in_progress_work_units: int
"""Work units currently being processed"""
pending_work_units: int
"""Work units waiting to be processed"""
total_work_units: int
"""Total work units"""
sessions: Optional[Dict[str, Sessions]] = None
"""Per-session status when not filtered by session"""
```
```typescript TypeScript
Promise<{
totalWorkUnits: number
completedWorkUnits: number
inProgressWorkUnits: number
pendingWorkUnits: number
sessions?: Record<string, QueueStatus.Sessions>
}>
```
</CodeGroup>
Whenever a message is sent it will generate several tasks. These could
be tasks such as generating insights, cleaning up a representation, summarizing
a conversation etc. These tasks are defined based on who is sending the
message, what session the message is in, and potentially who is observing the
message. We call the combination of these parameters a `work_unit`
This has a few different implications.
- tasks within the same work_unit are processed sequentially, but multiple
work_units will be processed in parallel
- If local representations are turned in a Session then a message will
generate an additional work unit for every peer that has `observe_others=True`
The `get_queue_status` and `poll_queue_status` methods can take additional
parameters to scope the status to a specific work unit
<CodeGroup>
```python Python
def get_queue_status(
self,
observer_id: str | None = None,
sender_id: str | None = None,
session_id: str | None = None,
) -> QueueStatus:
```
```typescript TypeScript
export const QueueStatusOptionsSchema = z.object({
observerId: z.string().optional(),
senderId: z.string().optional(),
sessionId: z.string().optional(),
timeoutMs: z
.number()
.positive('Timeout must be a positive number')
.optional(),
})
```
</CodeGroup>
Additionally, there are queue status and polling queue status methods
available on the session objects in each of the SDKs.
Below are the function signatures for the session level queue status method
<CodeGroup>
```python python
@validate_call
def get_queue_status(
self,
observer_id: str | None = None,
sender_id: str | None = None,
) -> QueueStatus:
```
```typescript TypeScript
async getQueueStatus(
options?: Omit<QueueStatusOptions, 'sessionId'>
): Promise<{
totalWorkUnits: number
completedWorkUnits: number
inProgressWorkUnits: number
pendingWorkUnits: number
sessions?: Record<string, QueueStatus.Sessions>
}>
```
</CodeGroup>

271
docs/v2.6.0-alpha/documentation/features/advanced/representation-scopes.mdx Normal file
View File

@ -0,0 +1,271 @@
---
title: 'Representation Scopes'
description: 'Advanced configuration and querying for representations'
icon: 'circle'
---
Assuming reasoning is enabled, you can control the perspectives representations are built from. This page covers:
1. **Default Behavior** — Honcho reasons over every message written to a peer
2. **Observer-Observed Model** — How peers build representations of other peers
3. **Querying with Target** — Accessing perspective-specific representations
4. **Use Cases** — When to use directional representations
## Default: Reasoning On
When `observe_me=true` (the default), Honcho forms one representation per peer, reasoning over every message written to that peer across all sessions.
You can retrieve a subset of conclusions from a peer's representation using `working_rep()`:
```python
# Retrieve conclusions from Honcho's representation of Alice (across all sessions)
alice_rep = session.working_rep("alice")
# Or via chat
response = alice.chat("What are Alice's main interests?", session_id=session.id)
```
This is sufficient for most applications—Honcho reasons over every message written to the peer, storing conclusions that any part of your system can retrieve.
## Observer-Observed Representations
When you enable `observe_others=true` at the session level, peers begin forming **directional representations** of other peers they interact with. These representations are scoped to what that observer has actually witnessed.
### How It Works
Each peer has **one representation**, but that representation can contain reasoning about:
- **Itself** (when Honcho observes the peer with `observe_me=true`)
- **Other peers** (when the peer observes others with `observe_others=true`)
These are stored as separate (observer, observed) pairs in Honcho's internal collections:
| Observer | Observed | What This Represents |
|----------|----------|---------------------|
| alice | alice | Honcho's representation of Alice (across all sessions) |
| alice | bob | Alice's representation of Bob (from sessions Alice participated in) |
| alice | charlie | Alice's representation of Charlie (from sessions Alice participated in) |
### Information Segmentation
This enables sophisticated scenarios where different agents have different knowledge based on what they've actually witnessed.
**Example**: Bob and Charlie tell different things to Alice in separate sessions.
```
Session 1 (Alice + Bob):
Bob → "I had pancakes for breakfast."
Session 2 (Alice + Charlie):
Charlie → "I had pancakes for breakfast. Bob is lying about his breakfast."
```
With `observe_others=true` enabled on Alice:
- **Alice's representation of Bob** only includes Session 1 (she heard Bob say he had pancakes)
- **Alice's representation of Charlie** only includes Session 2 (she heard Charlie's claim about Bob lying)
- **Honcho's representation of Alice** reasons over both sessions
![](/images/observe_config.png)
## Querying with Target
The `target` parameter controls which representation you retrieve:
| Query | Returns |
|-------|---------|
| `working_rep("alice")` | Conclusions from Honcho's representation of Alice (across all sessions) |
| `working_rep("alice", target="bob")` | Conclusions from Alice's representation of Bob (from sessions Alice participated in) |
| `working_rep("alice", target="charlie")` | Conclusions from Alice's representation of Charlie (from sessions Alice participated in) |
### Code Examples
<CodeGroup>
```python Python
from honcho import Honcho, SessionPeerConfig
honcho = Honcho()
session = honcho.session("game-session")
alice = honcho.peer("alice")
bob = honcho.peer("bob")
charlie = honcho.peer("charlie")
# Add peers to session
session.add_peers([alice, bob, charlie])
# Enable Alice to form representations of others
session.set_peer_config(alice, SessionPeerConfig(observe_others=True))
# Add messages
session.add_messages([
bob.message("I had pancakes for breakfast."),
charlie.message("I prefer waffles.")
])
# Different sessions with different participants
session2 = honcho.session("game-session-2")
session2.add_peers([alice, charlie])
session2.set_peer_config(alice, SessionPeerConfig(observe_others=True))
session2.add_messages([
charlie.message("I didn't have breakfast. I lied to Bob.")
])
# Retrieve conclusions from different perspectives
honcho_view = session.working_rep("alice") # Across all sessions
bob_view = session.working_rep("alice", target="bob") # Alice's view of Bob
charlie_view = session2.working_rep("alice", target="charlie") # Alice's view of Charlie
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
const honcho = new Honcho({});
const session = await honcho.session("game-session");
const alice = await honcho.peer("alice");
const bob = await honcho.peer("bob");
const charlie = await honcho.peer("charlie");
await session.addPeers([alice, bob, charlie]);
await session.setPeerConfig(alice, { observe_others: true });
await session.addMessages([
bob.message("I had pancakes for breakfast."),
charlie.message("I prefer waffles.")
]);
const session2 = await honcho.session("game-session-2");
await session2.addPeers([alice, charlie]);
await session2.setPeerConfig(alice, { observe_others: true });
await session2.addMessages([
charlie.message("I didn't have breakfast. I lied to Bob.")
]);
// Retrieve conclusions from different perspectives
const honchoView = await session.workingRep("alice"); // Across all sessions
const bobView = await session.workingRep("alice", { target: "bob" }); // Alice's view of Bob
const charlieView = await session2.workingRep("alice", { target: "charlie" }); // Alice's view of Charlie
```
</CodeGroup>
### Chat Endpoint with Target
The `target` parameter also works with the chat endpoint:
<CodeGroup>
```python Python
# Query using conclusions from Honcho's representation (across all sessions)
honcho_answer = alice.chat(
"What did Bob say about breakfast?",
session_id=session.id
)
# Query using conclusions from Alice's representation of Bob (from Alice's sessions only)
alice_answer = alice.chat(
"What did Bob say about breakfast?",
session_id=session.id,
target="bob"
)
```
```typescript TypeScript
// Query using conclusions from Honcho's representation (across all sessions)
const honchoAnswer = await alice.chat(
"What did Bob say about breakfast?",
{ sessionId: session.id }
);
// Query using conclusions from Alice's representation of Bob (from Alice's sessions only)
const aliceAnswer = await alice.chat(
"What did Bob say about breakfast?",
{ sessionId: session.id, target: "bob" }
);
```
</CodeGroup>
<Note>
The `target` parameter only returns meaningful results if the observer peer has `observe_others=true` and has actually participated in sessions with the observed peer. Otherwise, the representation will be empty or non-existent.
</Note>
## When to Use Directional Representations
### Use Cases Where This Matters
1. **Multi-agent games**: NPCs should only know what they've witnessed, not omniscient game state
2. **Information asymmetry scenarios**: Different agents have access to different information
3. **Perspective-dependent agents**: Agent behavior depends on their unique understanding of other agents
4. **Privacy-segmented systems**: Users should only see representations based on their interactions
### Use Cases Where Default Is Sufficient
1. **Single-user applications**: Only one user, so perspective doesn't matter
2. **Centralized knowledge systems**: All agents should share the same understanding
3. **Simple chatbots**: No multi-agent interaction or information segmentation needed
<Info>
Most applications don't need directional representations. Start with the default Honcho-observes-all behavior and only enable `observe_others` when you need information segmentation between agents.
</Info>
## Architecture: How It's Stored
Under the hood, Honcho stores representations as (observer, observed) pairs in internal collections:
- **Collection**: A unique (observer, observed, workspace) tuple containing documents
- **Documents**: Individual conclusions and artifacts (deductive, inductive, abductive conclusions, summaries, peer cards) with session scoping
When you retrieve with `target`, Honcho fetches documents from the specific (observer, observed) collection. When you retrieve without `target`, it fetches from the (peer, peer) collection—the peer's self-representation.
This architecture enables:
- **Efficient querying**: Each perspective is isolated and can be queried independently
- **Session filtering**: Within a collection, documents can be filtered by session
- **Scalability**: Adding more observers doesn't degrade query performance
## Semantic Search Parameters
Both `working_rep()` and `chat()` support semantic filtering to retrieve a subset of relevant conclusions. You can optionally filter by session to retrieve only conclusions from specific session context:
| Parameter | Type | Description |
|-----------|------|-------------|
| `search_query` | `str` | Semantic query to filter conclusions |
| `search_top_k` | `int` | Number of results to include (1–100) |
| `search_max_distance` | `float` | Maximum semantic distance (0.0–1.0) |
| `include_most_derived` | `bool` | Include most recently derived conclusions |
| `max_observations` | `int` | Cap on total conclusions returned (1–100) |
<CodeGroup>
```python Python
# Retrieve conclusions about billing from Alice's representation of Bob
alice_view_billing = session.working_rep(
"alice",
target="bob",
search_query="billing issues",
search_top_k=10,
include_most_derived=True
)
```
```typescript TypeScript
const aliceViewBilling = await session.workingRep("alice", {
target: "bob",
searchQuery: "billing issues",
searchTopK: 10,
includeMostDerived: true
});
```
</CodeGroup>
## When Representations Update
Directional representations update automatically through the reasoning pipeline when:
1. A message is created in a session
2. The message sender has `observe_me=true` (or session-level equivalent)
3. Other peers in the session have `observe_others=true`
The pipeline respects scoping—Honcho's representations reason over messages across all sessions, while directional representations only reason over messages from sessions where the observer was an active participant.
<Note>
Conclusions are cached for fast retrieval. Use `working_rep()` to retrieve stored conclusions for dashboards and analytics. Use `peer.chat()` when you need query-specific reasoning with natural language.
</Note>

246
docs/v2.6.0-alpha/documentation/features/advanced/search.mdx Normal file
View File

@ -0,0 +1,246 @@
---
title: 'Search'
description: 'Learn how to search across workspaces, sessions, and peers to find relevant conversations and content'
icon: 'magnifying-glass'
---
Honcho's search functionality allows you to find relevant messages and conversations across different scopes - from entire workspaces down to specific peers or sessions.
## Search Scopes
### Workspace Search
Search across all content in your workspace - sessions, peers, and messages:
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho()
# Search across entire workspace
results = honcho.search("budget planning")
# Iterate through all results
for result in results:
print(f"Found: {result}")
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
(async () => {
// Initialize client
const honcho = new Honcho({});
// Search across entire workspace
const results = await honcho.search("budget planning");
// Iterate through all results
for (const result of results) {
console.log(`Found: ${result}`);
}
})();
```
</CodeGroup>
### Session Search
Search within a specific session's conversation history:
<CodeGroup>
```python Python
# Create or get a session
session = honcho.session("team-meeting-jan")
# Search within this session only
results = session.search("action items")
# Process results
for result in results:
print(f"Session result: {result}")
```
```typescript TypeScript
(async () => {
// Create or get a session
const session = await honcho.session("team-meeting-jan");
// Search within this session only
const results = await session.search("action items");
// Process results
for (const result of results) {
console.log(`Session result: ${result}`);
}
})();
```
</CodeGroup>
### Peer Search
Search across all content associated with a specific peer:
<CodeGroup>
```python Python
# Create or get a peer
alice = honcho.peer("alice")
# Search across all of Alice's messages and interactions
results = alice.search("programming")
# View results
for result in results:
print(f"Alice's content: {result}")
```
```typescript TypeScript
import { Message } from "@honcho-ai/sdk";
(async () => {
// Create or get a peer
const alice = await honcho.peer("alice");
// Search across all of Alice's messages and interactions
const results: Message[] = await alice.search("programming");
// View results
for (const result of results) {
console.log(`Alice's content: ${result.content}`);
}
})();
```
</CodeGroup>
## Filters and Limits
### Get a specific number of results
You can specify the number of results you want to return by passing the `limit` parameter to the search method. The default is 10 results, with a maximum of 100.
<CodeGroup>
```python Python
results = honcho.search("budget planning", limit=20)
```
```typescript TypeScript
(async () => {
const results = await honcho.search("budget planning", { limit: 20 });
})();
```
</CodeGroup>
### Get messages from a Peer in a specific Session
Combine Peer-level search with a `session_id` filter to get messages from a Peer in a specific Session.
<CodeGroup>
```python Python
my_peer = honcho.peer("my-peer")
my_session = honcho.session("team-meeting-jan")
results = my_peer.search("budget planning", filters={"session_id": my_session.id})
```
```typescript TypeScript
(async () => {
const my_peer = await honcho.peer("my-peer");
const my_session = await honcho.session("team-meeting-jan");
const results = await my_peer.search("budget planning", { filters: { session_id: my_session.id } });
})();
```
</CodeGroup>
Search returns an object containing an `items` array of message objects:
```json
{
"items": [
{
"id": "<string>",
"content": "<string>",
"peer_id": "<string>",
"session_id": "<string>",
"metadata": {},
"created_at": "2023-11-07T05:31:56Z",
"workspace_id": "<string>",
"token_count": 123
}
]
}
```
### Filter results by time range
<CodeGroup>
```python Python
results = honcho.search("budget planning", filters={"created_at": {"gte": "2024-01-01", "lte": "2024-01-31"}})
```
```typescript TypeScript
(async () => {
const results = await honcho.search("budget planning", { filters: { created_at: { gte: "2024-01-01", lte: "2024-01-31" } } });
})();
```
</CodeGroup>
### Filter results by metadata
<CodeGroup>
```python Python
results = honcho.search("budget planning", filters={"metadata": {"key": "value"}})
```
```typescript TypeScript
(async () => {
const results = await honcho.search("budget planning", { filters: { metadata: { key: "value" } } });
})();
```
</CodeGroup>
### Best Practices
### Handle Empty Results Gracefully
<CodeGroup>
```python Python
# Always check for empty results
results = honcho.search("very specific query")
result_list = list(results)
if result_list:
print(f"Found {len(result_list)} results")
for result in result_list:
print(f"- {result}")
else:
print("No results found - try a broader search")
```
```typescript TypeScript
import { Message } from "@honcho-ai/sdk";
(async () => {
// Always check for empty results
const results: Message[] = await honcho.search("very specific query");
if (results.length > 0) {
console.log(`Found ${results.length} results`);
for (const result of results) {
console.log(`- ${result.content}`);
}
} else {
console.log("No results found - try a broader search");
}
})();
```
</CodeGroup>
## Conclusion
Honcho's search functionality provides powerful discovery capabilities across your conversational data. By understanding how to:
- Choose the appropriate search scope (workspace, session, or peer)
- Handle paginated results effectively
- Combine search with context building
You can build applications that provide intelligent insights and context-aware responses based on historical conversations and interactions.

249
docs/v2.6.0-alpha/documentation/features/advanced/streaming-response.mdx Normal file
View File

@ -0,0 +1,249 @@
---
title: "Streaming Responses"
description: "Using streaming responses with Honcho SDKs"
icon: "wave-sine"
---
When working with AI-generated content, streaming the response as it's generated can significantly improve the user experience. Honcho provides streaming functionality in its SDKs that allows your application to display content as it's being generated, rather than waiting for the complete response.
## When to Use Streaming
Streaming is particularly useful for:
- Real-time chat interfaces
- Long-form content generation
- Applications where perceived speed is important
- Interactive agent experiences
- Reducing time-to-first-word in user interactions
## Streaming with the Dialectic Endpoint
One of the primary use cases for streaming in Honcho is with the Dialectic endpoint. This allows you to stream the AI's reasoning about a user in real-time.
### Prerequisites
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client (using the default workspace)
honcho = Honcho()
# Create or get peers
user = honcho.peer("demo-user")
assistant = honcho.peer("assistant")
# Create a new session
session = honcho.session("demo-session")
# Add peers to the session
session.add_peers([user, assistant])
# Store some messages for context (optional)
session.add_messages([
user.message("Hello, I'm testing the streaming functionality")
])
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
(async () => {
// Initialize client (using the default workspace)
const honcho = new Honcho({});
// Create or get peers
const user = await honcho.peer('demo-user');
const assistant = await honcho.peer('assistant');
// Create a new session
const session = await honcho.session('demo-session');
// Add peers to the session
await session.addPeers([user, assistant]);
// Store some messages for context (optional)
await session.addMessages([
user.message("Hello, I'm testing the streaming functionality")
]);
})();
```
</CodeGroup>
## Streaming from the Dialectic Endpoint
<CodeGroup>
```python Python
import time
# Basic streaming example
response_stream = user.chat("What can you tell me about this user?", stream=True)
for chunk in response_stream.iter_text():
print(chunk, end="", flush=True) # Print each chunk as it arrives
time.sleep(0.01) # Optional delay for demonstration
```
```typescript TypeScript
(async () => {
// Basic streaming example
const responseStream = await user.chat("What can you tell me about this user?", {
stream: true
});
// Process the stream
for await (const chunk of responseStream.iter_text()) {
process.stdout.write(chunk); // Write to console without newlines
}
})();
```
</CodeGroup>
## Working with Streaming Data
When working with streaming responses, consider these patterns:
1. **Progressive Rendering** - Update your UI as chunks arrive instead of waiting for the full response
2. **Buffered Processing** - Accumulate chunks until a logical break (like a sentence or paragraph)
3. **Token Counting** - Monitor token usage in real-time for applications with token limits
4. **Error Handling** - Implement appropriate error handling for interrupted streams
## Example: Restaurant Recommendation Chat
<CodeGroup>
```python Python
import asyncio
from honcho import Honcho
async def restaurant_recommendation_chat():
# Initialize client
honcho = Honcho()
# Create peers
user = honcho.peer("food-lover")
assistant = honcho.peer("restaurant-assistant")
# Create session
session = honcho.session("food-preferences-session")
# Add peers to session
await session.add_peers([user, assistant])
# Store multiple user messages about food preferences
user_messages = [
"I absolutely love spicy Thai food, especially curries with coconut milk.",
"Italian cuisine is another favorite - fresh pasta and wood-fired pizza are my weakness!",
"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."
]
# Add the user's messages to the session
session_messages = [user.message(message) for message in user_messages]
await session.add_messages(session_messages)
# Print the user messages
for message in user_messages:
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 using the user's peer to get recommendations
response_stream = user.chat(
"Based on this user's food preferences, recommend 3 restaurants they might enjoy in the Lower East Side.",
stream=True,
session_id=session.id
)
for chunk in response_stream.iter_text():
print(chunk, end="", flush=True)
full_response += chunk
await asyncio.sleep(0.01)
# Store the assistant's complete response
await session.add_messages([
assistant.message(full_response)
])
# Run the async function
if __name__ == "__main__":
asyncio.run(restaurant_recommendation_chat())
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
(async () => {
async function restaurantRecommendationChat() {
// Initialize client
const honcho = new Honcho({});
// Create peers
const user = await honcho.peer('food-lover');
const assistant = await honcho.peer('restaurant-assistant');
// Create session
const session = await honcho.session('food-preferences-session');
// Add peers to session
await session.addPeers([user, assistant]);
// Store multiple user messages about food preferences
const userMessages = [
"I absolutely love spicy Thai food, especially curries with coconut milk.",
"Italian cuisine is another favorite - fresh pasta and wood-fired pizza are my weakness!",
"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."
];
// Add the user's messages to the session
const sessionMessages = userMessages.map(message => user.message(message));
await session.addMessages(sessionMessages);
// Print the user messages
for (const message of userMessages) {
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 using the user's peer to get recommendations
const responseStream = await user.chat(
"Based on this user's food preferences, recommend 3 restaurants they might enjoy in the Lower East Side.",
{
stream: true,
sessionId: session.id
}
);
for await (const chunk of responseStream.iter_text()) {
process.stdout.write(chunk);
fullResponse += chunk;
}
// Store the assistant's complete response
await session.addMessages([
assistant.message(fullResponse)
]);
}
await restaurantRecommendationChat();
})();
```
</CodeGroup>
## Performance Considerations
When implementing streaming:
- Consider connection stability for mobile or unreliable networks
- Implement appropriate timeouts for stream operations
- 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.

49
docs/v2.6.0-alpha/documentation/features/advanced/summarizer.mdx Normal file
View File

@ -0,0 +1,49 @@
---
title: 'Summarizer'
description: 'How Honcho creates summaries of conversations'
icon: 'compress'
---
Almost all agents require, in addition to personalization and memory, a way to quickly prime a context window with a summary of the conversation (in Honcho, this is equivalent to a `session`). The general strategy for summarization is to combine a list of recent messages verbatim with a compressed LLM-generated summary of the older messages not included. Implementing this correctly, in such a way that the resulting context is:
* Exhaustive: the combination of recent messages and summary should cover the entire conversation
* Dynamically sized: the tokens used on both summary and recent messages should be malleable based on desired token usage
* Performant: while creation of the summary by LLM introduces necessary latency, this should never add latency to an arbitrary end-user request
...is a non-trivial problem. Summarization should not be necessary to re-implement for every new agent you build, so Honcho comes with a built-in solution.
### Creating Summaries
Honcho already has an asynchronous task queue for the purpose of deriving facts from messages. This is the ideal place to create summaries where they won't add latency to a message. Currently, Honcho has two configurable summary types:
* Short summaries: by default, enqueued every 20 messages and given a token limit of 1000
* Long summaries: by default, enqueued every 60 messages and given a token limit of 4000
Both summaries are designed to be exhaustive: when enqueued, they are given the *prior* summary of their type plus every message after that summary. This recursive compression process naturally biases the summary towards recent messages while still covering the entire conversation.
For example, if message 160 in a conversation triggers a short summary, as it would with default settings, the summary task would retrieve the prior short summary (message 140) plus messages 141-160. It would then produce a summary of messages 0-160 and store that in the short summary slot on the session. Every session has a single slot for each summary type: new summaries replace old ones.
It's important to keep in mind that summary tasks run in the background and are not guaranteed to complete before the next message. However, they are guaranteed to complete in order, so that if a user saves 100 messages in a single batch, the short summary will first be created for messages 0-20, then 21-40, and so on, in our desired recursive way.
### Retrieving Summaries
Summaries are retrieved from the session by the `get_context` method. This method has two parameters:
* `summary`: A boolean indicating whether to include the summary in the return type. The default is true.
* `tokens`: An integer indicating the maximum number of tokens to use for the context. **If not provided, `get_context` will retrieve as many tokens as are required to create exhaustive conversation coverage.**
The return type is simply a list of recent messages and a summary if the flag is used. These two components are dynamically sized based on the token limit. Combined, they will always be below the given token limit. Honcho reserves 60% of the context size for recent messages and 40% for the summary.
There's a critical trade-off to understand between exhaustiveness and token usage. Let's go through some scenarios:
* If the *last message* contains more tokens than the context token limit, no summary *or* message list is possible -- both will be empty.
* If the *last few messages* contain more tokens than the context token limit, no summary is possible -- the context will only contain the last 1 or 2 messages that fit in the token limit.
* If the summaries contain more tokens than the context token limit, no summary is possible -- the context will only contain the X most recent messages that fit in the token limit. Note that while summaries will often be smaller than their token limits, avoiding this scenario means passing a higher token limit than the Honcho-configured summary size(s). For this reason, the default token limit for `get_context` is a few times larger than the configured long summary size.
The above scenarios indicate where summarization is not possible -- therefore, the context retrieved will almost certainly **not** be exhaustive.
Sometimes, gaps in context aren't an issue. In these cases, it's best to pass a reasonable token limit depending on your needs. Other cases demand exhaustive context -- don't pass a token limit and just let Honcho retrieve the ideal combination of summary and recent messages. Finally, if you don't care about the conversation at large and just want the last few messages, set `summary` to false and `tokens` to some multiple of your desired message count. Note that context messages are not paginated, so there's a hard limit on the number of messages that can be retrieved (currently 100,000 tokens).
As a final note, remember that summaries are generated asynchronously and therefore may not be available immediately. If you batch-save a large number of messages, assume that summaries will not be available until those messages are processed, which can take seconds to minutes depending on the number of messages and the configured LLM provider. Exhaustive `get_context` calls performed during this time will likely just return the messages in the session.

331
docs/v2.6.0-alpha/documentation/features/advanced/toggle-reasoning.mdx Normal file
View File

@ -0,0 +1,331 @@
---
title: 'Toggle Reasoning'
description: 'Customize how Honcho reasons over peers, sessions, and messages'
icon: 'wrench'
---
Honcho's reasoning can be configured at multiple levels to control how it processes messages, generates conclusions, creates summaries, and builds peer representations.
Configuration follows a hierarchy: **message > session > workspace > global defaults**. Settings at lower levels override those at higher levels, giving you fine-grained control over behavior.
## Configuration Hierarchy
Honcho uses a hierarchical configuration system where more specific settings override more general ones:
1. **Global Defaults**: Built-in system defaults
2. **Workspace Configuration**: Settings that apply to all sessions in a workspace
3. **Session Configuration**: Settings that apply to all messages in a session
4. **Message Configuration**: Settings that apply to a specific message
Separately, you can configure the reasoning status of a peer. This overrides defaults and workspace configuration, but not session or message configuration.
<Info>
All configuration fields are optional. If not specified, the value is inherited from the next level up in the hierarchy.
</Info>
## Configuration Options
### Reasoning Configuration
Controls whether the system should reason over messages.
| Field | Type | Description |
|-------|------|-------------|
| `enabled` | `bool` | Whether to enable reasoning functionality. When disabled, no facts or representations are generated. |
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho()
# Disable reasoning at session level
session = honcho.session("private-session", config={
"reasoning": {"enabled": False}
})
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
const honcho = new Honcho({});
// Disable reasoning at session level
const session = await honcho.session("private-session", {
config: {
reasoning: { enabled: false }
}
});
```
</CodeGroup>
### Peer Card Configuration
Controls how peer cards (containing key biographical information) are generated and used.
| Field | Type | Description |
|-------|------|-------------|
| `use` | `bool` | Whether to use peer cards during the reasoning process. |
| `create` | `bool` | Whether to generate and update peer cards based on message content. |
<CodeGroup>
```python Python
# Disable peer card generation but still use existing cards
session = honcho.session("my-session", config={
"peer_card": {"create": False, "use": True}
})
```
```typescript TypeScript
// Disable peer card generation but still use existing cards
const session = await honcho.session("my-session", {
config: {
peer_card: { create: false, use: true }
}
});
```
</CodeGroup>
### Summary Configuration
Controls automatic conversation summarization. Available at workspace and session levels only.
| Field | Type | Description |
|-------|------|-------------|
| `enabled` | `bool` | Whether to enable summary functionality. |
| `messages_per_short_summary` | `int` | Number of messages between short summaries. Must be ≥ 10. |
| `messages_per_long_summary` | `int` | Number of messages between long summaries. Must be ≥ 20 and greater than `messages_per_short_summary`. |
<CodeGroup>
```python Python
# Customize summary frequency
session = honcho.session("verbose-session", config={
"summary": {
"enabled": True,
"messages_per_short_summary": 15,
"messages_per_long_summary": 45
}
})
```
```typescript TypeScript
// Customize summary frequency
const session = await honcho.session("verbose-session", {
config: {
summary: {
enabled: true,
messages_per_short_summary: 15,
messages_per_long_summary: 45
}
}
});
```
</CodeGroup>
### Dream Configuration
Controls the "dreaming" process that consolidates and refines representations. Available at workspace and session levels only.
| Field | Type | Description |
|-------|------|-------------|
| `enabled` | `bool` | Whether to enable dream functionality. Automatically disabled if reasoning is disabled. |
<CodeGroup>
```python Python
# Disable dreams for a workspace
honcho.set_config({
"dream": {
"enabled": False
}
})
```
```typescript TypeScript
// Disable dreams for a workspace
await honcho.setConfig({
dream: {
enabled: false
}
});
```
</CodeGroup>
---
## Peer Configuration
By default, all peers are "observed" by Honcho. This means that Honcho will reason over messages sent by the peer and generate a representation of them. In most cases, this is why you use Honcho! However, sometimes an application requires a peer that should not be observed: for example, an assistant or game NPC that your program will never need to access advanced reasoning for.
You may therefore disable observation of a peer by setting the `observe_me` flag in their configuration to `false`.
If the peer has a session-level configuration, it will override this configuration. If the flag is not set, or is set to `true`, the peer will be observed.
<Info>
For session-level observation controls and local representations (where peers build separate models of each other), see [Representation Scopes](/v2/documentation/features/advanced/representation-scopes).
</Info>
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho()
# Create peer with configuration
peer = honcho.peer("my-peer", config={"observe_me": False})
# Change peer's configuration
peer.set_config({"observe_me": True})
# Note: creating the same peer again will also replace the configuration
peer = honcho.peer("my-peer", config={"observe_me": False})
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
(async () => {
// Initialize client
const honcho = new Honcho({});
// Create peer with configuration
const peer = await honcho.peer("my-peer", { config: { observe_me: false } });
// Change peer's configuration
await peer.setConfig({ observe_me: true });
// Note: creating the same peer again will also replace the configuration
await honcho.peer("my-peer", { config: { observe_me: false } });
})();
```
</CodeGroup>
## Session Configuration
Sessions support the full configuration schema. You can disable reasoning entirely for a session, customize summary behavior, or adjust peer card settings.
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho()
# Create session with reasoning disabled
session = honcho.session("my-session", config={
"reasoning": {"enabled": False}
})
# Create session with custom summary settings
session = honcho.session("detailed-session", config={
"summary": {
"messages_per_short_summary": 10,
"messages_per_long_summary": 30
}
})
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
(async () => {
// Initialize client
const honcho = new Honcho({});
// Create session with reasoning disabled
const session = await honcho.session("my-session", {
config: { reasoning: { enabled: false } }
});
// Create session with custom summary settings
const detailedSession = await honcho.session("detailed-session", {
config: {
summary: {
messages_per_short_summary: 10,
messages_per_long_summary: 30
}
}
});
})();
```
</CodeGroup>
## Message Configuration
Individual messages can override session and workspace configuration for fine-grained control. This is useful for excluding specific messages from processing or adjusting behavior on a per-message basis.
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho()
session = honcho.session("my-session")
user = honcho.peer("user")
# Create a message that skips the reasoning process
session.add_messages([
user.message("This message won't be analyzed", config={
"reasoning": {"enabled": False}
})
])
# Create a message with custom peer card settings
session.add_messages([
user.message("Use existing card but don't update it", config={
"peer_card": {"use": True, "create": False}
})
])
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
(async () => {
const honcho = new Honcho({});
const session = await honcho.session("my-session");
const user = await honcho.peer("user");
// Create a message that skips the reasoning process
await session.addMessages([
user.message("This message won't be analyzed", {
configuration: { reasoning: { enabled: false } }
})
]);
})();
```
</CodeGroup>
## Full Configuration Schema Reference
### Workspace & Session Configuration
```json
{
"reasoning": {
"enabled": true
},
"peer_card": {
"use": true,
"create": true
},
"summary": {
"enabled": true,
"messages_per_short_summary": 20,
"messages_per_long_summary": 60
},
"dream": {
"enabled": true
}
}
```
### Message Configuration
```json
{
"reasoning": {
"enabled": true
},
"peer_card": {
"use": true,
"create": true
}
}
```
<Note>
Message configuration only supports reasoning and `peer_card` settings. Summary and dream configurations are session/workspace-level only.
</Note>

683
docs/v2.6.0-alpha/documentation/features/advanced/using-filters.mdx Normal file
View File

@ -0,0 +1,683 @@
---
title: 'Using Filters'
description: "Learn how to filter workspaces, peers, sessions, and messages using Honcho's powerful filtering system"
icon: 'filter'
---
Honcho provides a sophisticated filtering system that allows you to query workspaces, peers, sessions, and messages with precise control. The filtering system supports logical operators, comparison operators, metadata filtering, and wildcards to help you find exactly what you need.
## Basic Filtering Concepts
Filters in Honcho are expressed as dictionaries that define conditions for matching resources. The system supports both simple equality filters and complex queries with multiple conditions.
### Simple Filters
The most basic filters check for exact matches:
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho()
# Simple peer filter
peers = honcho.get_peers(filters={"peer_id": "alice"})
# Simple session filter with metadata
sessions = honcho.get_sessions(filters={
"metadata": {"type": "support"}
})
# Simple message filter
messages = honcho.get_messages(filters={
"session_id": "support-chat-1",
"peer_id": "alice"
})
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
(async () => {
// Initialize client
const honcho = new Honcho({});
// Simple peer filter
const peers = await honcho.getPeers({
filters: { peerId: "alice" }
});
// Simple session filter with metadata
const sessions = await honcho.getSessions({
filters: {
metadata: { type: "support" }
}
});
// Simple message filter
const messages = await honcho.getMessages({
filters: {
sessionId: "support-chat-1",
peerId: "alice"
}
});
})();
```
</CodeGroup>
## Logical Operators
Combine multiple conditions using logical operators for complex queries:
### AND Operator
Use AND to require all conditions to be true:
<CodeGroup>
```python Python
messages = honcho.get_messages(filters={
"AND": [
{"session_id": "chat-1"},
{"created_at": {"gte": "2024-01-01"}}
]
})
```
```typescript TypeScript
(async () => {
const messages = await honcho.getMessages({
filters: {
AND: [
{ sessionId: "chat-1" },
{ createdAt: { gte: "2024-01-01" } }
]
}
});
})();
```
</CodeGroup>
### OR Operator
Use OR to match any of the specified conditions:
<CodeGroup>
```python Python
# Find messages from either alice or bob
messages = session.get_messages(filters={
"OR": [
{"peer_id": "alice"},
{"peer_id": "bob"}
]
})
# Complex OR with metadata conditions
sessions = honcho.get_sessions(filters={
"OR": [
{"metadata": {"priority": "high"}},
{"metadata": {"urgent": True}},
{"metadata": {"escalated": True}}
]
})
```
```typescript TypeScript
(async () => {
// Find messages from either alice or bob
const messages = await session.getMessages({
filters: {
OR: [
{ peerId: "alice" },
{ peerId: "bob" }
]
}
});
// Complex OR with metadata conditions
const sessions = await honcho.getSessions({
filters: {
OR: [
{ metadata: { priority: "high" } },
{ metadata: { urgent: true } },
{ metadata: { escalated: true } }
]
}
});
})();
```
</CodeGroup>
### NOT Operator
Use NOT to exclude specific conditions:
<CodeGroup>
```python Python
# Find all peers except alice
peers = honcho.get_peers(filters={
"NOT": [
{"peer_id": "alice"}
]
})
# Find sessions that are NOT completed
sessions = honcho.get_sessions(filters={
"NOT": [
{"metadata": {"status": "completed"}}
]
})
```
```typescript TypeScript
(async () => {
// Find all peers except alice
const peers = await honcho.getPeers({
filters: {
NOT: [
{ peerId: "alice" }
]
}
});
// Find sessions that are NOT completed
const sessions = await honcho.getSessions({
filters: {
NOT: [
{ metadata: { status: "completed" } }
]
}
});
})();
```
</CodeGroup>
### Combining Logical Operators
Create sophisticated queries by combining different logical operators:
<CodeGroup>
```python Python
# Find messages from alice OR bob, but NOT where message has archived set to true in metadata
messages = session.get_messages(filters={
"AND": [
{
"OR": [
{"peer_id": "alice"},
{"peer_id": "bob"}
]
},
{
"NOT": [
{"metadata": {"archived": True}}
]
}
]
})
```
```typescript TypeScript
(async () => {
// Find messages from alice OR bob, but NOT where message has archived set to true in metadata
const messages = await session.getMessages({
filters: {
AND: [
{
OR: [
{ peerId: "alice" },
{ peerId: "bob" }
]
},
{
NOT: [
{ metadata: { archived: true } }
]
}
]
}
});
})();
```
</CodeGroup>
## Comparison Operators
Use comparison operators for range queries and advanced matching:
### Numeric Comparisons
<CodeGroup>
```python Python
# Find sessions created after a specific date
sessions = honcho.get_sessions(filters={
"created_at": {"gte": "2024-01-01"}
})
# Find messages within a date range
messages = session.get_messages(filters={
"created_at": {
"gte": "2024-01-01",
"lte": "2024-12-31"
}
})
# Metadata numeric comparisons
sessions = honcho.get_sessions(filters={
"metadata": {
"score": {"gt": 8.5},
"duration": {"lte": 3600}
}
})
```
```typescript TypeScript
(async () => {
// Find sessions created after a specific date
const sessions = await honcho.getSessions({
filters: {
createdAt: { gte: "2024-01-01" }
}
});
// Find messages within a date range
const messages = await session.getMessages({
filters: {
createdAt: {
gte: "2024-01-01",
lte: "2024-12-31"
}
}
});
// Metadata numeric comparisons
const sessions = await honcho.getSessions({
filters: {
metadata: {
score: { gt: 8.5 },
duration: { lte: 3600 }
}
}
});
})();
```
</CodeGroup>
### List Membership
<CodeGroup>
```python Python
# Find messages from specific peers in a session
messages = session.get_messages(filters={
"peer_id": {"in": ["alice", "bob", "charlie"]}
})
# Find sessions with specific tags
sessions = honcho.get_sessions(filters={
"metadata": {
"tag": {"in": ["important", "urgent", "follow-up"]}
}
})
# Not equal comparisons
peers = honcho.get_peers(filters={
"metadata": {
"status": {"ne": "inactive"}
}
})
```
```typescript TypeScript
(async () => {
// Find messages from specific peers in a session
const messages = await session.getMessages({
filters: {
peerId: { in: ["alice", "bob", "charlie"] }
}
});
// Find sessions with specific tags
const sessions = await honcho.getSessions({
filters: {
metadata: {
tag: { in: ["important", "urgent", "follow-up"] }
}
}
});
// Not equal comparisons
const peers = await honcho.getPeers({
filters: {
metadata: {
status: { ne: "inactive" }
}
}
});
})();
```
</CodeGroup>
## Metadata Filtering
Metadata filtering is particularly powerful in Honcho, supporting nested conditions and complex queries:
### Basic Metadata Filtering
<CodeGroup>
```python Python
# Simple metadata equality
sessions = honcho.get_sessions(filters={
"metadata": {
"type": "customer_support",
"priority": "high"
}
})
# Nested metadata objects
peers = honcho.get_peers(filters={
"metadata": {
"profile": {
"role": "admin",
"department": "engineering"
}
}
})
```
```typescript TypeScript
(async () => {
// Simple metadata equality
const sessions = await honcho.getSessions({
filters: {
metadata: {
type: "customer_support",
priority: "high"
}
}
});
// Nested metadata objects
const peers = await honcho.getPeers({
filters: {
metadata: {
profile: {
role: "admin",
department: "engineering"
}
}
}
});
})();
```
</CodeGroup>
### Advanced Metadata Queries
<Info>
If you want to do advanced queries like these, make sure not to create metadata fields that use the same names as the included comparison operators! For example, if you have a metadata field called `contains`, it will conflict with the `contains` operator.
</Info>
<CodeGroup>
```python Python
# Metadata with comparison operators
sessions = honcho.get_sessions(filters={
"metadata": {
"score": {"gte": 4.0, "lte": 5.0},
"created_by": {"ne": "system"},
"tags": {"contains": "important"}
}
})
# Complex metadata conditions
messages = session.get_messages(filters={
"AND": [
{"metadata": {"sentiment": {"in": ["positive", "neutral"]}}},
{"metadata": {"confidence": {"gt": 0.8}}},
{"content": {"icontains": "thank"}}
]
})
```
```typescript TypeScript
(async () => {
// Metadata with comparison operators
const sessions = await honcho.getSessions({
filters: {
metadata: {
score: { gte: 4.0, lte: 5.0 },
createdBy: { ne: "system" },
tags: { contains: "important" }
}
}
});
// Complex metadata conditions
const messages = await session.getMessages({
filters: {
AND: [
{ metadata: { sentiment: { in: ["positive", "neutral"] } } },
{ metadata: { confidence: { gt: 0.8 } } },
{ content: { icontains: "thank" } }
]
}
});
})();
```
</CodeGroup>
## Wildcards
Use wildcards (*) to match any value for a field:
<CodeGroup>
```python Python
# Find all sessions with any peer_id (essentially all sessions)
sessions = honcho.get_sessions(filters={
"peer_id": "*"
})
# Wildcard in lists - matches everything
messages = session.get_messages(filters={
"peer_id": {"in": ["alice", "bob", "*"]}
})
# Metadata wildcards
sessions = honcho.get_sessions(filters={
"metadata": {
"type": "*", # Any type
"status": "active" # But status must be active
}
})
```
```typescript TypeScript
(async () => {
// Find all sessions with any peer_id (essentially all sessions)
const sessions = await honcho.getSessions({
filters: {
peerId: "*"
}
});
// Wildcard in lists - matches everything
const messages = await session.getMessages({
filters: {
peerId: { in: ["alice", "bob", "*"] }
}
});
// Metadata wildcards
const sessions = await honcho.getSessions({
filters: {
metadata: {
type: "*", // Any type
status: "active" // But status must be active
}
}
});
})();
```
</CodeGroup>
## Resource-Specific Examples
### Filtering Workspaces
<CodeGroup>
```python Python
# Find workspaces by name pattern
workspaces = honcho.get_workspaces(filters={
"name": {"contains": "prod"}
})
# Filter by metadata
workspaces = honcho.get_workspaces(filters={
"metadata": {
"environment": "production",
"team": {"in": ["backend", "frontend", "devops"]}
}
})
```
```typescript TypeScript
(async () => {
// Find workspaces by name pattern
const workspaces = await honcho.getWorkspaces({
filters: {
name: { contains: "prod" }
}
});
// Filter by metadata
const workspaces = await honcho.getWorkspaces({
filters: {
metadata: {
environment: "production",
team: { in: ["backend", "frontend", "devops"] }
}
}
});
})();
```
</CodeGroup>
### Filtering Messages
<CodeGroup>
```python Python
# Find error messages from the last week
from datetime import datetime, timedelta
week_ago = (datetime.now() - timedelta(days=7)).isoformat()
messages = session.get_messages(filters={
"AND": [
{"content": {"icontains": "error"}},
{"created_at": {"gte": week_ago}},
{"metadata": {"level": {"in": ["error", "critical"]}}}
]
})
# Find messages in specific sessions with sentiment analysis
messages = session.get_messages(filters={
"AND": [
{"session_id": {"in": ["support-1", "support-2", "support-3"]}},
{"metadata": {"sentiment": "negative"}},
{"metadata": {"confidence": {"gte": 0.7}}}
]
})
```
```typescript TypeScript
(async () => {
// Find error messages from the last week
const weekAgo = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000).toISOString();
const messages = await session.getMessages({
filters: {
AND: [
{ content: { icontains: "error" } },
{ createdAt: { gte: weekAgo } },
{ metadata: { level: { in: ["error", "critical"] } } }
]
}
});
// Find messages in specific sessions with sentiment analysis
const messages = await session.getMessages({
filters: {
AND: [
{ sessionId: { in: ["support-1", "support-2", "support-3"] } },
{ metadata: { sentiment: "negative" } },
{ metadata: { confidence: { gte: 0.7 } } }
]
}
});
})();
```
</CodeGroup>
## Error Handling
Handle filter errors gracefully:
<CodeGroup>
```python Python
from honcho.exceptions import FilterError
try:
# Invalid filter - unsupported operator
messages = session.get_messages(filters={
"created_at": {"invalid_operator": "2024-01-01"}
})
except FilterError as e:
print(f"Filter error: {e}")
# Handle the error appropriately
try:
# Invalid column name
sessions = honcho.get_sessions(filters={
"nonexistent_field": "value"
})
except FilterError as e:
print(f"Invalid field: {e}")
```
```typescript TypeScript
(async () => {
try {
// Invalid filter - unsupported operator
const messages = await session.getMessages({
filters: {
createdAt: { invalidOperator: "2024-01-01" }
}
});
} catch (error) {
if (error.message.includes("filters")) {
console.error(`Filter error: ${error.message}`);
// Handle the error appropriately
}
}
try {
// Invalid column name
const sessions = await honcho.getSessions({
filters: {
nonexistentField: "value"
}
});
} catch (error) {
console.error(`Invalid field: ${error.message}`);
}
})();
```
</CodeGroup>
## Conclusion
Honcho's filtering system provides powerful capabilities for querying your conversational data. By understanding how to:
- Use simple equality filters and complex logical operators
- Apply comparison operators for range and pattern matching
- Filter metadata with nested conditions
- Handle wildcards and dynamic filter construction
- Follow best practices for performance and validation
You can build sophisticated applications that efficiently find and process exactly the conversations, messages, and insights you need from your Honcho data.

191
docs/v2.6.0-alpha/documentation/features/chat.mdx Normal file
View File

@ -0,0 +1,191 @@
---
title: "Chat Endpoint"
description: "An endpoint for reasoning about your users"
sidebarTitle: "Chat Endpoint"
icon: "message-question"
---
The Chat endpoint (`peer.chat()`) is the natural language interface to Honcho's reasoning. Instead of manually retrieving conclusions, your LLM can ask questions and get synthesized answers based on all the reasoning Honcho has done about a peer. Think of it as agent-to-agent communication.
## Basic Usage
The simplest way to use the chat endpoint is to ask a question and get a text response:
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho()
peer = honcho.peer("user-123")
# Ask Honcho about the peer
query = "What is the user's favorite way of completing the task?"
answer = peer.chat(query)
print(answer)
# "Based on observations, the user prefers using keyboard shortcuts..."
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
const honcho = new Honcho({});
const peer = await honcho.peer("user-123");
// Ask Honcho about the peer
const query = "What is the user's favorite way of completing the task?";
const answer = await peer.chat(query);
console.log(answer);
// "Based on observations, the user prefers using keyboard shortcuts..."
```
</CodeGroup>
The chat endpoint searches through the peer's representation--all the conclusions Honcho has reasoned about them--and synthesizes a natural language answer.
## Streaming Responses
For longer answers, use streaming to get incremental responses:
<CodeGroup>
```python Python
query = "What do we know about the user?"
response_stream = peer.chat(query, stream=True)
for chunk in response_stream.iter_text():
print(chunk, end="", flush=True)
```
```typescript TypeScript
const query = "What do we know about the user?";
const responseStream = await peer.chat(query, { stream: true });
for await (const chunk of responseStream.iter_text()) {
process.stdout.write(chunk);
}
```
</CodeGroup>
Streaming is useful for displaying real-time responses in chat interfaces or when asking complex questions that require longer answers.
## Integration Patterns
### Dynamic Prompt Enhancement
Let your LLM decide what it needs to know, then inject that context into the next generation:
<CodeGroup>
```python Python
# Your LLM generates a query based on the conversation
llm_query = "Does the user prefer formal or casual communication?"
# Get answer from Honcho
context = peer.chat(llm_query)
# Add to your next LLM prompt
enhanced_prompt = f"""
Context about the user: {context}
User message: {user_input}
Respond appropriately based on the context.
"""
```
```typescript TypeScript
// Your LLM generates a query based on the conversation
const llmQuery = "Does the user prefer formal or casual communication?";
// Get answer from Honcho
const context = await peer.chat(llmQuery);
// Add to your next LLM prompt
const enhancedPrompt = `
Context about the user: ${context}
User message: ${userInput}
Respond appropriately based on the context.
`;
```
</CodeGroup>
### Conditional Logic
Use chat endpoint responses to drive application logic:
<CodeGroup>
```python Python
# Check if user has completed onboarding
onboarding_status = peer.chat("Has the user completed the onboarding flow?")
if "yes" in onboarding_status.lower():
# Show main interface
pass
else:
# Show onboarding
pass
```
```typescript TypeScript
// Check if user has completed onboarding
const onboardingStatus = await peer.chat("Has the user completed the onboarding flow?");
if (onboardingStatus.toLowerCase().includes("yes")) {
// Show main interface
} else {
// Show onboarding
}
```
</CodeGroup>
### Preference Extraction
Extract specific preferences for personalization:
<CodeGroup>
```python Python
# Get multiple insights
tone = peer.chat("What tone does the user prefer in responses?")
expertise = peer.chat("What is the user's level of technical expertise?")
goals = peer.chat("What are the user's main goals or objectives?")
# Use these to configure your agent's behavior
```
```typescript TypeScript
// Get multiple insights
const tone = await peer.chat("What tone does the user prefer in responses?");
const expertise = await peer.chat("What is the user's level of technical expertise?");
const goals = await peer.chat("What are the user's main goals or objectives?");
// Use these to configure your agent's behavior
```
</CodeGroup>
## How Honcho Answers
When you call `peer.chat(query)`:
1. Honcho searches through the peer's peer card and representation--conclusions drawn from reasoning over their messages
2. Retrieves conclusions semantically relevant to your query
3. Combines them with segments of source messages, if needed, to gather more context
4. Synthesizes them into a coherent natural language response to your query
Honcho [reasoning](/v2/documentation/core-concepts/reasoning) runs continuously in the background, processing new messages and updating representations. The chat endpoint always has access to Honcho's latest conclusions about the peer.
## Best Practices
### Ask specific questions
Instead of "Tell me about the user", ask "What communication style does the user prefer?" You'll get more actionable answers.
### Let your LLM formulate queries
The chat endpoint shines when your LLM decides what it needs to know. This creates dynamic, context-aware personalization. An excellent way to achieve this, if building an agent, is to give access to the Honcho chat endpoint as just another tool.
### Use for runtime decisions
Don't just use chat for LLM prompts - use it to drive application logic, routing, and feature flags based on user behavior.
### Combine with get_context()
Use `get_context()` for conversation context and `peer.chat()` for specific insights. They complement each other.
For more ideas on using the chat endpoint, see our [guides](/v2/guides/overview).

652
docs/v2.6.0-alpha/documentation/features/get-context.mdx Normal file
View File

@ -0,0 +1,652 @@
---
title: 'Get Context'
description: 'Learn how to use get_context() to retrieve and format conversation context for LLM integration'
icon: 'messages'
---
The `get_context()` method is a powerful feature that retrieves formatted conversation context from sessions, making it easy to integrate with LLMs like OpenAI, Anthropic, and others. This guide covers everything you need to know about working with session context.
By default, the context includes a blend of summary and messages which covers the entire history of the session. Summaries are automatically generated at intervals and recent messages are included depending on how many tokens the context is intended to be. You can specify any token limit you want, and can disable summaries to fill that limit entirely with recent messages. To get representation data, you need to specify a target peer.
## Basic Usage
The `get_context()` method is available on all Session objects and returns a `SessionContext` that contains the formatted conversation history.
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client and create session
honcho = Honcho()
session = honcho.session("conversation-1")
# Get basic context (not very useful before adding any messages!)
context = session.get_context()
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
(async () => {
// Initialize client and create session
const honcho = new Honcho({});
const session = await honcho.session("conversation-1");
// Get basic context (not very useful before adding any messages!)
const context = await session.getContext();
})();
```
</CodeGroup>
## Context Parameters
The `get_context()` method accepts several optional parameters to customize the retrieved context:
### Token Limits
Control the size of the context by setting a maximum token count:
<CodeGroup>
```python Python
# Limit context to 1500 tokens
context = session.get_context(tokens=1500)
# Limit context to 3000 tokens for larger conversations
context = session.get_context(tokens=3000)
```
```typescript TypeScript
(async () => {
// Limit context to 1500 tokens
const context = await session.getContext({ tokens: 1500 });
// Limit context to 3000 tokens for larger conversations
const context = await session.getContext({ tokens: 3000 });
})();
```
</CodeGroup>
### Summary Mode
Enable summary mode (on by default) to get a condensed version of the conversation:
<CodeGroup>
```python Python
# Get context with summary enabled -- will contain both summary and messages
context = session.get_context(summary=True)
# Combine summary=False with token limits to get more messages
context = session.get_context(summary=False, tokens=2000)
```
```typescript TypeScript
(async () => {
// Get context with summary enabled -- will contain both summary and messages
const context = await session.getContext({ summary: true });
// Combine summary=False with token limits to get more messages
const context = await session.getContext({
summary: false,
tokens: 2000
});
})();
```
</CodeGroup>
### Peer Representation in Context
You can include a peer's [representation](/v2/documentation/core-concepts/representation) and peer card in the context by specifying `peer_target`. This is useful for providing the LLM with knowledge about a specific peer.
<CodeGroup>
```python Python
# Get context with peer representation included
context = session.get_context(
tokens=2000,
peer_target="user-123" # Include representation of user-123
)
# Access the representation and peer card
print(context.peer_representation) # String representation
print(context.peer_card) # List of peer card items
# Get representation from a specific peer's perspective
context = session.get_context(
tokens=2000,
peer_target="user-123",
peer_perspective="assistant" # From assistant's viewpoint
)
```
```typescript TypeScript
(async () => {
// Get context with peer representation included
const context = await session.getContext({
tokens: 2000,
peerTarget: "user-123" // Include representation of user-123
});
// Access the representation and peer card
console.log(context.peerRepresentation); // String representation
console.log(context.peerCard); // Array of peer card items
// Get representation from a specific peer's perspective
const perspectiveContext = await session.getContext({
tokens: 2000,
peerTarget: "user-123",
peerPerspective: "assistant" // From assistant's viewpoint
});
})();
```
</CodeGroup>
### Semantic Search with Last Message
Use `last_user_message` to fetch semantically relevant conclusions based on the most recent message (requires `peer_target`):
<CodeGroup>
```python Python
context = session.get_context(
tokens=2000,
peer_target="user-123",
last_user_message="What are my coding preferences?",
search_top_k=10, # Number of relevant observations
search_max_distance=0.8, # Max semantic distance (0.0-1.0)
include_most_derived=True, # Include most recent observations
max_observations=25 # Cap total observations
)
```
```typescript TypeScript
(async () => {
const context = await session.getContext({
tokens: 2000,
peerTarget: "user-123",
lastUserMessage: "What are my coding preferences?",
representationOptions: {
searchTopK: 10, // Number of relevant observations
searchMaxDistance: 0.8, // Max semantic distance (0.0-1.0)
includeMostDerived: true, // Include most recent observations
maxObservations: 25 // Cap total observations
}
});
})();
```
</CodeGroup>
### Session-Scoped Representations
Use `limit_to_session` to only include observations from the current session:
<CodeGroup>
```python Python
# Get context limited to this session's observations only
context = session.get_context(
tokens=2000,
peer_target="user-123",
limit_to_session=True # Only observations from this session
)
```
```typescript TypeScript
(async () => {
// Get context limited to this session's observations only
const context = await session.getContext({
tokens: 2000,
peerTarget: "user-123",
limitToSession: true // Only observations from this session
});
})();
```
</CodeGroup>
### All Parameters Reference
| Parameter | Type | Description |
|-----------|------|-------------|
| `summary` | `bool` | Include summary in context (default: true) |
| `tokens` | `int` | Maximum tokens to include |
| `peer_target` | `str` | Peer ID to include representation for |
| `peer_perspective` | `str` | Peer ID for perspective (requires peer_target) |
| `last_user_message` | `str` | Message for semantic search (requires peer_target) |
| `limit_to_session` | `bool` | Limit to session observations only |
| `search_top_k` | `int` | Semantic search results to include (1-100) |
| `search_max_distance` | `float` | Max semantic distance (0.0-1.0) |
| `include_most_derived` | `bool` | Include most recently derived observations |
| `max_observations` | `int` | Maximum observations to include (1-100) |
## Converting to LLM Formats
The `SessionContext` object provides methods to convert the context into formats compatible with popular LLM APIs. When converting to OpenAI format, you must specify the assistant peer to format the context in such a way that the LLM can understand it.
### OpenAI Format
Convert context to OpenAI's chat completion format:
<CodeGroup>
```python Python
# Create peers
alice = honcho.peer("alice")
assistant = honcho.peer("assistant")
# Add some conversation
session.add_messages([
alice.message("What's the weather like today?"),
assistant.message("It's sunny and 75°F outside!")
])
# Get context and convert to OpenAI format
context = session.get_context()
openai_messages = context.to_openai(assistant=assistant)
# The messages are now ready for OpenAI API
print(openai_messages)
# [
# {"role": "user", "content": "What's the weather like today?"},
# {"role": "assistant", "content": "It's sunny and 75°F outside!"}
# ]
```
```typescript TypeScript
(async () => {
// Create peers
const alice = await honcho.peer("alice");
const assistant = await honcho.peer("assistant");
// Add some conversation
await session.addMessages([
alice.message("What's the weather like today?"),
assistant.message("It's sunny and 75°F outside!")
]);
// Get context and convert to OpenAI format
const context = await session.getContext();
const openaiMessages = context.toOpenAI(assistant);
// The messages are now ready for OpenAI API
console.log(openaiMessages);
// [
// {"role": "user", "content": "What's the weather like today?"},
// {"role": "assistant", "content": "It's sunny and 75°F outside!"}
// ]
})();
```
</CodeGroup>
### Anthropic Format
Convert context to Anthropic's Claude format:
<CodeGroup>
```python Python
# Get context and convert to Anthropic format
context = session.get_context()
anthropic_messages = context.to_anthropic(assistant=assistant)
# Ready for Anthropic API
print(anthropic_messages)
```
```typescript TypeScript
(async () => {
// Get context and convert to Anthropic format
const context = await session.getContext();
const anthropicMessages = context.toAnthropic(assistant);
// Ready for Anthropic API
console.log(anthropicMessages);
})();
```
</CodeGroup>
## Complete LLM Integration Examples
### Using with OpenAI
<CodeGroup>
```python Python
import openai
from honcho import Honcho
# Initialize clients
honcho = Honcho()
openai_client = openai.OpenAI()
# Set up conversation
session = honcho.session("support-chat")
user = honcho.peer("user-123")
assistant = honcho.peer("support-bot")
# Add conversation history
session.add_messages([
user.message("I'm having trouble with my account login"),
assistant.message("I can help you with that. What error message are you seeing?"),
user.message("It says 'Invalid credentials' but I'm sure my password is correct")
])
# Get context for LLM
messages = session.get_context(tokens=2000).to_openai(assistant=assistant)
# Add new user message and get AI response
messages.append({
"role": "user",
"content": "Can you reset my password?"
})
response = openai_client.chat.completions.create(
model="gpt-4",
messages=messages
)
# Add AI response back to session
session.add_messages([
user.message("Can you reset my password?"),
assistant.message(response.choices[0].message.content)
])
```
```typescript TypeScript
import OpenAI from 'openai';
import { Honcho } from "@honcho-ai/sdk";
(async () => {
// Initialize clients
const honcho = new Honcho({});
const openai = new OpenAI();
// Set up conversation
const session = await honcho.session("support-chat");
const user = await honcho.peer("user-123");
const assistant = await honcho.peer("support-bot");
// Add conversation history
await session.addMessages([
user.message("I'm having trouble with my account login"),
assistant.message("I can help you with that. What error message are you seeing?"),
user.message("It says 'Invalid credentials' but I'm sure my password is correct")
]);
// Get context for LLM
const messages = await session.getContext({ tokens: 2000 }).toOpenAI(assistant);
// Add new user message and get AI response
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [
...messages,
{ role: "user", content: "Can you reset my password?" }
]
});
// Add AI response back to session
await session.addMessages([
user.message("Can you reset my password?"),
assistant.message(response.choices[0].message.content)
]);
})();
```
</CodeGroup>
### Multi-Turn Conversation Loop
<CodeGroup>
```python Python
def chat_loop():
"""Example of a continuous chat loop using get_context()"""
session = honcho.session("chat-session")
user = honcho.peer("user")
assistant = honcho.peer("ai-assistant")
while True:
# Get user input
user_input = input("You: ")
if user_input.lower() in ['quit', 'exit']:
break
# Add user message to session
session.add_messages([user.message(user_input)])
# Get conversation context
context = session.get_context(tokens=2000)
messages = context.to_openai(assistant=assistant)
# Get AI response
response = openai_client.chat.completions.create(
model="gpt-4",
messages=messages
)
ai_response = response.choices[0].message.content
print(f"Assistant: {ai_response}")
# Add AI response to session
session.add_messages([assistant.message(ai_response)])
# Start the chat loop
chat_loop()
```
```typescript TypeScript
(async () => {
async function chatLoop() {
const session = await honcho.session("chat-session");
const user = await honcho.peer("user");
const assistant = await honcho.peer("ai-assistant");
// This would be replaced with actual user input handling in a real app
const userInputs = [
"Hello, how are you?",
"What's the weather like?",
"Tell me a joke"
];
for (const userInput of userInputs) {
console.log(`You: ${userInput}`);
// Add user message to session
await session.addMessages([user.message(userInput)]);
// Get conversation context
const context = await session.getContext({ tokens: 2000 });
const messages = context.toOpenAI(assistant);
// Get AI response
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: messages
});
const aiResponse = response.choices[0].message.content;
console.log(`Assistant: ${aiResponse}`);
// Add AI response to session
await session.addMessages([assistant.message(aiResponse)]);
}
}
// Start the chat loop
await chatLoop();
})();
```
</CodeGroup>
## Advanced Context Usage
### Context with Summaries for Long Conversations
For very long conversations, use summaries to maintain context while controlling token usage:
<CodeGroup>
```python Python
# For long conversations, use summary mode
long_session = honcho.session("long-conversation")
# Get summarized context to fit within token limits
context = long_session.get_context(summary=True, tokens=1500)
messages = context.to_openai(assistant=assistant)
# This will include a summary of older messages and recent full messages
print(f"Context contains {len(messages)} formatted messages")
```
```typescript TypeScript
(async () => {
// For long conversations, use summary mode
const longSession = await honcho.session("long-conversation");
// Get summarized context to fit within token limits
const context = await longSession.getContext({
summary: true,
tokens: 1500
});
const messages = context.toOpenAI(assistant);
// This will include a summary of older messages and recent full messages
console.log(`Context contains ${messages.length} formatted messages`);
})();
```
</CodeGroup>
### Context for Different Assistant Types
You can get context formatted for different types of assistants in the same session:
<CodeGroup>
```python Python
# Create different assistant peers
chatbot = honcho.peer("chatbot")
analyzer = honcho.peer("data-analyzer")
moderator = honcho.peer("moderator")
# Get context formatted for each assistant type
chatbot_context = session.get_context().to_openai(assistant=chatbot)
analyzer_context = session.get_context().to_openai(assistant=analyzer)
moderator_context = session.get_context().to_openai(assistant=moderator)
# Each context will format the conversation from that assistant's perspective
```
```typescript TypeScript
(async () => {
// Create different assistant peers
const chatbot = await honcho.peer("chatbot");
const analyzer = await honcho.peer("data-analyzer");
const moderator = await honcho.peer("moderator");
// Get context formatted for each assistant type
const context = await session.getContext();
const chatbotContext = context.toOpenAI(chatbot);
const analyzerContext = context.toOpenAI(analyzer);
const moderatorContext = context.toOpenAI(moderator);
// Each context will format the conversation from that assistant's perspective
})();
```
</CodeGroup>
## Best Practices
### 1. Token Management
Always set appropriate token limits to control costs and ensure context fits within LLM limits:
<CodeGroup>
```python Python
# Good: Set reasonable token limits based on your model
context = session.get_context(tokens=3000) # For GPT-4
context = session.get_context(tokens=1500) # For smaller models
# Good: Use summaries for very long conversations
context = session.get_context(summary=True, tokens=2000)
```
```typescript TypeScript
(async () => {
// Good: Set reasonable token limits based on your model
const context = await session.getContext({ tokens: 3000 }); // For GPT-4
const context = await session.getContext({ tokens: 1500 }); // For smaller models
// Good: Use summaries for very long conversations
const context = await session.getContext({ summary: true, tokens: 2000 });
})();
```
</CodeGroup>
### 2. Context Caching
For applications with frequent context retrieval, consider caching context when appropriate:
<CodeGroup>
```python Python
# Cache context for multiple LLM calls within the same request
context = session.get_context(tokens=2000)
openai_messages = context.to_openai(assistant=assistant)
anthropic_messages = context.to_anthropic(assistant=assistant)
# Use the same context object for multiple format conversions
```
```typescript TypeScript
(async () => {
// Cache context for multiple LLM calls within the same request
const context = await session.getContext({ tokens: 2000 });
const openaiMessages = context.toOpenAI(assistant);
const anthropicMessages = context.toAnthropic(assistant);
// Use the same context object for multiple format conversions
})();
```
</CodeGroup>
### 3. Error Handling
Always handle potential errors when working with context:
<CodeGroup>
```python Python
try:
context = session.get_context(tokens=2000)
messages = context.to_openai(assistant=assistant)
# Use messages with LLM API
response = openai_client.chat.completions.create(
model="gpt-4",
messages=messages
)
except Exception as e:
print(f"Error getting context: {e}")
# Handle error appropriately
```
```typescript TypeScript
(async () => {
try {
const context = await session.getContext({ tokens: 2000 });
const messages = context.toOpenAI(assistant);
// Use messages with LLM API
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: messages
});
} catch (error) {
console.error(`Error getting context: ${error}`);
// Handle error appropriately
}
})();
```
</CodeGroup>
## Conclusion
The `get_context()` method is essential for integrating Honcho sessions with LLMs. By understanding how to:
- Retrieve context with appropriate parameters
- Convert context to LLM-specific formats
- Manage token limits and summaries
- Handle multi-turn conversations
You can build sophisticated AI applications that maintain conversation history and context across interactions while integrating seamlessly with popular LLM providers.

99
docs/v2.6.0-alpha/documentation/introduction/overview.mdx Normal file
View File

@ -0,0 +1,99 @@
---
title: "Honcho Overview"
icon: "brain"
sidebarTitle: "Overview"
---
Honcho is an open source memory library with a managed service for building stateful agents. Use it with any model, framework, or architecture. It enables agents to build and maintain state about any entity--users, agents, groups, ideas, and more. And because it's a continual learning system, it understands entities that change over time. Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.
<CardGroup cols={2}>
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
Sign up and start building with Honcho
</Card>
<Card title="Quickstart" icon="rocket" href="/v2/documentation/introduction/quickstart">
Build your first stateful agent in minutes
</Card>
</CardGroup>
<Note>
Honcho is a memory system that reasons. Read more on the approach [here](https://blog.plasticlabs.ai/blog/Memory-as-Reasoning).
</Note>
## Why Use Honcho?
Honcho streamlines the agent building process by offering elegant, flexible primitives for managing context. It also reasons over that context to give developers access to far richer insights only accessible through reasoning.
Take the following scenario:
- You find a use case for LLMs and build an agent around it
- It works well initially but can't maintain context across sessions
- You spend weeks engineering a RAG solution that seems to help
- Then the cycle begins...
- Users report the agent forgetting things, contradicting itself, or losing context mid-session
- You build evals to quantify the problem
- You re-engineer your entire RAG pipeline with better chunking, embeddings, retrieval strategies
- The problems shift but don't disappear
- Repeat
Eventually you realize the issue isn't engineering—-it's that you're not extracting all the latent information from your data. You need to reason exhaustively, handle contradictions, track patterns over time, and maintain coherent state. In other words, you'd need to build Honcho.
Break free from this cycle. Honcho is a general solution to context engineering, memory, and statefulness.
## How Honcho Works
Honcho has four storage primitives that work together:
```mermaid
graph LR
W[Workspaces] -->|have| P[Peers]
W -->|have| S[Sessions]
S -->|have| SM[Messages]
P <-.->|many-to-many| S
style W fill:#B6DBFF,stroke:#333,color:#000
style P fill:#B6DBFF,stroke:#333,color:#000
style S fill:#B6DBFF,stroke:#333,color:#000
style SM fill:#B6DBFF,stroke:#333,color:#000
```
- **Workspaces** - Top-level containers that isolate different applications or environments
- **Peers** - Any entity that persists but changes over time (users, agents, objects, and more)
- **Sessions** - Interaction threads between peers with temporal boundaries
- **Messages** - Units of data that trigger reasoning (conversations, events, activity, documents, and more)
When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical [*reasoning*](/v2/documentation/core-concepts/reasoning) to generate conclusions about each peer. These conclusions are stored as [*representations*](/v2/documentation/core-concepts/representation) that you can query to provide rich context for your agents.
![Honcho Architecture](/images/architecture.png)
The diagram above shows the flow: agents write messages to Honcho, which triggers reasoning that updates what's stored in representations. Developers (or agents) can then query to get additional context for their next response.
## Why Reasoning?
Traditional RAG systems retrieve what was explicitly said, but they miss what matters most—the insights only accessible by *rigorously thinking* about your data. Without reasoning, you're leaving latent information on the table. Static retrieval can't surface implicit connections, struggles when new information contradicts old data, and fails when you need to make predictions under uncertainty.
Honcho uses formal logic to extract all that latent information. This reasoning is AI-native—it performs the rigorous, compute-intensive thinking that humans struggle with, instantly and consistently. The result is memory that goes beyond simple RAG recall to provide exhaustive context for statefulness.
## Get Started
Honcho gives you maximum control over your agent's context and memory. The data model is flexible and composable, the reasoning backend is powerful yet cost-effective, and everything is built to give developers levers to manage token usage, latency, and reasoning depth.
We're just scratching the surface. Dive into the quickstart to see Honcho in action, explore the architecture to understand how it all fits together, or jump straight to building.
Welcome to Honcho. We're excited to have you at the frontier of AI with us 🫡.
<CardGroup cols={2}>
<Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
Sign up for the Honcho platform and get your API key
</Card>
<Card title="Quickstart" icon="rocket" href="/v2/documentation/introduction/quickstart">
Build your first stateful agent in minutes
</Card>
<Card title="Architecture" icon="sitemap" href="/v2/documentation/core-concepts/architecture">
Deep dive into how Honcho's primitives fit together
</Card>
<Card title="Reasoning" icon="gears" href="/v2/documentation/core-concepts/reasoning">
Learn how Honcho reasons about data to build memory
</Card>
</CardGroup>

404
docs/v2.6.0-alpha/documentation/introduction/quickstart.mdx Normal file
View File

@ -0,0 +1,404 @@
---
title: "Quickstart"
icon: "bolt"
sidebarTitle: "Quickstart"
---
Let's get started with Honcho. In this quickstart, you will:
- Set up a workspace with peers (user and assistant)
- Ingest messages from across multiple sessions
- Query the reasoning Honcho produces to get synthesized insights about the user
<Note>
Running the code below requires an API key. Create and account and get your API key at [app.honcho.dev](https://app.honcho.dev) under "API KEYS".
Every new tenant gets \$100.00 in free credits on sign up. The code below costs ~\$0.04 to run, so don't worry--still plenty of free credits for iterating.
</Note>
#### 1. Install the SDK
<CodeGroup>
```bash Python (uv)
uv add honcho-ai
```
```bash Python (pip)
pip install honcho-ai
```
```bash TypeScript (npm)
npm install @honcho-ai/sdk
```
```bash TypeScript (yarn)
yarn add @honcho-ai/sdk
```
```bash TypeScript (pnpm)
pnpm add @honcho-ai/sdk
```
</CodeGroup>
#### 2. Initialize the Client
The Honcho client is the main entry point for interacting with Honcho's API. It uses a workspace called `default` unless specified, so let's create a `first-honcho-test` workspace for this quickstart.
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho(workspace="first-honcho-test", api_key=HONCHO_API_KEY)
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
// Initialize client
const honcho = new Honcho({ workspace = "first-honcho-test", apiKey = HONCHO_API_KEY });
```
</CodeGroup>
#### 3. Create Peers
<CodeGroup>
```python Python
user = honcho.peer("user")
assistant = honcho.peer("assistant")
```
```typescript TypeScript
const user = await honcho.peer("user")
const assistant = await honcho.peer("assistant")
```
</CodeGroup>
#### 4. Add Messages to Sessions
We've generated an example conversation dataset with 14 messages across 4 sessions. At a high level, the conversation contains a user chatting with an assistant to get help debugging software infrastructure problems for work *and* jam strategy on a side project they're working on. Spoiler alert--the user is way more interested in their side project.
Create a file called `conversation.json` and add the content in the accordion below. Then we'll loop through the sessions and messages in that file and write them to Honcho.
<Accordion title="Example conversation.json">
```json Example Conversation
{
"sessions": [
{
"id": "session_1",
"messages": [
{
"role": "user",
"content": "containers getting OOM killed in CI after someone on my team updated the base image. quick fix?"
},
{
"role": "assistant",
"content": "OOM kills after a base image update usually means the new image has higher memory requirements. Quick fix: bump the memory limit in your CI config. If you need to unblock fast, you could also pin back to the previous base image version temporarily."
}
]
},
{
"id": "session_2",
"messages": [
{
"role": "user",
"content": "hey, been playing with honcho for a side project. do you know if there's a limit on how many users i can have?"
},
{
"role": "assistant",
"content": "Honcho's free tier is based on context ingested, not number of users - so you can have as many users as you want, you're just limited by how much content you're processing. What are you building?"
},
{
"role": "user",
"content": "ok so basically it's a personal finance assistant that actually remembers your situation - like it knows you're saving for a house, that you hate subscriptions, that you always regret impulse buys over $50. i've been thinking a lot about the UX, like when should it proactively bring up past context vs wait for you to ask? and how do you balance feeling \"known\" vs feeling surveilled? i have a whole notion doc on this lol"
},
{
"role": "assistant",
"content": "That's a really thoughtful approach to the personalization problem! The \"known vs surveilled\" tension is exactly right - the best experiences feel like talking to a friend who remembers, not a system that tracks. Proactive context works best when it's in service of the user's stated goals."
}
]
},
{
"id": "session_3",
"messages": [
{
"role": "user",
"content": "do i need to update docker-compose too or just the CI yaml for that memory thing"
},
{
"role": "assistant",
"content": "Just the CI yaml for the memory limit - docker-compose is separate and only matters if you're hitting the same OOM issue locally."
},
{
"role": "user",
"content": "k. oh btw 3 friends are using the finance app now, they keep asking when they can pay me lol. one of them said it's the first budgeting thing that \"gets\" her"
},
{
"role": "assistant",
"content": "That's awesome - \"when can I pay you\" is the best kind of validation. And that quote about it being the first thing that \"gets\" her is exactly the value prop of personalized memory. Sounds like you're onto something real."
}
]
},
{
"id": "session_4",
"messages": [
{
"role": "user",
"content": "if i wanted to charge like $5/mo for the finance app, would honcho's pricing still make sense at that price point? trying to figure out unit economics early"
},
{
"role": "assistant",
"content": "You should be fine at that price point. Unlike other memory frameworks that charge you to access your own data, Honcho only charges for the reasoning layer - ingestion and inference. Storage and retrieval are free. So your unit economics are mostly about how often you're synthesizing insights, not how much history you're keeping."
},
{
"role": "user",
"content": "ok interesting. wish i had more time to work on this"
},
{
"role": "assistant",
"content": "Yeah, sounds like you've got something worth making time for. The early traction is real."
}
]
}
]
}
```
</Accordion>
<CodeGroup>
```python Python
import json
# Load conversation data
with open("conversation.json", "r") as f:
data = json.load(f)
# Process each session
for session_data in data["sessions"]:
session = honcho.session(session_data["id"])
session.add_peers([user, assistant])
# Add messages with correct roles
messages = []
for msg in session_data["messages"]:
if msg["role"] == "user":
messages.append(user.message(msg["content"]))
elif msg["role"] == "assistant":
messages.append(assistant.message(msg["content"]))
session.add_messages(messages)
```
```typescript TypeScript
import * as fs from 'fs';
const data = JSON.parse(fs.readFileSync("conversation.json", "utf-8"));
for (const sessionData of data.sessions) {
const session = honcho.session(sessionData.id);
session.addPeers([user, assistant]);
const messages = sessionData.messages.map((msg: any) =>
msg.role === "user" ? user.message(msg.content) : assistant.message(msg.content)
);
session.addMessages(messages);
}
```
</CodeGroup>
#### 5. Query for Insights
Now ask Honcho what it's learned--this is where the magic happens:
<CodeGroup>
```python Python
response = user.chat("What should I know about this user? 3 sentences max")
print(response)
```
```typescript TypeScript
user.chat("What should I know about this user? 3 sentences max").then((response) => {
console.log(response);
})
```
</CodeGroup>
<Tip>
Honcho needs a short amount of time to process messages you write to it. There are several utilities to [check the status](/v2/documentation/features/advanced/queue-status) of the queue. Honcho also offers numerous ways to query reasoning to fit latency needs: see the [Get Context](/v2/documentation/features/get-context) page.
</Tip>
The response will look something like this:
> User is a personal finance app developer building a personalized finance assistant that's generating real demand (friends are already asking when they can pay). They're notably thoughtful about product design, carefully considering the UX balance between making users feel "known" versus "surveilled" when their app proactively surfaces remembered context like savings goals and spending regrets. They're business-minded and working through unit economics early, exploring a $5/month subscription model with usage-based cost structure focused on insight generation frequency rather than data storage—though they wish they had more time to dedicate to the project.
Honcho synthesizes signal by reasoning about the user to draw conclusions beyond what was explicitly stated. It identifies the user as "notably thoughtful about product design", "business-minded" from the discussion of unit economics, and surfaces the signal that they desire to work on the project more.
This is rich personal context for domain-specific agents to do what they want with.
- A life coach agent might see "they wish they had more time to dedicate to the project" and "friends are already asking when they can pay" and ask "have you thought about what it would take to go full-time?"
- A productivity agent might see the same pattern and say "let's protect your weekend time for the finance app."
- A financial advisor agent might see it and ask "what runway would you need to make the leap?"
Honcho acts almost like a detective--it reasons about new and existing evidence in order to form conclusions that can be used to make a *case*. These conclusions wait to be composed dynamically based on how you, the ~~judge~~ developer, query it. This approach is what drives our [pareto-frontier](TODO: link to evals page here) performance on memory benchmarks, and our custom models allow us to optimize speed and cost.
## Next Steps
You just saw how Honcho reasons about data to build rich peer representations. In this quickstart, you:
- Set up a workspace with peers (user and assistant)
- Ingested messages across multiple sessions
- Queried the reasoning to get synthesized insights about the user
Here's the full working code if you want to run it yourself:
<Accordion title="Full Scripts">
<CodeGroup>
```python Python
# uv sync
# uv run python test.py
import json
import time
import uuid
from honcho import Honcho
from dotenv import load_dotenv
load_dotenv()
# Initialize Honcho client with a unique workspace
workspace_id = f"docs-example-{uuid.uuid4().hex[:8]}"
honcho = Honcho(environment="production", workspace_id=workspace_id)
# Create peers to represent the user and assistant
user = honcho.peer("user")
assistant = honcho.peer("assistant")
# Load conversation data from JSON file
with open("conversation.json", "r") as f:
conversation_data = json.load(f)
# Import historical conversation sessions
for session_data in conversation_data["sessions"]:
session = honcho.session(session_data["id"])
session.add_peers([user, assistant])
# Convert messages to peer messages with correct attribution
messages = []
for msg in session_data["messages"]:
if msg["role"] == "user":
messages.append(user.message(msg["content"]))
elif msg["role"] == "assistant":
messages.append(assistant.message(msg["content"]))
session.add_messages(messages)
# Wait for Honcho to process the conversation history
def wait_for_processing():
status = honcho.get_deriver_status()
while status.pending_work_units > 0 or status.in_progress_work_units > 0:
time.sleep(1)
status = honcho.poll_deriver_status()
print("Processing conversation history...")
start_time = time.time()
wait_for_processing()
elapsed = int(time.time() - start_time)
print(f"Done in {elapsed}s! Querying user insights...\n")
# Query insights about the user based on conversation history
response = user.chat("What should I know about this user? 3 sentences max")
print(response)
```
```typescript Typescript
// npm install
// npx ts-node test.ts
import * as fs from 'fs';
import { randomUUID } from 'crypto';
import * as dotenv from 'dotenv';
import { Honcho } from '@honcho-ai/sdk';
dotenv.config();
// Initialize Honcho client with a unique workspace
const workspaceId = `docs-example-${randomUUID().slice(0, 8)}`;
const honcho = new Honcho({
environment: "production",
workspaceId,
});
// Create peers to represent the user and assistant
const user = await honcho.peer("user");
const assistant = await honcho.peer("assistant");
// Load conversation data from JSON file
const conversationData = JSON.parse(fs.readFileSync("conversation.json", "utf-8"));
// Import historical conversation sessions
for (const sessionData of conversationData.sessions) {
const session = await honcho.session(sessionData.id);
await session.addPeers([user, assistant]);
// Convert messages to peer messages with correct attribution
const messages = [];
for (const msg of sessionData.messages) {
if (msg.role === "user") {
messages.push(user.message(msg.content));
} else if (msg.role === "assistant") {
messages.push(assistant.message(msg.content));
}
}
await session.addMessages(messages);
}
// Wait for Honcho to process the conversation history
async function waitForProcessing() {
let status = await honcho.getDeriverStatus();
while (status.pendingWorkUnits > 0 || status.inProgressWorkUnits > 0) {
await new Promise(resolve => setTimeout(resolve, 1000));
status = await honcho.pollDeriverStatus();
}
}
console.log("Processing conversation history...");
const startTime = Date.now();
await waitForProcessing();
const elapsed = Math.floor((Date.now() - startTime) / 1000);
console.log(`Done in ${elapsed}s! Querying user insights...\n`);
// Query insights about the user based on conversation history
const response = await user.chat("What should I know about this user? 3 sentences max");
console.log(response);
```
</CodeGroup>
</Accordion>
From here, you can explore how to use Honcho's features in your own applications:
<CardGroup cols={2}>
<Card title="Get Context" icon="messages" href="/v2/documentation/features/get-context">
Learn how to fetch the right context for your agent's next response
</Card>
<Card title="Architecture" icon="sitemap" href="/v2/documentation/core-concepts/architecture">
Deep dive into how Honcho's primitives fit together
</Card>
<Card title="Chat Endpoint" icon="comments" href="/v2/documentation/features/chat">
Query representations with natural language
</Card>
<Card title="Guides" icon="book" href="/v2/guides/overview">
Integration patterns and advanced use cases
</Card>
</CardGroup>

59
docs/v2.6.0-alpha/documentation/introduction/vibecoding.mdx Normal file
View File

@ -0,0 +1,59 @@
---
title: "AI-Powered Honcho Setup"
icon: "wand-magic-sparkles"
description: "Universal starter prompt for building with Honcho"
sidebarTitle: 'Vibecoding Setup'
---
These docs are designed to be easily consumable by LLMs. Each page has a button that lets you copy the page as Markdown or paste directly into ChatGPT or Claude.
We follow the llms.txt standard. There are both an llms.txt and llms-full.txt available:
- [llms.txt](/llms.txt)
- [llms-full.txt](/llms-full.txt)
We also provide a starter prompt to paste into a coding assistant to quickly get started building with Honcho.
## Universal Starter Prompt
```
I want to start building with Honcho - an open source memory library for building stateful agents.
## Honcho Resources
**Documentation:**
- Main docs: https://docs.honcho.dev
- API Reference: https://docs.honcho.dev/v2/api-reference/introduction
- Quickstart: https://docs.honcho.dev/v2/documentation/introduction/quickstart
- Architecture: https://docs.honcho.dev/v2/documentation/core-concepts/architecture
**Code & Examples:**
- Core repo: https://github.com/plastic-labs/honcho
- Python SDK: https://github.com/plastic-labs/honcho-python
- TypeScript SDK: https://github.com/plastic-labs/honcho-node
- Discord bot starter: https://github.com/plastic-labs/discord-python-starter
- Telegram bot example: https://github.com/plastic-labs/telegram-python-starter
**What Honcho Does:**
Honcho is an open source memory library with a managed service for building stateful agents. It enables agents to build and maintain state about any entity--users, agents, groups, ideas, and more. Because it's a continual learning system, it understands entities that change over time.
When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical reasoning to generate conclusions about each peer. These conclusions are stored as representations that you can query to provide rich context for your agents.
**Architecture Overview:**
- Core primitives: Workspaces contain Peers (any entity that persists but changes) and Sessions (interaction threads between peers)
- Peers can observe other peers in sessions (configurable with observe_me and observe_others)
- Background reasoning processes messages to extract premises, draw conclusions, and build representations
- Representations enable continuous improvement as new messages refine existing conclusions and scaffold new ones over time
- Chat endpoint provides personalized responses based on learned context
- Supports any LLM (OpenAI, Anthropic, open source)
- Can use managed service or self-host
Please assess the resources above and ask me relevant questions to help build a well-structured application using Honcho. Consider asking about:
- What I'm trying to build
- My technical preferences and stack
- Whether I want to use the managed service or self-host
- My experience level with the technologies involved
- Specific features I need (multi-peer sessions, perspective-taking, streaming, etc.)
Once you understand my needs, help me create a working implementation with proper memory and statefulness.
```

181
docs/v2.6.0-alpha/documentation/reference/platform.mdx Normal file
View File

@ -0,0 +1,181 @@
---
title: "The Honcho Dashboard"
icon: "rocket"
description: "Build socially intelligent agents without worrying about infrastructure"
sidebarTitle: "Dashboard Overview"
---
<Card title="Sign up to start using Honcho!" icon="rocket" href="https://app.honcho.dev">
Start using the platform to manage Honcho instances for your workspace or app.
</Card>
The quickest way to begin using Honcho in production is with the
[Honcho Cloud Platform](https://app.honcho.dev). Sign up, generate an API key,
and start building with Honcho.
## 1. Go to [app.honcho.dev](https://app.honcho.dev)
Create an account to start using Honcho. If a teammate already uses Honcho, ask
them to invite you to their organization. Otherwise, you'll see a banner
prompting you to create a new one.
<div style={{ maxWidth: "400px", margin: "0 auto" }}>
<Frame>
<img src="/images/app-screenshots/welcome-to-honcho.png" alt="Honcho Platform Dashboard" loading="lazy" decoding="async" fetchpriority="low" style={{ width: "100%", height: "auto" }} />
</Frame>
</div>
Once you've created an organization, you'll be taken to the dashboard and see
the Welcome page with integration guidance and links to documentation.
<Frame>
<img src="/images/app-screenshots/get-started-copy.png" alt="Honcho Dashboard Getting Started" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
Each organization has dedicated infrastructure running to isolate your
workloads. Once you add a valid payment method under the
[Billing](https://app.honcho.dev/billing) page, your instance will turn on.
## 2. Activate your Honcho instance
Navigate to the [Billing](https://app.honcho.dev/billing) page to add a payment method. Your Honcho instance provisions automatically, and you can monitor the deployment on the [Instance Status](https://app.honcho.dev/status) page until all systems show a green check mark.
<Frame>
<img src="/images/app-screenshots/status-page.png" alt="Instance Status Page" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
You can also upgrade Honcho when new versions are made available directly from the status page.
<div style={{ maxWidth: "700px", margin: "0 auto" }}>
<Frame>
<img src="/images/app-screenshots/upgrade-honcho.png" alt="Upgrade Honcho" loading="lazy" decoding="async" fetchpriority="low" style={{ width: "100%", height: "auto" }} />
</Frame>
</div>
The **Performance** page provides comprehensive monitoring with usage metrics, health analytics, API response times, and endpoint usage across Honcho.
<Frame>
<img src="/images/app-screenshots/performance-analytics.png" alt="Performance Analytics Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 3. Manage API Keys
The [API Keys](https://app.honcho.dev/api-keys) page allows you to create and manage authentication tokens for different environments. You can create admin-level keys with full instance access or scope keys to specific `Workspaces`, `Peers`, or `Sessions`.
<Frame>
<img src="/images/app-screenshots/api-keys.png" alt="API Key Management Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 4. Test with API Playground
The [API Playground](https://app.honcho.dev/playground) provides a Postman-like interface to test queries, explore endpoints, and validate your integration. Authenticate with an API key and send requests directly to your Honcho instance with real-time responses and full request/response logging.
<Frame>
<img src="/images/app-screenshots/api-playground.png" alt="API Playground Interface" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 5. Workspaces
The [Explore](https://app.honcho.dev/explore) page provides comprehensive `Workspace` management where you can create workspaces and begin exploring the platform. Each `Workspace` serves as a container for organizing your Honcho data.
<Frame>
<img src="/images/app-screenshots/explore-honcho.png" alt="Workspace Table" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
Click into any workspace to access a general overview of `Peers` and `Sessions`. Here you can quickly create `Peers`, `Sessions`, and add multiple `Peers` to any `Session`. Edit the metadata and configuration for a `Workspace` with the Edit Config button. Click into any entity to navigate to their respective utilities pages or click the expand icon to view Workspace-wide `Peers` and `Sessions` data tables with more details.
<Frame>
<img src="/images/app-screenshots/workspace-dash.png" alt="Workspace Dashboard Overview" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 6. Peer Dashboard & Utilities
Expand the `Peers` list from the `Workspace` dashboard to see a detailed view of `Peers`.
<Frame>
<img src="/images/app-screenshots/peer-dash.png" alt="Peer Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
Click into any peer to navigate to their respective utilities page. Next to the `Peer` name you can edit the [Global Peer Configuration](/v2/documentation/core-concepts/configuration), and in the tabs below, explore all utilities for the `Peer`.
<Frame>
<img src="/images/app-screenshots/peer-utilities.png" alt="Peer Management Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
Utilities include:
- **Message search** across all sessions for a `Peer`
- **Dialectic Chat** to query `Peer` representations globally or session-scoped (results vary dependant on the `Peer`'s configuration)
<Frame>
<img src="/images/app-screenshots/chat-endpoint.png" alt="Chat Endpoint" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
- **Session logs** view which `Sessions` the `Peer` is active
- **Peer configuration and metadata management** including [Session-Peer Configuration](/v2/documentation/core-concepts/configuration#session-peer-configuration)
<Frame>
<img src="/images/app-screenshots/peer-utilities.png" alt="Peer Management Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 7. Session Dashboard & Utilities
Click into the sessions view within a workspace to see a table of all of your `Sessions` data.
<Frame>
<img src="/images/app-screenshots/session-dash.png" alt="Sessions Table" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
Click into a `Session` to open its utilities page.
<Frame>
<img src="/images/app-screenshots/session-utilities.png" alt="Session Utilities" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
Here you can:
- **View and add Messages** within the `Session`; filter messages by `Peer`
- **Advanced search** across `Session` messages
- **Peer management** for adding/removing `Peers` and editing a `Peer`'s Session-level configuration
- **Get Context** to generate LLM-ready context with customizable token limits
<Frame>
<img src="/images/app-screenshots/get-context.png" alt="Get Context" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 8. Webhooks Integration
The [Webhooks](https://app.honcho.dev/webhooks) page enables Webhook creation and management.
<Frame>
<img src="/images/app-screenshots/webhooks-page.png" alt="Webhooks Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## 9. Organization Member Access
The [Members](https://app.honcho.dev/members) page provides organization administration to manage your team's access to Honcho with the ability to grant admin permissions.
<Frame>
<img src="/images/app-screenshots/members-dashboard.png" alt="Members Dashboard" width="1200" height="800" loading="lazy" decoding="async" fetchpriority="low" />
</Frame>
## Go Further
View the [Architecture](/v2/documentation/core-concepts/architecture) to see how Honcho works under the hood.
Dive into our [API Reference](/v2/api-reference) to explore all available endpoints.
## Next Steps
<CardGroup cols={2}>
<Card title="Sign up to Honcho Platform" icon="rocket" href="https://app.honcho.dev">
Get started with managed Honcho instances
</Card>
<Card title="Join our Discord" icon="discord" href="http://discord.gg/plasticlabs">
Connect with 1000+ developers building with Honcho
</Card>
<Card title="Contribute to Honcho" icon="code" href="/v2/contributing/guidelines">
View our guidelines and explore the codebase
</Card>
<Card title="Explore Examples" icon="book" href="/v2/guides">
See Honcho in action with real examples
</Card>
</CardGroup>
We're excited to see what you'll build with Honcho Platform. Let's create smarter, more personalized AI experiences together!
---
*Ready to build personally aligned AI? [Get started with Honcho →](https://app.honcho.dev)*

1110
docs/v2.6.0-alpha/documentation/reference/sdk.mdx Normal file
View File

File diff suppressed because it is too large Load Diff

0
docs/v2.6.0-alpha/documentation/reference/storage.mdx Normal file
View File

162
docs/v2.6.0-alpha/documentation/scratch/honcho-memory/advanced-retrieval/get-context.mdx Normal file
View File

@ -0,0 +1,162 @@
---
title: "Get Context (Memory-Enhanced)"
description: "Intelligent context retrieval powered by Honcho Memory"
icon: "brain"
sidebarTitle: "Get Context"
---
# Memory-Enhanced Context Retrieval
The Get Context endpoint provides intelligent, memory-enhanced context retrieval that combines raw conversation history with derived insights and representations.
## Overview
Unlike basic message retrieval, memory-enhanced context:
- Includes relevant facts about peers from long-term memory
- Incorporates session summaries for efficient context
- Provides working representations of peer psychology
- Optimizes content for LLM token limits
## Features
### Token-Aware Retrieval
Automatically manages context to fit within your specified token budget:
```python
context = session.get_context(max_tokens=2000)
```
### Multi-Layered Context
Combines multiple information sources:
1. **Recent Messages**: Latest conversation turns
2. **Session Summaries**: Compressed historical context
3. **Peer Representations**: Psychological insights
4. **Peer Cards**: Identity and role information
### Configurable Options
Fine-tune what context is included:
```python
context = session.get_context(
max_tokens=2000,
include_summaries=True,
include_representation=True,
peer_id="peer_123" # Get representation for specific peer
)
```
## Use Cases
### Agent Response Generation
Provide your agent with rich context for personalized responses:
```python
# Get optimized context
context = session.get_context(max_tokens=1500)
# Use in your LLM prompt
response = llm.generate(
messages=[
{"role": "system", "content": context},
{"role": "user", "content": user_message}
]
)
```
### Multi-Peer Conversations
Get context tailored to specific participants:
```python
# Get Alice's perspective
alice_context = session.get_context(peer_id=alice.id)
# Get Bob's perspective
bob_context = session.get_context(peer_id=bob.id)
```
### Dynamic Context Windows
Adjust context size based on task complexity:
```python
# More context for complex tasks
detailed_context = session.get_context(max_tokens=4000)
# Minimal context for simple queries
quick_context = session.get_context(max_tokens=500)
```
## How It Works
The Get Context endpoint uses a sophisticated algorithm to:
1. Estimate token counts for all available context
2. Prioritize recent messages and relevant insights
3. Include summaries when full history exceeds token limit
4. Add peer representations when requested
5. Return optimally structured context
## Best Practices
### Token Budgeting
Leave room in your model's context window:
```python
# For a 8K context model
context = session.get_context(max_tokens=2000) # Leaves room for prompt + response
```
### Representation Updates
Ensure representations are current:
```python
# Check if representation is being generated
status = workspace.get_deriver_status(session_id=session.id)
# Wait for processing if needed
if status.pending > 0:
time.sleep(1) # Or implement proper polling
```
### Caching Strategies
Context can be cached for repeated queries:
```python
# Cache context for multiple agent calls
cached_context = session.get_context(max_tokens=2000)
# Reuse for multiple related queries
for query in user_queries:
response = agent.query(context=cached_context, query=query)
```
## Performance Considerations
- **First Call**: May be slower as representations are generated
- **Subsequent Calls**: Fast retrieval from vector storage
- **Token Counting**: Uses tiktoken for accurate estimation
- **Caching**: Consider caching context for high-frequency scenarios
## Related Features
<CardGroup cols={3}>
<Card title="Basic Get Context" icon="database" href="/v2/documentation/core-concepts/features/get-context">
Learn about basic context retrieval
</Card>
<Card title="Summaries" icon="align-left" href="/v2/documentation/core-concepts/summarizer">
Understand session summarization
</Card>
<Card title="Dialectic API" icon="comments" href="/v2/documentation/core-concepts/features/dialectic-endpoint">
Chat with Honcho for insights
</Card>
</CardGroup>

288
docs/v2.6.0-alpha/documentation/scratch/honcho-memory/quickstart.mdx Normal file
View File

@ -0,0 +1,288 @@
---
title: 'Quickstart - Honcho Memory'
icon: 'bolt'
sidebarTitle: 'Quickstart'
---
Implement Honcho Memory in just a few steps. No signup required.
<Note>
By default, the SDK uses the demo server hosted at demo.honcho.dev. The demo server is meant for quick experimentation and the data is cleared on a regular basis. Do not use for production applications.
</Note>
## 1. Install the SDK
<CodeGroup>
```bash Python (uv)
uv add honcho-ai
```
```bash Python (pip)
pip install honcho-ai
```
```bash TypeScript (npm)
npm install @honcho-ai/sdk
```
```bash TypeScript (yarn)
yarn add @honcho-ai/sdk
```
```bash TypeScript (pnpm)
pnpm add @honcho-ai/sdk
```
</CodeGroup>
## 2. Initialize the Client
The Honcho client is the main entry point for interacting with Honcho's API. By default, it uses the demo environment and a default workspace.
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client (uses demo environment and default workspace)
honcho = Honcho()
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
// Initialize client (uses demo environment and default workspace)
const honcho = new Honcho({});
```
</CodeGroup>
## 3. Create Peers
Peers represent individual users, AI agents, or any conversational entity in your system:
<CodeGroup>
```python Python
alice = honcho.peer("alice")
bob = honcho.peer("bob")
```
```typescript TypeScript
const alice = await honcho.peer("alice")
const bob = await honcho.peer("bob")
```
</CodeGroup>
## 4. Create a Session
Sessions are independent conversations that can include multiple peers:
<CodeGroup>
```python Python
session = honcho.session("session_1")
session.add_peers([alice, bob])
```
```typescript TypeScript
const session = await honcho.session("session_1")
await session.addPeers([alice, bob])
```
</CodeGroup>
## 5. Add Messages
Add some conversation messages. Honcho automatically learns from these interactions:
<CodeGroup>
```python Python
session.add_messages([
alice.message("Hi Bob, how are you?"),
bob.message("I'm good, thank you!"),
alice.message("What are you doing today after work?"),
bob.message("I'm going to the gym! I've been trying to get back in shape."),
alice.message("That's great! I should probably start exercising too."),
bob.message("You should! I find that evening workouts help me relax."),
])
```
```typescript TypeScript
await session.addMessages([
alice.message("Hi Bob, how are you?"),
bob.message("I'm good, thank you!"),
alice.message("What are you doing today after work?"),
bob.message("I'm going to the gym! I've been trying to get back in shape."),
alice.message("That's great! I should probably start exercising too."),
bob.message("You should! I find that evening workouts help me relax."),
])
```
</CodeGroup>
## 6. Query for Insights
Now ask Honcho what it's learned - this is where the magic happens:
<CodeGroup>
```python Python
# Ask what Bob is like
response = bob.chat("Tell me about Bob's interests and habits")
print(response)
# Returns rich context like:
# "Bob is health-conscious and has been working on getting back in shape.
# He regularly goes to the gym, particularly in the evenings, and finds
# exercise helps him relax. He's encouraging about fitness and willing
# to share advice about workout routines."
```
```typescript TypeScript
bob.chat("Tell me about Bob's interests and habits").then((response) => {
console.log(response);
// Returns rich context like:
// "Bob is health-conscious and has been working on getting back in shape.
// He regularly goes to the gym, particularly in the evenings, and finds
// exercise helps him relax. He's encouraging about fitness and willing
// to share advice about workout routines."
})
```
</CodeGroup>
<Note>
Writing messages to Honcho triggers reasoning by default...
</Note>
## 7. Putting it all together
<CodeGroup>
```python Python
import os
from honcho import Honcho
# Create your client
honcho = Honcho()
# Get your Peers
alice = honcho.peer("alice")
bob = honcho.peer("bob")
# Make a Session and add your Peers
session = honcho.session("session_1")
session.add_peers([alice, bob])
# Add messages sent by your Peers
session.add_messages([
alice.message("Hi Bob, how are you?"),
bob.message("I'm good, thank you!"),
alice.message("What are you doing today after work?"),
bob.message("I'm going to the gym! I've been trying to get back in shape."),
alice.message("That's great! I should probably start exercising too."),
bob.message("You should! I find that evening workouts help me relax."),
])
# Get insights about your Peers
response = bob.chat("Tell me about Bob's interests and habits")
print(response)
# Returns rich context like:
# "Bob is health-conscious and has been working on getting back in shape.
# He regularly goes to the gym, particularly in the evenings, and finds
# exercise helps him relax. He's encouraging about fitness and willing
# to share advice about workout routines."
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
// Create your client
const honcho = new Honcho({});
// Get your Peers
const alice = await honcho.peer("alice")
const bob = await honcho.peer("bob")
// Make a Session and add your peers
const session = await honcho.session("session_1")
await session.addPeers([alice, bob])
// Add messages sent by your Peers
await session.addMessages([
alice.message("Hi Bob, how are you?"),
bob.message("I'm good, thank you!"),
alice.message("What are you doing today after work?"),
bob.message("I'm going to the gym! I've been trying to get back in shape."),
alice.message("That's great! I should probably start exercising too."),
bob.message("You should! I find that evening workouts help me relax."),
])
// Get insights about your peers
bob.chat("Tell me about Bob's interests and habits").then((response) => {
console.log(response);
// Returns rich context like:
// "Bob is health-conscious and has been working on getting back in shape.
// He regularly goes to the gym, particularly in the evenings, and finds
// exercise helps him relax. He's encouraging about fitness and willing
// to share advice about workout routines."
})
```
</CodeGroup>
## Recap
Honcho just reasoned about a conversation between two people--Alice
and Bob. We:
1. Set up our connection to Honcho.
2. Setup the participants of our conversation--these are called `Peers`.
3. Made a `Session` and added our `Peers`.
4. Sent messages from our `Peers`.
5. Queried Honcho to get insights about one of the `Peers` in the conversation.
As soon as you save a message in Honcho, it will start to reason about it to
pull out insights and develop a profile of the user. This is the default
behavior and can be toggled off via [the configuration](/v2/documentation/core-concepts/configuration).
## Next Steps
<CardGroup cols={3}>
<Card title="Architecture" icon="rocket"
href="/v2/documentation/core-concepts/architecture">
Learn about the data primitives in Honcho and how they work together
</Card>
<Card title="Start Building" icon="brain" href="https://app.honcho.dev">
Sign up for Managed Honcho and get started building agents now.
</Card>
<Card title="Guides" icon="book" href="/v2/guides/overview">
Check out spellbooks to see different examples apps built with Honcho
</Card>
</CardGroup>
---
# SCRATCH
### Production Environment
<CodeGroup>
```python Python
import os
from honcho import Honcho
# Production environment with API key
honcho = Honcho(
api_key=os.environ["HONCHO_API_KEY"],
environment="production",
# Create a workspace, otherwise set to "default"
# workspaceId="your-workspace-id"
)
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
// Production environment with API key
const honcho = new Honcho({
apiKey: process.env.HONCHO_API_KEY!,
environment: "production",
// Create a workspace, otherwise set to "default"
// workspace: "your-workspace-id"
});
```
</CodeGroup>

68
docs/v2.6.0-alpha/documentation/scratch/local-vs-global.mdx Normal file
View File

@ -0,0 +1,68 @@
---
title: Local vs Global Representations
description: Model directional relationships between Peers in Honcho
icon: location-pin
---
One of the unique affordances of Honcho is that it allows developers to model
directional relationships between Peers. What I mean by this is you can model
how one `Peer` thinks about another `Peer`.
There are many use cases where you don't want every agent or human to know
everything about another user such as games or multi-agent workflows. To
illustrate this, the following examples shows 2 conversations.
Conversation #1 (With Bob and Alice)
```
Alice: I had a great breakfast today.
Bob: What did you eat?
Alice: I had pancakes and eggs and bacon
```
Conversation #2 (With Alice and Charlie)
```
Alice: I actually didn't eat any breakfast today.
Charlie: Oh that's too bad.
Alice: But I lied to Bob and told him I did, so back me up if you see them.
```
Alice told Bob a lie in this conversation. If we stored both of these
conversations in Honcho with Alice, Bob, and Charlie as `Peers` and let them
use Honcho to get insights on each other then Bob would immediately know this
deception. For example:
<CodeGroup>
```python Python
# Bob could run
alice.chat("What did Alice eat today?")
# Response: Alice did not eat anything today
```
</CodeGroup>
This is a problem. Bob shouldn't be able to know everything about Alice in this
situation. So to support these situations we support what we call **Local
Representations**.
By default insights generated for a `Peer` are scoped globally. This means every
message sent by that `Peer` in any conversation updates the same representation
of that `Peer`. However, we can enable **Local Representations** so Bob can
form a representation Alice based only on what they observe Alice do.
This feature is illustrated in the graphic below:
<img src="/images/local-vs-global-reps.png" alt="Peer Representations" />
We can enable local representation for a `Peer` by setting `observe_others=True`.
This is shown in the [Configure
Reasoning](/v2/documentation/core-concepts/configuration) page.
Now if we used Bob's local representation of Alice then Bob would only get
insights on what they've seen Alice say to them.
```python
bob.chat(target="alice", query="What did Alice eat today?")
# Response: Alice ate pancakes, eggs, and bacon
```
<Note>
Local Representations are turned off by default
</Note>

347
docs/v2.6.0-alpha/documentation/scratch/working-rep.mdx Normal file
View File

@ -0,0 +1,347 @@
---
title: 'Working Representations'
description: "Learn how to retrieve cached peer knowledge and understanding using Honcho's working representation system"
icon: 'brain'
---
Working representations are Honcho's system for accessing cached psychological models that capture what peers know, think, and remember. Unlike the `chat()` method which generates fresh representations on-demand, the `working_rep()` method retrieves pre-computed representations that have been automatically built and stored as conversations progress.
## How Working Representations Are Created
Working representations are automatically generated and cached through Honcho's background processing system:
1. **Automatic Generation**: When messages are added to sessions, they trigger background jobs that analyze conversations using theory of mind inference and long-term memory integration
2. **Cached Storage**: The generated representations are stored in the database as metadata on `Peer` objects (for global representations) or `SessionPeer` objects (for session-scoped representations)
3. **Retrieval**: The `working_rep()` method provides fast access to these cached representations without requiring LLM processing
<Info>
**Cached vs On-Demand**: `working_rep()` retrieves cached representations for fast access, while `peer.chat()` generates fresh representations using the dialectic system. Use `working_rep()` when you need fast access to stored knowledge, and `chat()` when you need current analysis with custom queries.
</Info>
## Basic Usage
Working representations are accessed through the `working_rep()` method on Session or Peer objects:
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho()
# Create peers and session
user = honcho.peer("user-123")
assistant = honcho.peer("ai-assistant")
session = honcho.session("support-conversation")
# Add conversation to trigger representation generation
session.add_messages([
user.message("I'm having trouble with my billing account"),
assistant.message("I can help with that. What specific issue are you seeing?"),
user.message("My credit card was charged twice last month"),
assistant.message("I see duplicate charges on your account. Let me refund one of them.")
])
# Chat to generate a working representation
response = user.chat("What is this user's main concern right now?", session_id=session.id)
# Retrieve the cached working representation for the user
user_representation = session.working_rep("user-123")
print("Cached user representation:", user_representation)
# Or access from the peer directly
peer_representation = user.working_rep()
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
// Initialize client
const honcho = new Honcho({});
// Create peers and session
const user = await honcho.peer("user-123");
const assistant = await honcho.peer("ai-assistant");
const session = await honcho.session("support-conversation");
// Add conversation to trigger representation generation
await session.addMessages([
user.message("I'm having trouble with my billing account"),
assistant.message("I can help with that. What specific issue are you seeing?"),
user.message("My credit card was charged twice last month"),
assistant.message("I see duplicate charges on your account. Let me refund one of them.")
]);
// Chat to generate a working representation
const response = await user.chat("What is this user's main concern right now?", { sessionId: session.id });
// Retrieve the cached working representation for the user
const userRepresentation = await session.workingRep("user-123");
console.log("Cached user representation:", userRepresentation);
// Or access from the peer directly
const peerRepresentation = await user.workingRep();
```
</CodeGroup>
## Semantic Search in Representations
Working representations support semantic search to retrieve the most relevant observations for a given query. This is useful when you want to focus the representation on specific topics.
### Parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `search_query` | `str` | Semantic search query to filter relevant observations |
| `search_top_k` | `int` | Number of semantic search results to include (1-100) |
| `search_max_distance` | `float` | Maximum semantic distance threshold (0.0-1.0) |
| `include_most_derived` | `bool` | Whether to include the most recently derived observations |
| `max_observations` | `int` | Maximum number of observations to include (1-100) |
<CodeGroup>
```python Python
# Get representation focused on a specific topic
billing_rep = session.working_rep(
"user-123",
search_query="billing and payment issues",
search_top_k=10,
search_max_distance=0.8,
include_most_derived=True,
max_observations=25
)
# Get representation from peer with target
# What user-123 knows about the assistant
local_rep = session.working_rep(
"user-123",
target="ai-assistant",
search_query="support interactions"
)
# Access from peer object with semantic search
user_rep = user.working_rep(
session=session,
search_query="preferences",
search_top_k=5
)
```
```typescript TypeScript
// Get representation focused on a specific topic
const billingRep = await session.workingRep("user-123", {
searchQuery: "billing and payment issues",
searchTopK: 10,
searchMaxDistance: 0.8,
includeMostDerived: true,
maxObservations: 25
});
// Get representation from peer with target
// What user-123 knows about the assistant
const localRep = await session.workingRep("user-123", {
target: "ai-assistant",
searchQuery: "support interactions"
});
// Access from peer object with semantic search
const userRep = await user.workingRep(session, undefined, {
searchQuery: "preferences",
searchTopK: 5
});
```
</CodeGroup>
## Understanding Representation Content
Cached working representations contain structured psychological analysis based on conversation history. The format typically includes:
### Current Mental State Predictions
Information about what the peer is currently thinking, feeling, or focused on based on recent messages.
### Relevant Long-term Facts
Facts about the peer that have been extracted and stored over time from various conversations.
### Example Representation Structure
<CodeGroup>
```python Python
# Example of what a cached representation might contain
representation = session.working_rep("user-123")
# Typical content structure:
"""
PREDICTION ABOUT THE USER'S CURRENT MENTAL STATE:
The user appears frustrated with a billing issue, specifically concerning duplicate charges.
They seem to have some confidence in the support process as they provided specific details.
RELEVANT LONG-TERM FACTS ABOUT THE USER:
- User has had previous billing inquiries
- User prefers direct, specific communication
- User is detail-oriented when reporting issues
"""
print("Full representation:", representation)
```
```typescript TypeScript
// Example of what a cached representation might contain
const representation = await session.workingRep("user-123");
// Typical content structure:
/*
PREDICTION ABOUT THE USER'S CURRENT MENTAL STATE:
The user appears frustrated with a billing issue, specifically concerning duplicate charges.
They seem to have some confidence in the support process as they provided specific details.
RELEVANT LONG-TERM FACTS ABOUT THE USER:
- User has had previous billing inquiries
- User prefers direct, specific communication
- User is detail-oriented when reporting issues
*/
console.log("Full representation:", representation);
```
</CodeGroup>
## When Representations Are Updated
Working representations are automatically updated through Honcho's background processing system:
### Message Processing Pipeline
1. **Message Creation**: When messages are added via `session.add_messages()` or similar methods
2. **Background Queuing**: Messages are queued for processing in the background
3. **Theory of Mind Analysis**: The system analyzes conversation patterns and psychological states
4. **Fact Extraction**: Long-term facts are extracted and stored in vector embeddings
5. **Representation Generation**: New representations are created combining current analysis with historical facts
6. **Cache Update**: The new representation is stored in the database metadata
### Processing Triggers
Representations are updated when:
- New messages are added to sessions
- Sufficient new content has accumulated
- The background processing system determines an update is needed
## Comparison with Chat Method
Understanding when to use `working_rep()` vs `peer.chat()`:
### Use `working_rep()` when:
- You need fast access to stored psychological models
- You want to see what the system has already learned about a peer
- You're building dashboards or analytics that display peer understanding
- You need consistent representations that don't change between calls
### Use `peer.chat()` when:
- You need to ask specific questions about a peer
- You want fresh analysis based on current conversation state
- You need customized insights for specific use cases
- You want to query about relationships between peers
<CodeGroup>
```python Python
# Fast cached access
cached_rep = session.working_rep("user-123")
print("Cached:", cached_rep[:100] + "...")
# Custom query with fresh analysis
custom_analysis = user.chat("What is this user's main concern right now?", session_id=session.id)
print("Fresh analysis:", custom_analysis)
```
```typescript TypeScript
// Fast cached access
const cachedRep = await session.workingRep("user-123");
console.log("Cached:", cachedRep.substring(0, 100) + "...");
// Custom query with fresh analysis
const customAnalysis = await user.chat("What is this user's main concern right now?", { sessionId: session.id });
console.log("Fresh analysis:", customAnalysis);
```
</CodeGroup>
## Best Practices
### 1. Ensure Availability Before Using
Make sure that a representation exists before processing it by using the chat endpoint first.
### 2. Use for Fast Analytics
Cached representations are ideal for analytics dashboards:
<CodeGroup>
```python Python
# Good: Fast dashboard updates using cached data
def update_analytics_dashboard(sessions):
analytics = {}
for session in sessions:
for peer_id in session.get_peer_ids():
rep = session.working_rep(peer_id)
analytics[peer_id] = analyze_representation(rep)
return analytics
```
```typescript TypeScript
// Good: Fast dashboard updates using cached data
async function updateAnalyticsDashboard(sessions) {
const analytics: Record<string, any> = {};
for (const session of sessions) {
const peerIds = await session.getPeerIds();
for (const peerId of peerIds) {
const rep = await session.workingRep(peerId);
analytics[peerId] = analyzeRepresentation(rep);
}
}
return analytics;
}
```
</CodeGroup>
### 3. Combine with Fresh Analysis When Needed
Use cached representations for baseline understanding, and fresh analysis for current insights:
<CodeGroup>
```python Python
# Get baseline understanding from cache
baseline = session.working_rep("user-123")
# Get current specific insights
current_state = user.chat("How is this user feeling right now?", session_id=session.id)
# Combine for comprehensive view
comprehensive_view = {
"baseline_knowledge": baseline,
"current_analysis": current_state
}
```
```typescript TypeScript
// Get baseline understanding from cache
const baseline = await session.workingRep("user-123");
// Get current specific insights
const currentState = await user.chat("How is this user feeling right now?", { sessionId: session.id });
// Combine for comprehensive view
const comprehensiveView = {
baselineKnowledge: baseline,
currentAnalysis: currentState
};
```
</CodeGroup>
## Conclusion
Working representations provide fast access to cached psychological models that Honcho automatically builds and maintains. By understanding how to:
- Retrieve cached representations using `session.working_rep()`
- Parse and interpret representation content
- Handle cases where representations aren't available
- Combine cached and fresh analysis appropriately
You can build efficient applications that leverage Honcho's continuous learning about peer knowledge and mental states without the latency of real-time generation.

254
docs/v2.6.0-alpha/guides/discord.mdx Normal file
View File

@ -0,0 +1,254 @@
---
title: "Discord Bots with Honcho"
icon: 'discord'
description: "Use Honcho to build a Discord bot with conversational memory and context management."
sidebarTitle: 'Discord Bot'
---
> Example code is available on [GitHub](https://github.com/plastic-labs/discord-python-starter)
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.
## Events
Most Discord bots have async functions that listen for specific events, the most common one being messages. We can use Honcho to store messages by user and session based on an interface's event logic. Take the following function definition for example:
```python
@bot.event
async def on_message(message):
"""
Receive a message from Discord and respond with a message from our LLM assistant.
"""
if not validate_message(message):
return
input = sanitize_message(message)
# If the message is empty after sanitizing, ignore it
if not input:
return
peer = honcho_client.peer(id=get_peer_id_from_discord(message))
session = honcho_client.session(id=str(message.channel.id))
async with message.channel.typing():
response = llm(session, input)
await send_discord_message(message, response)
# Save both the user's message and the bot's response to the session
session.add_messages(
[
peer.message(input),
assistant.message(response),
]
)
```
Let's break down what this code is doing...
```python
@bot.event
async def on_message(message):
if not validate_message(message):
return
```
This is how you define an event function in `py-cord` that listens for messages. We use a helper function `validate_message()` to check if the message should be processed.
## Helper Functions
The code uses several helper functions to keep the main logic clean and readable. Let's examine each one:
### Message Validation
```python
def validate_message(message) -> bool:
"""
Determine if the message is valid for the bot to respond to.
Return True if it is, False otherwise. Currently, the bot will
only respond to messages that tag it with an @mention in a
public channel and are not from the bot itself.
"""
if message.author == bot.user:
# ensure the bot does not reply to itself
return False
if isinstance(message.channel, discord.DMChannel):
return False
if not bot.user.mentioned_in(message):
return False
return True
```
This function centralizes all the logic for determining whether the bot should respond to a message. It checks that:
- The message isn't from the bot itself
- The message isn't in a DM channel
- The bot is mentioned in the message
### Message Sanitization
```python
def sanitize_message(message) -> str | None:
"""Remove the bot's mention from the message content if present"""
content = message.content.replace(f"<@{bot.user.id}>", "").strip()
if not content:
return None
return content
```
This helper removes the bot's mention from the message content, leaving just the actual user input.
### Peer ID Generation
```python
def get_peer_id_from_discord(message):
"""Get a Honcho peer ID for the message author"""
return f"discord_{str(message.author.id)}"
```
This creates a unique peer identifier for each Discord user by prefixing their Discord ID.
### LLM Integration
```python
def llm(session, prompt) -> str:
"""
Call the LLM with the given prompt and chat history.
You should expand this function with custom logic, prompts, etc.
"""
messages: list[dict[str, object]] = session.get_context().to_openai(
assistant=assistant
)
messages.append({"role": "user", "content": prompt})
try:
completion = openai.chat.completions.create(
model=MODEL_NAME,
messages=messages,
)
return completion.choices[0].message.content
except Exception as e:
print(e)
return f"Error: {e}"
```
This function handles the LLM interaction. It uses Honcho's built-in `to_openai()` method to automatically convert the session context into the format expected by OpenAI's chat completions API.
### Message Sending
```python
async def send_discord_message(message, response_content: str):
"""Send a message to the Discord channel"""
if len(response_content) > 1500:
# Split response into chunks at newlines, keeping under 1500 chars
chunks = []
current_chunk = ""
for line in response_content.splitlines(keepends=True):
if len(current_chunk) + len(line) > 1500:
chunks.append(current_chunk)
current_chunk = line
else:
current_chunk += line
if current_chunk:
chunks.append(current_chunk)
for chunk in chunks:
await message.channel.send(chunk)
else:
await message.channel.send(response_content)
```
This function handles sending messages to Discord, automatically splitting long responses into multiple messages to stay within Discord's character limits.
## Honcho Integration
The new Honcho peer/session API makes integration much simpler:
```python
peer = honcho_client.peer(id=get_peer_id_from_discord(message))
session = honcho_client.session(id=str(message.channel.id))
```
Here we create a peer object for the user and a session object using the Discord channel ID. This automatically handles user and session management.
```python
# Save both the user's message and the bot's response to the session
session.add_messages(
[
peer.message(input),
assistant.message(response),
]
)
```
After generating the response, we save both the user's input and the bot's response to the session using the `add_messages()` method. The `peer.message()` creates a message from the user, while `assistant.message()` creates a message from the assistant.
## Slash Commands
Discord bots also offer slash command functionality. Here's an example using Honcho's chat endpoint feature:
```python
@bot.slash_command(
name="chat",
description="Query the peer's representation in natural language.",
)
async def chat(ctx, query: str):
await ctx.defer()
try:
peer = honcho_client.peer(id=get_peer_id_from_discord(ctx))
session = honcho_client.session(id=str(ctx.channel.id))
response = peer.chat(
query=query,
session_id=session.id,
)
if response:
await ctx.followup.send(response)
else:
await ctx.followup.send(
f"I don't know anything about {ctx.author.name} because we haven't talked yet!"
)
except Exception as e:
logger.error(f"Error calling Dialectic API: {e}")
await ctx.followup.send(
f"Sorry, there was an error processing your request: {str(e)}"
)
```
This slash command uses Honcho's chat endpoint functionality to answer questions about the user based on their conversation history.
## Setup and Configuration
The bot requires several environment variables and setup:
```python
honcho_client = Honcho()
assistant = honcho_client.peer(id="assistant", config={"observe_me": False})
openai = OpenAI(base_url="https://openrouter.ai/api/v1", api_key=MODEL_API_KEY)
```
- `honcho_client`: The main Honcho client
- `assistant`: A peer representing the bot/assistant
- `openai`: OpenAI client configured to use OpenRouter
## Recap
The new Honcho peer/session API makes Discord bot integration much simpler and more intuitive. Key patterns we learned:
- **Peer/Session Model**: Users are represented as peers, conversations as sessions
- **Automatic Context Management**: `session.get_context().to_openai()` automatically formats chat history
- **Message Storage**: `session.add_messages()` stores both user and assistant messages
- **Representation Queries**: `peer.chat()` enables querying conversation history
- **Helper Functions**: Clean code organization with focused helper functions
This approach provides a clean, maintainable structure for building Discord bots with conversational memory and context management.

293
docs/v2.6.0-alpha/guides/file-uploads.mdx Normal file
View File

@ -0,0 +1,293 @@
---
title: 'File Uploads'
description: 'Upload PDFs, text files, and JSON documents to create messages in Honcho'
icon: 'upload'
---
Honcho's file upload feature allows you to convert documents into messages automatically. Upload PDFs, text files, or JSON documents, and Honcho will extract the text content, split it into appropriately sized chunks, and create messages that become part of your peer's representation or session context.
This feature is perfect for ingesting documents, reports, research papers, or any text-based content that you want your AI agents to understand and reference.
## How It Works
When you upload a file, Honcho:
1. **Extracts text** from the file using specialized processors based on file type
2. **Creates messages** with the extracted content split into chunks that fit within message limits (messages are limited to 50,000 characters)
3. **Queues processing** for background analysis and insight derivation like any other message
The file content becomes part of the peer's representation, making it available for natural language queries and context retrieval.
## Supported File Types
Honcho currently supports the following file types with more to come:
- **PDF files** (`application/pdf`) - Text extraction with page numbers
- **Text files** (`text/*`) - Plain text, markdown, code files, etc.
- **JSON files** (`application/json`) - Structured data converted to readable format
<Note>
Files are processed in memory and not stored on disk. Only the extracted text content is preserved in Honcho's message system.
</Note>
## Basic Usage
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize client
honcho = Honcho()
# Create session and peer
session = honcho.session("research-session")
user = honcho.peer("researcher")
# Upload a PDF to a session
with open("research_paper.pdf", "rb") as file:
messages = session.upload_file(
file=file,
peer_id=user.id,
)
print(f"Created {len(messages)} messages from the PDF")
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
import fs from "fs";
(async () => {
// Initialize client
const honcho = new Honcho({});
// Create session and peer
const session = await honcho.session("research-session");
const user = await honcho.peer("researcher");
// Upload a PDF to a session
const fileStream = fs.createReadStream("research_paper.pdf");
const messages = await session.uploadFile(fileStream, user.id);
console.log(`Created ${messages.length} messages from the PDF`);
})();
```
</CodeGroup>
## Upload Parameters
The upload methods accept the following parameters:
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `file` | File | Yes | File to upload |
| `peer_id` | String | Yes | ID of the peer creating the messages |
## File Processing Details
### Text Extraction
**PDF Files**: Text is extracted page by page with page numbers preserved:
```
[Page 1]
Introduction
This document provides...
[Page 2]
Methodology
Our approach involves...
```
**Text Files**: Content is decoded using UTF-8, UTF-16, or Latin-1 encoding as needed.
**JSON Files**: Structured data is converted to string format.
### Chunking Strategy
Large files are automatically split into chunks of ~49,500 characters. The system seeks to break at natural boundaries if present:
1. Paragraph breaks (`\n\n`)
2. Line breaks (`\n`)
3. Sentence endings (`. `)
4. Word boundaries (` `)
Each chunk becomes a separate message, maintaining the original document structure.
## Querying Uploaded Content
Once files are uploaded, you can query the content using Honcho's natural language interface:
<CodeGroup>
```python Python
# Query what was learned from the uploaded documents
response = user.chat("What are the key findings from the research papers I uploaded?")
print(response)
# Ask about specific documents
response = user.chat("What does the quarterly report say about revenue growth?")
print(response)
# Get context from the uploaded documents for LLM integration
context = session.get_context(tokens=3000)
messages = context.to_openai(assistant=assistant)
```
```typescript TypeScript
(async () => {
// Query what was learned from the uploaded documents
const response = await user.chat("What are the key findings from the research papers I uploaded?");
console.log(response);
// Ask about specific documents
const response2 = await user.chat("What does the quarterly report say about revenue growth?");
console.log(response2);
// Get context from the uploaded documents for LLM integration
const context = await session.getContext({ tokens: 3000 });
const messages = context.toOpenAI(assistant);
})();
```
</CodeGroup>
## Error Handling
### Unsupported File Types
Files with unsupported content types will raise an exception:
```python
try:
messages = session.upload_file(
file=open("image.jpg", "rb"),
peer_id=user.id
)
except Exception as e:
print(f"Upload failed: {e}")
# Error: "Could not process file image.jpg: Unsupported file type: image/jpeg"
```
### Missing Required Fields
Session uploads require a `peer_id` parameter:
```python
# This will fail for session uploads
try:
messages = session.upload_file(file=file) # Missing peer_id
except ValueError as e:
print(f"Validation error: {e}")
```
## Complete Example: Document Analysis Assistant
Here's a complete example of building a document analysis assistant:
<CodeGroup>
```python Python
from honcho import Honcho
# Initialize
honcho = Honcho()
session = honcho.session("document-analysis")
user = honcho.peer("analyst")
assistant = honcho.peer("analysis-bot")
def upload_document(file_path, description):
"""Upload a document and add it to the session"""
with open(file_path, "rb") as file:
messages = session.upload_file(
file=file,
peer_id=user.id,
)
return messages
def analyze_documents():
"""Get AI analysis of uploaded documents"""
context = session.get_context(tokens=4000)
messages = context.to_openai(assistant=assistant)
# Add analysis request
messages.append({
"role": "user",
"content": "Please analyze all the documents I've uploaded and provide a comprehensive summary of the key findings, trends, and recommendations."
})
# Call OpenAI (or your preferred LLM)
# response = openai.chat.completions.create(model="gpt-4", messages=messages)
# return response.choices[0].message.content
return "Analysis would be generated here"
# Upload multiple documents
documents = [
("quarterly_report.pdf", "Q3 2024 Quarterly Financial Report"),
("market_research.pdf", "Market Analysis and Competitive Landscape"),
("product_roadmap.pdf", "Product Development Roadmap 2024-2025")
]
for file_path, description in documents:
messages = upload_document(file_path, description)
print(f"Uploaded {file_path}: {len(messages)} messages created")
# Get AI analysis
analysis = analyze_documents()
print("Document Analysis:", analysis)
```
```typescript TypeScript
import { Honcho } from "@honcho-ai/sdk";
import fs from "fs";
(async () => {
// Initialize
const honcho = new Honcho({});
const session = await honcho.session("document-analysis");
const user = await honcho.peer("analyst");
const assistant = await honcho.peer("analysis-bot");
async function uploadDocument(filePath: string, description: string) {
const fileStream = fs.createReadStream(filePath);
const messages = await session.uploadFile(fileStream, user.id);
return messages;
}
async function analyzeDocuments() {
const context = await session.getContext({ tokens: 4000 });
const messages = context.toOpenAI(assistant);
// Add analysis request
messages.push({
role: "user",
content: "Please analyze all the documents I've uploaded and provide a comprehensive summary of the key findings, trends, and recommendations."
});
// Call OpenAI (or your preferred LLM)
// const response = await openai.chat.completions.create({ model: "gpt-4", messages });
// return response.choices[0].message.content;
return "Analysis would be generated here";
}
// Upload multiple documents
const documents = [
["quarterly_report.pdf", "Q3 2024 Quarterly Financial Report"],
["market_research.pdf", "Market Analysis and Competitive Landscape"],
["product_roadmap.pdf", "Product Development Roadmap 2024-2025"]
];
for (const [filePath, description] of documents) {
const messages = await uploadDocument(filePath, description);
console.log(`Uploaded ${filePath}: ${messages.length} messages created`);
}
// Get AI analysis
const analysis = await analyzeDocuments();
console.log("Document Analysis:", analysis);
})();
```
</CodeGroup>
## Error Handling
- **Always wrap uploads in try-catch blocks** for robust error handling
- **Validate file types** before upload to avoid processing errors
- **Handle large files gracefully** with progress indicators
- **Implement retry logic** for network failures

294
docs/v2.6.0-alpha/guides/integrations/crewai.mdx Normal file
View File

@ -0,0 +1,294 @@
---
title: "CrewAI"
icon: 'users-gear'
description: "Build AI agents with persistent memory using CrewAI and Honcho"
sidebarTitle: 'CrewAI'
---
Integrate Honcho with CrewAI to build AI agents that maintain memory across sessions. This guide shows you how to use Honcho's memory layer with CrewAI's agent orchestration framework.
<Note>
The full code is available on [GitHub](https://github.com/plastic-labs/honcho/tree/main/examples/crewai) with examples in [Python](https://github.com/plastic-labs/honcho/tree/main/examples/crewai/python/examples)
</Note>
## What We're Building
We'll create AI agents that remember and reason over past conversations. Here's how the pieces fit together:
- **CrewAI** orchestrates agent behavior and task execution
- **Honcho** stores messages and retrieves relevant context
The key benefit: CrewAI automatically retrieves relevant conversation history from Honcho without you needing to manually manage context, token limits, or message formatting.
<Note>
This tutorial demonstrates single-agent setup to show how Honcho integrates with CrewAI. For production applications, you can extend this to multi-agent crews with shared or individual memory using Honcho's `peer` system.
</Note>
## Setup
Install required packages:
<CodeGroup>
```bash Python (uv)
uv add honcho-crewai crewai python-dotenv
```
```bash Python (pip)
pip install honcho-crewai crewai python-dotenv
```
</CodeGroup>
Use any LLM provider for your Crew. Create a `.env` file with your API keys:
```bash
OPENAI_API_KEY=your_openai_key
```
<Note>
This tutorial uses the Honcho demo server at https://demo.honcho.dev which runs a small instance of Honcho on the latest version. For production, get your Honcho API key at [app.honcho.dev](https://app.honcho.dev). For local development, use `environment="local"`.
</Note>
## CrewAI Honcho Storage
The `honcho_crewai` package provides `HonchoStorage`, a storage provider that implements CrewAI's `Storage` interface using Honcho's session-based memory.
<Note>
Before proceeding, it's important to understand Honcho's core concepts (`Peers` and `Sessions`). Review the [Honcho Architecture](/v2/documentation/core-concepts/architecture) to familiarize yourself with these primitives.
</Note>
`HonchoStorage` implements CrewAI's `Storage` interface using Honcho's `peer` and `session` primitives.
```python
storage = HonchoStorage(
user_id="demo-user", # Required: Honcho `peer` ID for the user
session_id=None, # Optional: Specific `session` ID (auto-generated UUID if None)
honcho_client=None, # Optional: Pre-configured Honcho client instance
)
```
The `HonchoStorage` class implements three key methods:
- **`save()`** - Stores messages in Honcho's `session`, associating them with the appropriate `peer` (user or assistant)
- **`search()`** - Performs semantic vector search using `session.search()` to find messages most relevant to the query. Supports optional `filters` parameter for fine-grained scoping.
- **`reset()`** - Creates a new `session` to start fresh conversations
CrewAI automatically calls these methods when agents need to store or retrieve memory, creating a seamless integration.
### Search with Filters
The `search()` method supports an optional `filters` parameter for fine-grained scoping of search results:
```python
# Search with peer_id filter (only messages from a specific peer)
results = storage.search("query", filters={"peer_id": "user123"})
# Search with metadata filter
results = storage.search("query", filters={"metadata": {"priority": "high"}})
# Search with time range filter
results = storage.search("query", filters={"created_at": {"gte": "2024-01-01"}})
# Complex filter with logical operators
results = storage.search("query", filters={
"AND": [
{"peer_id": "user123"},
{"metadata": {"topic": "python"}}
]
})
```
For the full filter syntax including logical operators (AND, OR, NOT), comparison operators, and metadata filtering, see the [Using Filters](https://docs.honcho.dev/v2/documentation/core-concepts/features/using-filters) documentation.
<Note>
For comprehensive details about CrewAI's memory system, see the [official CrewAI Memory documentation](https://docs.crewai.com/en/concepts/memory).
</Note>
Let's create a basic example showing how CrewAI agents use Honcho's memory automatically:
```python Python
from dotenv import load_dotenv
from crewai import Agent, Task, Crew, Process
from crewai.memory.external.external_memory import ExternalMemory
from honcho_crewai import HonchoStorage
load_dotenv()
storage = HonchoStorage(user_id="simple-demo-user")
external_memory = ExternalMemory(storage=storage)
messages = [
("user", "I'm learning Python programming"),
("assistant", "Great! Python is an excellent language to learn."),
("user", "I'm particularly interested in web development"),
]
for role, message in messages:
external_memory.save(message, metadata={"agent": role})
agent = Agent(
role="Programming Mentor",
goal="Help users learn programming by remembering their interests and progress",
backstory=(
"You are a patient programming mentor who remembers what students "
"have told you about their learning journey and interests."
),
verbose=True,
allow_delegation=False
)
task = Task(
description=(
"Based on what you know about the user's interests, "
"suggest a simple web development project they could build to practice Python."
),
expected_output="A specific project suggestion with brief explanation",
agent=agent
)
crew = Crew(
agents=[agent],
tasks=[task],
process=Process.sequential,
external_memory=external_memory,
verbose=True
)
result = crew.kickoff()
print(result.raw)
```
## CrewAI Tool Integration
Honcho provides specialized tools that give CrewAI agents explicit control over memory retrieval:
- **`HonchoGetContextTool`** - Retrieves comprehensive conversation history with token limits. Use for tasks needing broad conversation understanding.
- **`HonchoDialecticTool`** - Queries representations about `peer`s. Use for understanding user preferences and characteristics without full message history.
- **`HonchoSearchTool`** - Performs semantic search for specific information. Supports optional `filters` parameter for fine-grained scoping. Use for targeted queries like "what did the user say about budget?"
<Tip>
Agents can use multiple tools in sequence: search for topics, query dialectic for preferences, then get full context for generation.
</Tip>
Here's an example demonstrating all three tools:
```python Python
from dotenv import load_dotenv
from crewai import Agent, Task, Crew, Process
from honcho import Honcho
from honcho_crewai import (
HonchoGetContextTool,
HonchoDialecticTool,
HonchoSearchTool,
)
load_dotenv()
honcho = Honcho()
user_id = "demo-user-45"
session_id = "tools-demo-session"
user = honcho.peer(user_id)
session = honcho.session(session_id)
messages = [
"I'm planning a trip to Japan in March",
"I love trying authentic local cuisine, especially ramen and sushi",
"My budget is around $3000 for a 10-day trip",
"I'm interested in visiting both Tokyo and Kyoto",
"I prefer staying in traditional ryokans over hotels",
]
for msg in messages:
session.add_messages([user.message(msg)])
context_tool = HonchoGetContextTool(
honcho=honcho, session_id=session_id, peer_id=user_id
)
dialectic_tool = HonchoDialecticTool(
honcho=honcho, session_id=session_id, peer_id=user_id
)
search_tool = HonchoSearchTool(honcho=honcho, session_id=session_id)
# Note: The search tool supports optional filters for fine-grained scoping
# Agents can use filters like {"peer_id": "user123"} or {"metadata": {"priority": "high"}}
travel_agent = Agent(
role="Travel Planning Specialist",
goal="Create personalized travel recommendations using memory tools",
backstory=(
"You are an expert travel planner with access to conversation memory tools. "
"Use the tools to understand the user's preferences before making recommendations."
),
tools=[context_tool, dialectic_tool, search_tool],
verbose=True,
allow_delegation=False
)
task = Task(
description=(
"Create a personalized 3-day Tokyo itinerary. "
"Use the memory tools to understand:\n"
" • Food preferences (use search_tool for 'cuisine' or 'food')\n"
" • Travel style and budget (use dialectic_tool to query user knowledge)\n"
" • Recent context (use context_tool to get conversation history)\n"
"Then create a detailed plan matching their interests."
),
expected_output=(
"A 3-day Tokyo itinerary with:\n"
" • Daily activities matching user interests\n"
" • Restaurant recommendations\n"
" • Accommodation suggestions\n"
" • Budget considerations"
),
agent=travel_agent
)
crew = Crew(
agents=[travel_agent],
tasks=[task],
process=Process.sequential,
verbose=True
)
crew.kickoff()
```
## Tool-Based vs Automatic Memory
**Use `HonchoStorage`** for automatic memory - CrewAI handles everything transparently. Best for simple conversational flows.
**Use Honcho Tools** for strategic control - agents decide when and how to query memory. Best for multi-step reasoning, when different query types are needed, or multi-agent systems.
You can combine both: automatic memory for baseline context, tools for specific queries. See the [hybrid memory example](https://github.com/plastic-labs/honcho/blob/main/examples/crewai/python/examples/hybrid_memory_example.py) for a complete implementation.
<Note>
**Multi-Agent Memory:** Use Honcho tools with different `peer_id` values to give each agent distinct memory and identity.
</Note>
## Next Steps
Now that you have a working CrewAI integration with Honcho, you can:
- **Create specialized agents** with domain-specific memory and context
- **Use CrewAI's advanced features** like hierarchical processes, tool delegation, and conditional task execution
- **Leverage logical reasoning** via the Dialectic API for deep `peer` understanding
- **Implement custom tools** to give agents explicit control over memory retrieval
## Related Resources
<CardGroup cols={2}>
<Card title="Honcho Architecture" icon="sitemap" href="/v2/documentation/core-concepts/architecture">
Understand Honcho's peer-based model and core primitives
</Card>
<Card title="Get Context" icon="messages" href="/v2/documentation/core-concepts/features/get-context">
Learn about retrieving and formatting conversation context
</Card>
<Card title="Dialectic API" icon="brain" href="/v2/documentation/core-concepts/features/dialectic">
Query `peer` representations for deeper understanding
</Card>
<Card title="LangGraph Integration" icon="diagram-project" href="/v2/integrations/langgraph">
Build stateful agents with LangGraph and Honcho
</Card>
</CardGroup>

363
docs/v2.6.0-alpha/guides/integrations/langgraph.mdx Normal file
View File

@ -0,0 +1,363 @@
---
title: "LangGraph"
icon: 'diagram-project'
description: "Build a stateful conversational AI agent with LangGraph and Honcho"
sidebarTitle: 'LangGraph'
---
Integrate Honcho with LangGraph to build a conversational AI agent that maintains memory across sessions. This guide shows you how to use Honcho's memory layer with LangGraph's orchestration.
<Note>
The full code is available on [GitHub](https://github.com/plastic-labs/honcho/tree/main/examples/langgraph) with examples in both [Python](https://github.com/plastic-labs/honcho/blob/main/examples/langgraph/python/main.py) and [TypeScript](https://github.com/plastic-labs/honcho/blob/main/examples/langgraph/typescript/main.ts)
</Note>
## What We're Building
We'll create a conversational agent that remembers and reasons over past exchanges with the user. Here's how the pieces fit together:
- **LangGraph** orchestrates the conversation flow
- **Honcho** stores messages and retrieves relevant context
- **Your LLM** generates responses using Honcho's formatted context
The key benefit: You don't manually manage conversation history, token limits, or message formatting. Honcho handles memory so you can focus on your agent's logic.
<Note>
This tutorial demonstrates a simple linear conversation flow to show
how Honcho integrates with LangGraph. For production applications,
you'll likely want to add LangGraph features like conditional routing,
tool calling, and multi-agent orchestration.
</Note>
## Setup
Install required packages:
<CodeGroup>
```bash Python (uv)
uv add honcho-ai langgraph langchain-core openai python-dotenv
```
```bash Python (pip)
pip install honcho-ai langgraph langchain-core openai python-dotenv
```
```bash TypeScript (npm)
npm install @honcho-ai/sdk @langchain/langgraph openai dotenv
```
```bash TypeScript (yarn)
yarn add @honcho-ai/sdk @langchain/langgraph openai dotenv
```
```bash TypeScript (pnpm)
pnpm add @honcho-ai/sdk @langchain/langgraph openai dotenv
```
</CodeGroup>
This tutorial uses OpenAI, but Honcho works with any LLM provider. Create a `.env` file with your API keys:
```bash
OPENAI_API_KEY=your_openai_key
```
<Note>
This tutorial uses the Honcho demo server at https://demo.honcho.dev which runs a small instance of Honcho on the latest version. For production, get your Honcho API key at [app.honcho.dev](https://app.honcho.dev). For local development, use `environment="local"`.
</Note>
## Initialize Clients
<CodeGroup>
```python Python
import os
from dotenv import load_dotenv
from typing_extensions import TypedDict
from honcho import Honcho, Peer, Session
from openai import OpenAI
from langgraph.graph import StateGraph, START, END
load_dotenv()
# Initialize Honcho
honcho = Honcho()
# Initialize OpenAI
llm = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
```
```typescript TypeScript
import * as dotenv from "dotenv";
import { Honcho, Peer, Session } from "@honcho-ai/sdk";
import OpenAI from "openai";
import { Annotation } from "@langchain/langgraph";
import { StateGraph, START, END } from "@langchain/langgraph";
import * as readline from "readline/promises";
dotenv.config();
// Initialize Honcho
const honcho = new Honcho({});
// Initialize OpenAI
const llm = new OpenAI({
apiKey: process.env.OPENAI_API_KEY
});
```
</CodeGroup>
## Define LangGraph State
Define your state schema to pass data through the graph. The state stores Honcho objects directly along with the current user message and assistant response.
<Note>
Before proceeding, it's important to understand Honcho's core concepts (`Peers` and `Sessions`). Review the [Honcho Architecture](/v2/documentation/core-concepts/architecture) to familiarize yourself with these primitives.
</Note>
<CodeGroup>
```python Python
class State(TypedDict):
user_message: str
assistant_response: str
user: Peer
assistant: Peer
session: Session
```
```typescript TypeScript
const StateAnnotation = Annotation.Root({
userMessage: Annotation<string>(),
assistantResponse: Annotation<string>(),
user: Annotation<Peer>(),
assistant: Annotation<Peer>(),
session: Annotation<Session>(),
});
type State = typeof StateAnnotation.State;
```
</CodeGroup>
## Build the LangGraph
Define your chatbot logic, using Honcho to retrieve conversation context. This function demonstrates how Honcho can store messages, retrieve context, and generate responses.
<CodeGroup>
```python Python
def chatbot(state: State):
user_message = state["user_message"]
# Get objects from state
user = state["user"]
assistant = state["assistant"]
session = state["session"]
# Step 1: Store the user's message in the session
# This adds it to Honcho's memory for future context retrieval
session.add_messages([user.message(user_message)])
# Step 2: Get context in OpenAI format with token limit
# get_context() retrieves relevant conversation history
# tokens=2000 limits the context to 2000 tokens to manage costs and fit within model limits
# to_openai() converts it to the format expected by OpenAI's API
messages = session.get_context(tokens=2000).to_openai(assistant=assistant)
# Step 3: Generate response using the context
response = llm.chat.completions.create(
model="gpt-5.1",
messages=messages
)
assistant_response = response.choices[0].message.content
# Step 4: Store assistant response in Honcho for future context
session.add_messages([assistant.message(assistant_response)])
return {"assistant_response": assistant_response}
```
```typescript TypeScript
async function chatbot(state: State) {
const userMessage = state.userMessage;
// Get objects from state
const user = state.user;
const assistant = state.assistant;
const session = state.session;
// Step 1: Store the user's message in the session
// This adds it to Honcho's memory for future context retrieval
await session.addMessages([user.message(userMessage)]);
// Step 2: Get context in OpenAI format with token limit
// getContext() retrieves relevant conversation history
// tokens: 2000 limits the context to 2000 tokens to manage costs and fit within model limits
// toOpenAI() converts it to the format expected by OpenAI's API
const messages = (await session.getContext({ tokens: 2000 })).toOpenAI(assistant);
// Step 3: Generate response using the context
const response = await llm.chat.completions.create({
model: "gpt-5.1",
messages: messages
});
const assistantResponse = response.choices[0].message.content!;
// Step 4: Store assistant response for future context
await session.addMessages([assistant.message(assistantResponse)]);
return { assistantResponse: assistantResponse };
}
```
</CodeGroup>
Now let's build the LangGraph:
<CodeGroup>
```python Python
graph = StateGraph(State) \
.add_node("chatbot", chatbot) \
.add_edge(START, "chatbot") \
.add_edge("chatbot", END) \
.compile()
```
```typescript TypeScript
const graph = new StateGraph(StateAnnotation)
.addNode("chatbot", chatbot)
.addEdge(START, "chatbot")
.addEdge("chatbot", END)
.compile();
```
</CodeGroup>
### Understanding get_context()
The [`get_context()`](/v2/documentation/core-concepts/features/get-context) method retrieves comprehensive conversation context and formats it for your LLM. It automatically:
- **Manages conversation history** - Tracks all messages and determines what's relevant
- **Respects token limits** - Stays within context window constraints without manual counting
- **Handles long conversations** - Combines recent detailed messages with summaries of older exchanges
- **Provides `peer` understanding** - Includes representations and `peer` cards when requested
The `SessionContext` object always includes fields for messages, summaries, `peer` representations, and `peer` cards. By default, only `messages` and `summary` are populated. To populate peer-specific context, pass a `peer_target` parameter:
**Using `peer_target` for Context:**
- **Without `peer_perspective`**: Returns Honcho's omniscient view of `peer_target` (all observations and context)
- **With `peer_perspective`**: Returns what `peer_perspective` knows about `peer_target` (perspective-based observations and context)
That's it. Call `session.get_context().to_openai(assistant)` and you get properly formatted context tailored for your assistant.
<Tip>
**Adding System Prompts:** Since `get_context()` returns conversation messages, you can easily prepend custom system instructions. Just add your system prompt to the beginning of the messages array before sending it to your LLM: `[{"role": "system", "content": "..."}, ...context_messages]`.
</Tip>
<Note>
For more details on all available parameters, see [`get_context() documentation`](/v2/documentation/core-concepts/features/get-context)
</Note>
## Chat Loop
Now we'll create the main conversation function. To simplify logic, we initialize Honcho objects once per conversation and pass them through the LangGraph state.
The `run_conversation_turn` function initializes a Honcho `Session` and `Peer` objects, passes them to the LangGraph, and returns the assistant's response. By calling it repeatedly with the same `user_id` and in the same session, the chat builds context over time.
<Note>
**Production Usage:** Honcho accepts any nanoid-compatible string for `user_id` and `session_id`. You can use IDs directly from your authentication system (Auth0, Firebase, Clerk, etc.) and session management without modification.
This tutorial uses hardcoded values for simplicity.
</Note>
<CodeGroup>
```python Python
def run_conversation_turn(user_id: str, user_input: str, session_id: str | None = None):
if not session_id:
session_id = f"session_{user_id}"
# Initialize Honcho objects
user = honcho.peer(user_id)
assistant = honcho.peer("assistant")
session = honcho.session(session_id)
result = graph.invoke({
"user_message": user_input,
"user": user,
"assistant": assistant,
"session": session
})
return result["assistant_response"]
if __name__ == "__main__":
print("Welcome to the AI Assistant! How can I help you today?")
user_id = "test-user-123"
while True:
user_input = input("You: ")
if user_input.lower() in ['quit', 'exit']:
break
response = run_conversation_turn(user_id, user_input)
print(f"Assistant: {response}\n")
```
```typescript TypeScript
async function runConversationTurn(
userId: string,
userInput: string,
sessionId?: string
): Promise<string> {
if (!sessionId) {
sessionId = `session_${userId}`;
}
// Initialize Honcho objects
const user = await honcho.peer(userId);
const assistant = await honcho.peer("assistant");
const session = await honcho.session(sessionId);
const result = await graph.invoke({
userMessage: userInput,
user: user,
assistant: assistant,
session: session,
});
return result.assistantResponse;
}
// Interactive chat loop
async function main() {
console.log("Welcome to the AI Assistant! How can I help you today?");
const userId = "test-user-123";
const rl = readline.createInterface({
input: process.stdin,
output: process.stdout,
});
while (true) {
const userInput = await rl.question("You: ");
if (userInput.toLowerCase() === "quit" || userInput.toLowerCase() === "exit") {
rl.close();
break;
}
const response = await runConversationTurn(userId, userInput);
console.log(`Assistant: ${response}\n`);
}
}
main();
```
</CodeGroup>
## Next Steps
Now that you have a working LangGraph integration with Honcho, you can:
- **Create custom [LangChain tools](https://docs.langchain.com/oss/python/langchain/tools#customize-tool-properties) for your agent** - to fully utilize Honcho's memory & context management features
- **Build a multi-agent LangGraph** where each agent is a Honcho `Peer` with its own memory
## Related Resources
<CardGroup cols={2}>
<Card title="Get Context" icon="messages" href="/v2/documentation/core-concepts/features/get-context">
Learn more about retrieving and formatting conversation context
</Card>
<Card title="MCP Integration" icon="star-of-life" href="/v2/integrations/mcp">
Use Honcho in Claude Desktop with MCP
</Card>
</CardGroup>

73
docs/v2.6.0-alpha/guides/integrations/mcp.mdx Normal file
View File

@ -0,0 +1,73 @@
---
title: "Model Context Protocol (MCP)"
icon: 'star-of-life'
description: "Use Honcho in Claude Desktop"
sidebarTitle: 'MCP'
---
You can let Claude use Honcho to manage its own memory in the native desktop app by using the Honcho MCP integration! Follow these steps:
1. Go to https://app.honcho.dev and get an API key. Then go to Claude Desktop and navigate to custom MCP servers.
<Note>
If you don't have node installed you will need to do that. Claude Desktop or Claude Code can help!
</Note>
2. Add Honcho to your Claude desktop config. You must provide a username for Honcho to refer to you as -- preferably what you want Claude to actually call you.
```json
{
"mcpServers": {
"honcho": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.honcho.dev",
"--header",
"Authorization:${AUTH_HEADER}",
"--header",
"X-Honcho-User-Name:${USER_NAME}"
],
"env": {
"AUTH_HEADER": "Bearer <your-honcho-key>",
"USER_NAME": "<your-name>"
}
}
}
}
```
You may customize your assistant name and/or workspace ID. Both are optional.
```json
{
"mcpServers": {
"honcho": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.honcho.dev",
"--header",
"Authorization:${AUTH_HEADER}",
"--header",
"X-Honcho-User-Name:${USER_NAME}",
"--header",
"X-Honcho-Assistant-Name:${ASSISTANT_NAME}",
"--header",
"X-Honcho-Workspace-ID:${WORKSPACE_ID}"
],
"env": {
"AUTH_HEADER": "Bearer <your-honcho-key>",
"USER_NAME": "<your-name>",
"ASSISTANT_NAME": "<your-assistant-name>",
"WORKSPACE_ID": "<your-custom-workspace-id>"
}
}
}
}
```
3. Restart the Claude Desktop app. Upon relaunch, it should start Honcho and the tools should be available!
4. Finally, Claude needs instructions on how to use Honcho. The Desktop app doesn't allow you to add system prompts directly, but you can create a project and paste these [instructions](https://raw.githubusercontent.com/plastic-labs/honcho/refs/heads/main/mcp/instructions.md) into the "Project Instructions" field.
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/tree/main/mcp)!

296
docs/v2.6.0-alpha/guides/migrations/mem0.mdx Normal file
View File

@ -0,0 +1,296 @@
---
title: 'Migrating from Mem0'
description: 'A guide to migrate from Mem0 to Honcho'
icon: 'arrow-right-arrow-left'
---
Interested in transferring your data from Mem0 to Honcho? This guide covers why to switch, how to migrate your data, and differences between the two products.
## Why Honcho?
Mem0 & Honcho both store your data. Only Honcho reasons about it. [Read more about our approach](https://blog.plasticlabs.ai/blog/Memory-as-Reasoning).
**Compounding Insights** - Honcho extracts insights that build on each other over time. The more your users interact, the richer and more accurate their profiles become.
**Superior Performance** - Higher accuracy on memory retrieval benchmarks with faster inference times (more details soon!).
**Competitive Pricing** - Mem0 charges for retrieval, not ingestion. Meaning you pay to access your own data. Honcho offers straightforward pricing with a generous free tier.
**Advanced Multi-Peer Sessions** - Honcho offers configurable observation settings (who builds memories about whom), representation-based queries between participants, and first-class peer objects.
<Note>
We would love to support the transfer and cost—just [book a call!](https://cal.com/team/plasticlabs/migration-to-honcho)
</Note>
## Quick Migration
For the best results, we recommend importing your raw messages directly into Honcho. This gives Honcho the full context to build rich, accurate representations and enables features like session summaries.
However, if you'd like to get started quickly, you can migrate your existing Mem0 memories directly as **observations**.
<Info>
Get your API key at [app.honcho.dev/api-keys](https://app.honcho.dev/api-keys). New accounts start with $100 credits.
</Info>
<CodeGroup>
```python Python
# pip install mem0ai honcho-ai
from mem0 import MemoryClient
from honcho import Honcho
# Export from Mem0
mem0 = MemoryClient(api_key="your-mem0-api-key")
memories = mem0.get_all(filters={"user_id": "user123"}, page_size=100)
# Initialize Honcho
honcho = Honcho(api_key="your-honcho-api-key")
user = honcho.peer("user123")
session = honcho.session("imported")
session.add_peers([user])
# Import memories directly as observations
observations = []
for memory in memories['results']:
content = memory.get("memory") or memory.get("messages", [{}])[0].get("content", "")
if content:
observations.append({"content": content, "session_id": "imported"})
# Batch create observations (up to 100 at a time)
if observations:
user.observations.create(observations)
print(f"Migrated {len(observations)} memories as observations!")
```
```typescript TypeScript
// npm install mem0ai @honcho-ai/sdk
import MemoryClient from "mem0ai";
import { Honcho } from "@honcho-ai/sdk";
// Export from Mem0
const mem0 = new MemoryClient({ apiKey: "your-mem0-api-key" });
const memories = await mem0.getAll({ filters: { user_id: "user123" }, page_size: 100 });
// Initialize Honcho
const honcho = new Honcho({ apiKey: "your-honcho-api-key" });
const user = await honcho.peer("user123");
const session = await honcho.session("imported");
await session.addPeers([user]);
// Import memories directly as observations
const observations = memories.results
.map(memory => ({
content: memory.memory || memory.messages?.[0]?.content || "",
session_id: "imported"
}))
.filter(obs => obs.content);
// Batch create observations (up to 100 at a time)
if (observations.length > 0) {
await user.observations.create(observations);
}
console.log(`Migrated ${observations.length} memories as observations!`);
```
</CodeGroup>
That's it! The user's Mem0 memories are now searchable in Honcho as observations. For richer representations with deductive reasoning and session summaries, consider importing your raw messages as described in the [Step-by-Step Migration](#step-by-step-migration) section.
For more details on replacing Mem0 API calls with Honcho equivalents go to [API Comparison](#api-comparison).
## Step-by-Step Migration
Prefer a more detailed walkthrough? Follow these steps:
### 1. Export User Messages
Importing raw user messages gives Honcho the full conversational context to build the most accurate representations. We recommend using a data structure that preserves the session and peer structure.
<Note>
If you need any help with this transfer or have any questions, please reach out at hello@plasticlabs.ai or [book a call!](https://cal.com/team/plasticlabs/migration-to-honcho)
</Note>
Alternatively, if you want to import the Mem0 memories, follow the example above and find more info in Mem0's [export API documentation](https://docs.mem0.ai/cookbooks/essentials/exporting-memories).
### 2. Install the Honcho SDK
<CodeGroup>
```bash Python (uv)
uv add honcho-ai
```
```bash Python (pip)
pip install honcho-ai
```
```bash TypeScript (npm)
npm install @honcho-ai/sdk
```
```bash TypeScript (yarn)
yarn add @honcho-ai/sdk
```
```bash TypeScript (pnpm)
pnpm add @honcho-ai/sdk
```
</CodeGroup>
### 3. Initialize the Honcho Client
<Info>
Get your API key at [app.honcho.dev/api-keys](https://app.honcho.dev/api-keys). New accounts start with $100 credits.
</Info>
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho( api_key="your-api-key" )
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
const honcho = new Honcho({apiKey: process.env.HONCHO_API_KEY!});
```
</CodeGroup>
### 4. Import Your Data
This is a possible implementation using raw user messages. Adapt the data structure to match your exported format.
<CodeGroup>
```python Python
# Example data structure (preserving message history with timestamps):
exported_data = {
"session-1": {
"user123": [
{"content": "I prefer dark mode", "timestamp": "2024-01-15T10:30:00Z"},
{"content": "My name is Alex", "timestamp": "2024-01-15T10:31:00Z"},
],
"user456": [
{"content": "I work in finance", "timestamp": "2024-01-15T11:00:00Z"},
{"content": "I like concise responses", "timestamp": "2024-01-15T11:02:00Z"},
],
},
"session-2": {
"user123": [
{"content": "Meeting notes from last week...", "timestamp": "2024-01-16T09:00:00Z"},
],
}
}
# Import into Honcho
for session_name, users in exported_data.items():
session = honcho.session(session_name)
for user_id, messages in users.items():
peer = honcho.peer(user_id)
session.add_peers([peer])
# Sort by timestamp to preserve message order
sorted_messages = sorted(messages, key=lambda m: m["timestamp"])
session.add_messages([peer.message(m["content"]) for m in sorted_messages])
```
```typescript TypeScript
// Example data structure (preserving message history with timestamps):
interface Message {
content: string;
timestamp: string;
}
const exportedData: Record<string, Record<string, Message[]>> = {
"session-1": {
"user123": [
{ content: "I prefer dark mode", timestamp: "2024-01-15T10:30:00Z" },
{ content: "My name is Alex", timestamp: "2024-01-15T10:31:00Z" },
],
"user456": [
{ content: "I work in finance", timestamp: "2024-01-15T11:00:00Z" },
{ content: "I like concise responses", timestamp: "2024-01-15T11:02:00Z" },
],
},
"session-2": {
"user123": [
{ content: "Meeting notes from last week...", timestamp: "2024-01-16T09:00:00Z" },
],
}
};
// Import into Honcho
for (const [sessionName, users] of Object.entries(exportedData)) {
const session = await honcho.session(sessionName);
for (const [userId, messages] of Object.entries(users)) {
const peer = await honcho.peer(userId);
await session.addPeers([peer]);
// Sort by timestamp to preserve message order
const sortedMessages = messages.sort((a, b) =>
new Date(a.timestamp).getTime() - new Date(b.timestamp).getTime()
);
await session.addMessages(sortedMessages.map((m) => peer.message(m.content)));
}
}
```
</CodeGroup>
### 5. Update Your Application Code
Reference the [API Comparison](#api-comparison) to replace your Mem0 API calls with the Honcho equivalents.
## API Comparison
### Core Operations
| Operation | Mem0 | Honcho | Notes |
|-----------|------|--------|-------|
| **Initialize** | `MemoryClient(api_key=...)` | `Honcho(api_key=...)` | |
| **Identity** | `user_id` string param | `peer = honcho.peer("id")` | Peers can be users or AI agents |
| **Add messages** | `client.add(messages, user_id=...)` | `session.add_messages([peer.message(...)])` | Session-scoped, triggers reasoning |
| **Add observations** | | `peer.observations.create([...])` | Direct observation or "memory" import, no processing |
| **Search** | `client.search(query, filters={"user_id": ...})` | `peer.search(query)` or `peer.observations.query(...)` | Scoped to peer or session |
| **List all** | `client.get_all(filters={"user_id": ...})` | `session.get_messages()` or `peer.observations.list()` | Messages or observations |
| **Update** | `client.update(memory_id, data=...)` | `honcho.update_message(message, metadata=...)` | Metadata updates only |
| **Delete** | `client.delete(memory_id)` | `peer.observations.delete(id)` or `session.delete()` | Observation or session-level |
### Honcho-Only Capabilities
Mem0 requires manual assembly of context from `search()` results. Honcho's `session.get_context()` returns a ready-to-use `SessionContext` object with built-in token limits, auto-included summaries, and format helpers (`.to_openai()`, `.to_anthropic()`).
<Card title="Get Context" icon="window-restore" href="../../documentation/core-concepts/features/get-context">
Learn more about token-optimized context retrieval
</Card>
Mem0's `search()` returns basic vector, semantic, or raw memory matches. Honcho's `peer.chat()` enables your agent to *reason* about what it knows—returning synthesized natural language insights with streaming support and scoped queries.
<Card title="Dialectic Endpoint" icon="brain" href="../../documentation/core-concepts/features/dialectic-endpoint">
Learn more about inference-powered queries
</Card>
Additional features with **no Mem0 equivalent**:
| Honcho Method | Description | Use Case |
|---------------|-------------|----------|
| `peer.card()` | Stable biographical facts (name, preferences, background) | User profiles, personalization |
| `session.working_rep(peer)` | Cached psychological analysis (mental state, intentions) | Real-time adaptation |
| `session.get_summaries()` | Auto-generated short/long session summaries | Conversation continuity |
| `SessionPeerConfig` | Configure observation settings (who learns about whom) | Privacy controls, role-based learning |
## Next Steps
<CardGroup cols={3}>
<Card title="Architecture" icon="rocket" href="../../documentation/core-concepts/architecture">
Understand peers and sessions
</Card>
<Card title="Dialectic API" icon="brain" href="../../documentation/core-concepts/features/dialectic-endpoint">
Inference responses
</Card>
<Card title="Guides" icon="book" href="../../guides/overview">
Integration examples
</Card>
</CardGroup>
Questions? Join our [Discord](https://discord.gg/honcho) or open an issue on [GitHub](https://github.com/plastic-labs/honcho/issues).

37
docs/v2.6.0-alpha/guides/overview.mdx Normal file
View File

@ -0,0 +1,37 @@
---
title: "Guides, Cookbooks, and Integrations"
sidebarTitle: 'Overview'
description: 'Helpful guides and design patterns for building with Honcho'
icon: 'hat-wizard'
---
<Note> Before you start a guide, follow [Quickstart](/v2/documentation/introduction/quickstart) to get up and running with Honcho in your language of choice. </Note>
These guides provide concrete examples and implementation patterns for building with Honcho. Whether you're integrating Honcho into existing platforms, exploring advanced features, or getting up and running quickly, you'll find working code you can adapt to your needs.
Each guide focuses on a specific use case with practical examples. The goal is to get you from idea to working prototype as quickly as possible, then provide the depth you need to scale and customize.
## Getting Started
Quick integration guides to get up and running:
<CardGroup cols={2}>
<Card title="MCP Integration" icon="link" href="/v2/integrations/mcp">
Get Honcho running with a single prompt in Claude Code
</Card>
<Card title="LangGraph" icon="diagram-project" href="/v2/integrations/langgraph">
Add persistent memory and theory of mind to your LangGraph agents
</Card>
</CardGroup>
## Application Interfaces
Ready-to-use integration patterns for popular platforms:
<CardGroup cols={2}>
<Card title="Discord Bot" icon="discord" href="/v2/guides/discord">
Build a Discord bot that remembers users across conversations
</Card>
<Card title="Telegram Bot" icon="telegram" href="/v2/guides/telegram">
Create a Telegram bot with persistent user understanding
</Card>
</CardGroup>

61
docs/v2.6.0-alpha/guides/storing-data.mdx Normal file
View File

@ -0,0 +1,61 @@
---
title: Storing Data
description: "Store Data in Honcho to Generate Memories and Insights"
icon: "memory"
---
The most basic building block of Honcho's data model is the `Message` object.
A `Message` is sent by a `Peer` and saved in a `Session`
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho()
peer = honcho.peer("sample-peer")
session = honcho.session("sample-session")
message = peer.message("Hello, world!")
session.add_messages([message])
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
const honcho = new Honcho({});
const peer = await honcho.peer('sample-peer');
const session = await honcho.session('sample-session');
const message = peer.message('Hello, world!');
await session.addMessages([message]);
```
</CodeGroup>
Once a `Message` is saved in Honcho, it will kick off a background task that
looks at the new data to generate insights about the `Peer` that sent the `Message`
This is the default behavior of Honcho and can be turned off by [configuring the
Peer or Session](/v2/documentation/core-concepts/configuration)
This pattern of having a Peer, Session, and Messages is highly flexible and
works for many different use cases and agent setups. Some use cases may only
need a single Peer, but many Sessions. Others will only use a single `Session`
for their entire app. These are flexible components that work in any situation.
## Chat Bots
A common use case for Honcho to is to build a chatbot like ChatGPT or Claude.
In this case you can simply
- Make a `Peer` for the User
- Make a `Peer` for the AI
Then you can make a `Session` for each thread of conversation and save
`Messages` from the user and assistant in each turn of conversation

359
docs/v2.6.0-alpha/guides/telegram.mdx Normal file
View File

@ -0,0 +1,359 @@
---
title: "Telegram Bots with Honcho"
icon: 'telegram'
description: "Use Honcho to build a Telegram bot with conversational memory and context management."
sidebarTitle: 'Telegram Bot'
---
> Example code is available on [GitHub](https://github.com/plastic-labs/telegram-python-starter)
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
**Telegram** as an interface. If you're not familiar with Telegram bot
development, the [python-telegram-bot](https://docs.python-telegram-bot.org/en/stable/) docs would be a good
place to start.
## Message Handling
Most Telegram bots have async functions that handle incoming messages. We can use Honcho to store messages by user and session based on the chat context. Take the following function definition for example:
```python
async def handle_message(update: Update, context: ContextTypes.DEFAULT_TYPE):
"""
Receive a message from Telegram and respond with a message from our LLM assistant.
"""
if not validate_message(update, context):
return
message_text = update.effective_message.text
input_text = sanitize_message(message_text, context.bot.username)
# If the message is empty after sanitizing, ignore it
if not input_text:
return
peer = honcho_client.peer(id=get_peer_id_from_telegram(update))
session = honcho_client.session(id=str(update.effective_chat.id))
# Send typing indicator
await context.bot.send_chat_action(
chat_id=update.effective_chat.id, action="typing"
)
response = llm(session, input_text)
await send_telegram_message(update, context, response)
# Save both the user's message and the bot's response to the session
session.add_messages(
[
peer.message(input_text),
assistant.message(response),
]
)
```
Let's break down what this code is doing...
```python
async def handle_message(update: Update, context: ContextTypes.DEFAULT_TYPE):
if not validate_message(update, context):
return
```
This is how you define a message handler in `python-telegram-bot` that processes incoming messages. We use a helper function `validate_message()` to check if the message should be processed.
## Helper Functions
The code uses several helper functions to keep the main logic clean and readable. Let's examine each one:
### Message Validation
```python
def validate_message(update: Update, context: ContextTypes.DEFAULT_TYPE) -> bool:
"""
Determine if the message is valid for the bot to respond to.
Return True if it is, False otherwise. The bot will respond to:
- Direct messages (private chats)
- Group messages that mention the bot or reply to it
- Messages that are not from the bot itself
"""
message = update.effective_message
if not message or not message.text:
return False
# Don't respond to our own messages
if message.from_user.id == context.bot.id:
return False
# Always respond in private chats
if update.effective_chat.type == "private":
return True
# In groups, only respond if mentioned or replied to
if (
message.reply_to_message
and message.reply_to_message.from_user.id == context.bot.id
):
return True
# Check if bot is mentioned
if message.entities:
for entity in message.entities:
if entity.type == "mention":
username = message.text[entity.offset : entity.offset + entity.length]
if username == f"@{context.bot.username}":
return True
return False
```
This function centralizes all the logic for determining whether the bot should respond to a message. It handles different chat types:
- **Private chats**: Always respond
- **Group chats**: Only respond when mentioned or when replying to the bot's messages
- **Bot prevention**: Never respond to the bot's own messages
### Message Sanitization
```python
def sanitize_message(message_text: str, bot_username: str) -> str | None:
"""Remove the bot's mention from the message content if present"""
content = message_text.replace(f"@{bot_username}", "").strip()
if not content:
return None
return content
```
This helper removes the bot's mention from the message content, leaving just the actual user input.
### Peer ID Generation
```python
def get_peer_id_from_telegram(update: Update) -> str:
"""Get a Honcho peer ID for the message author"""
return f"telegram_{update.effective_user.id}"
```
This creates a unique peer identifier for each Telegram user by prefixing their Telegram user ID.
### LLM Integration
```python
def llm(session, prompt) -> str:
"""
Call the LLM with the given prompt and chat history.
You should expand this function with custom logic, prompts, etc.
"""
messages: list[dict[str, object]] = session.get_context().to_openai(
assistant=assistant
)
messages.append({"role": "user", "content": prompt})
try:
completion = openai.chat.completions.create(
model=MODEL_NAME,
messages=messages,
)
return completion.choices[0].message.content
except Exception as e:
logger.error(f"LLM error: {e}")
return f"Error: {e}"
```
This function handles the LLM interaction. It uses Honcho's built-in `to_openai()` method to automatically convert the session context into the format expected by OpenAI's chat completions API.
### Message Sending
```python
async def send_telegram_message(
update: Update, context: ContextTypes.DEFAULT_TYPE, response_content: str
):
"""Send a message to the Telegram chat, splitting if necessary"""
# Telegram has a 4096 character limit, but we'll use 4000 to be safe
max_length = 4000
if len(response_content) <= max_length:
await update.effective_message.reply_text(response_content)
else:
# Split response into chunks at newlines, keeping under max_length chars
chunks = []
current_chunk = ""
for line in response_content.splitlines(keepends=True):
if len(current_chunk) + len(line) > max_length:
if current_chunk:
chunks.append(current_chunk)
current_chunk = line
else:
current_chunk += line
if current_chunk:
chunks.append(current_chunk)
for chunk in chunks:
await update.effective_message.reply_text(chunk)
```
This function handles sending messages to Telegram, automatically splitting long responses into multiple messages to stay within Telegram's 4096 character limit. It also includes a typing indicator to show the bot is processing.
## Honcho Integration
The new Honcho peer/session API makes integration much simpler:
```python
peer = honcho_client.peer(id=get_peer_id_from_telegram(update))
session = honcho_client.session(id=str(update.effective_chat.id))
```
Here we create a peer object for the user and a session object using the Telegram chat ID. This automatically handles user and session management across both private chats and group conversations.
```python
# Save both the user's message and the bot's response to the session
session.add_messages(
[
peer.message(input_text),
assistant.message(response),
]
)
```
After generating the response, we save both the user's input and the bot's response to the session using the `add_messages()` method. The `peer.message()` creates a message from the user, while `assistant.message()` creates a message from the assistant.
## Commands
Telegram bots support slash commands natively. Here's how to implement the `/dialectic` command using Honcho's dialectic feature:
```python
async def dialectic_command(update: Update, context: ContextTypes.DEFAULT_TYPE):
"""
Handle the /dialectic command to query the Honcho Dialectic endpoint.
"""
if not context.args:
await update.message.reply_text(
"Please provide a query. Usage: /dialectic <your query>"
)
return
query = " ".join(context.args)
try:
peer = honcho_client.peer(id=get_peer_id_from_telegram(update))
session = honcho_client.session(id=str(update.effective_chat.id))
response = peer.chat(
query=query,
session_id=session.id,
)
if response:
await send_telegram_message(update, context, response)
else:
await update.message.reply_text(
f"I don't know anything about {update.effective_user.first_name} because we haven't talked yet!"
)
except Exception as e:
logger.error(f"Error calling Dialectic API: {e}")
await update.message.reply_text(
f"Sorry, there was an error processing your request: {str(e)}"
)
```
You can also add a `/start` command for user onboarding:
```python
async def start_command(update: Update, context: ContextTypes.DEFAULT_TYPE):
"""Handle the /start command"""
await update.message.reply_text(
"Hello! I'm your AI assistant. You can:\n"
"• Chat with me directly in private messages\n"
"• Mention me (@username) in groups to get my attention\n"
"• Use /dialectic <query> to search our conversation history\n\n"
"Let's start chatting!"
)
```
## Setup and Configuration
The bot requires several environment variables and setup:
```python
honcho_client = Honcho()
assistant = honcho_client.peer(id="assistant", config={"observe_me": False})
openai = OpenAI(base_url="https://openrouter.ai/api/v1", api_key=MODEL_API_KEY)
```
- `honcho_client`: The main Honcho client
- `assistant`: A peer representing the bot/assistant
- `openai`: OpenAI client configured to use OpenRouter
### Application Setup
Register your handlers with the Telegram application:
```python
def main():
"""Start the bot"""
if not BOT_TOKEN:
logger.error("BOT_TOKEN not found in environment variables")
return
# Create the Application
application = Application.builder().token(BOT_TOKEN).build()
# Add handlers
application.add_handler(CommandHandler("start", start_command))
application.add_handler(CommandHandler("dialectic", dialectic_command))
application.add_handler(
MessageHandler(filters.TEXT & ~filters.COMMAND, handle_message)
)
# Start the bot
logger.info("Starting Telegram bot...")
application.run_polling(allowed_updates=Update.ALL_TYPES)
```
## Environment Variables
Your bot needs these environment variables:
```env
# Your Telegram bot token from BotFather
BOT_TOKEN=<your-token>
# AI model to use (see OpenRouter for available models)
MODEL_NAME=<your-model>
# Your OpenRouter API key
MODEL_API_KEY=<your-openrouter-api-key>
```
## Chat Types and Behavior
The bot handles different Telegram chat types intelligently:
### Private Chats
- **Behavior**: Responds to all messages
- **Session ID**: Uses the private chat ID
- **Memory**: Maintains conversation history per user
### Group Chats
- **Behavior**: Only responds when mentioned or replied to
- **Session ID**: Uses the group chat ID (shared across all members)
- **Memory**: Maintains group conversation context
## Recap
The new Honcho peer/session API makes Telegram bot integration much simpler and more intuitive. Key patterns we learned:
- **Peer/Session Model**: Users are represented as peers, conversations as sessions
- **Chat Type Handling**: Different validation logic for private vs group chats
- **Automatic Context Management**: `session.get_context().to_openai()` automatically formats chat history
- **Message Storage**: `session.add_messages()` stores both user and assistant messages
- **Dialectic Queries**: `peer.chat()` enables querying conversation history
- **Command System**: Native Telegram command support with `/start` and `/dialectic`
- **Message Splitting**: Automatic handling of Telegram's character limits
- **Helper Functions**: Clean code organization with focused helper functions
This approach provides a clean, maintainable structure for building Telegram bots with conversational memory and context management across both private conversations and group chats.

296
docs/v2.6.0-alpha/migrations/from-mem0.mdx Normal file
View File

@ -0,0 +1,296 @@
---
title: 'Migrating from Mem0'
description: 'A guide to migrate from Mem0 to Honcho'
icon: 'arrow-right-arrow-left'
---
Interested in transferring your data from Mem0 to Honcho? This guide covers why to switch, how to migrate your data, and differences between the two products.
## Why Honcho?
Mem0 & Honcho both store your data. Only Honcho reasons about it. [Read more about our approach](https://blog.plasticlabs.ai/blog/Memory-as-Reasoning).
**Compounding Insights** - Honcho extracts insights that build on each other over time. The more your users interact, the richer and more accurate their profiles become.
**Superior Performance** - Higher accuracy on memory retrieval benchmarks with faster inference times (more details soon!).
**Competitive Pricing** - Mem0 charges for retrieval, not ingestion. Meaning you pay to access your own data. Honcho offers straightforward pricing with a generous free tier.
**Advanced Multi-Peer Sessions** - Honcho offers configurable observation settings (who builds memories about whom), representation-based queries between participants, and first-class peer objects.
<Note>
We would love to support the transfer and cost—just [book a call!](https://cal.com/team/plasticlabs/migration-to-honcho)
</Note>
## Quick Migration
For the best results, we recommend importing your raw messages directly into Honcho. This gives Honcho the full context to build rich, accurate representations and enables features like session summaries.
However, if you'd like to get started quickly, you can migrate your existing Mem0 memories directly as **observations**.
<Info>
Get your API key at [app.honcho.dev/api-keys](https://app.honcho.dev/api-keys). New accounts start with $100 credits.
</Info>
<CodeGroup>
```python Python
# pip install mem0ai honcho-ai
from mem0 import MemoryClient
from honcho import Honcho
# Export from Mem0
mem0 = MemoryClient(api_key="your-mem0-api-key")
memories = mem0.get_all(filters={"user_id": "user123"}, page_size=100)
# Initialize Honcho
honcho = Honcho(api_key="your-honcho-api-key")
user = honcho.peer("user123")
session = honcho.session("imported")
session.add_peers([user])
# Import memories directly as observations
observations = []
for memory in memories['results']:
content = memory.get("memory") or memory.get("messages", [{}])[0].get("content", "")
if content:
observations.append({"content": content, "session_id": "imported"})
# Batch create observations (up to 100 at a time)
if observations:
user.observations.create(observations)
print(f"Migrated {len(observations)} memories as observations!")
```
```typescript TypeScript
// npm install mem0ai @honcho-ai/sdk
import MemoryClient from "mem0ai";
import { Honcho } from "@honcho-ai/sdk";
// Export from Mem0
const mem0 = new MemoryClient({ apiKey: "your-mem0-api-key" });
const memories = await mem0.getAll({ filters: { user_id: "user123" }, page_size: 100 });
// Initialize Honcho
const honcho = new Honcho({ apiKey: "your-honcho-api-key" });
const user = await honcho.peer("user123");
const session = await honcho.session("imported");
await session.addPeers([user]);
// Import memories directly as observations
const observations = memories.results
.map(memory => ({
content: memory.memory || memory.messages?.[0]?.content || "",
session_id: "imported"
}))
.filter(obs => obs.content);
// Batch create observations (up to 100 at a time)
if (observations.length > 0) {
await user.observations.create(observations);
}
console.log(`Migrated ${observations.length} memories as observations!`);
```
</CodeGroup>
That's it! The user's Mem0 memories are now searchable in Honcho as observations. For richer representations with deductive reasoning and session summaries, consider importing your raw messages as described in the [Step-by-Step Migration](#step-by-step-migration) section.
For more details on replacing Mem0 API calls with Honcho equivalents go to [API Comparison](#api-comparison).
## Step-by-Step Migration
Prefer a more detailed walkthrough? Follow these steps:
### 1. Export User Messages
Importing raw user messages gives Honcho the full conversational context to build the most accurate representations. We recommend using a data structure that preserves the session and peer structure.
<Note>
If you need any help with this transfer or have any questions, please reach out at hello@plasticlabs.ai or [book a call!](https://cal.com/team/plasticlabs/migration-to-honcho)
</Note>
Alternatively, if you want to import the Mem0 memories, follow the example above and find more info in Mem0's [export API documentation](https://docs.mem0.ai/cookbooks/essentials/exporting-memories).
### 2. Install the Honcho SDK
<CodeGroup>
```bash Python (uv)
uv add honcho-ai
```
```bash Python (pip)
pip install honcho-ai
```
```bash TypeScript (npm)
npm install @honcho-ai/sdk
```
```bash TypeScript (yarn)
yarn add @honcho-ai/sdk
```
```bash TypeScript (pnpm)
pnpm add @honcho-ai/sdk
```
</CodeGroup>
### 3. Initialize the Honcho Client
<Info>
Get your API key at [app.honcho.dev/api-keys](https://app.honcho.dev/api-keys). New accounts start with $100 credits.
</Info>
<CodeGroup>
```python Python
from honcho import Honcho
honcho = Honcho( api_key="your-api-key" )
```
```typescript TypeScript
import { Honcho } from '@honcho-ai/sdk';
const honcho = new Honcho({apiKey: process.env.HONCHO_API_KEY!});
```
</CodeGroup>
### 4. Import Your Data
This is a possible implementation using raw user messages. Adapt the data structure to match your exported format.
<CodeGroup>
```python Python
# Example data structure (preserving message history with timestamps):
exported_data = {
"session-1": {
"user123": [
{"content": "I prefer dark mode", "timestamp": "2024-01-15T10:30:00Z"},
{"content": "My name is Alex", "timestamp": "2024-01-15T10:31:00Z"},
],
"user456": [
{"content": "I work in finance", "timestamp": "2024-01-15T11:00:00Z"},
{"content": "I like concise responses", "timestamp": "2024-01-15T11:02:00Z"},
],
},
"session-2": {
"user123": [
{"content": "Meeting notes from last week...", "timestamp": "2024-01-16T09:00:00Z"},
],
}
}
# Import into Honcho
for session_name, users in exported_data.items():
session = honcho.session(session_name)
for user_id, messages in users.items():
peer = honcho.peer(user_id)
session.add_peers([peer])
# Sort by timestamp to preserve message order
sorted_messages = sorted(messages, key=lambda m: m["timestamp"])
session.add_messages([peer.message(m["content"]) for m in sorted_messages])
```
```typescript TypeScript
// Example data structure (preserving message history with timestamps):
interface Message {
content: string;
timestamp: string;
}
const exportedData: Record<string, Record<string, Message[]>> = {
"session-1": {
"user123": [
{ content: "I prefer dark mode", timestamp: "2024-01-15T10:30:00Z" },
{ content: "My name is Alex", timestamp: "2024-01-15T10:31:00Z" },
],
"user456": [
{ content: "I work in finance", timestamp: "2024-01-15T11:00:00Z" },
{ content: "I like concise responses", timestamp: "2024-01-15T11:02:00Z" },
],
},
"session-2": {
"user123": [
{ content: "Meeting notes from last week...", timestamp: "2024-01-16T09:00:00Z" },
],
}
};
// Import into Honcho
for (const [sessionName, users] of Object.entries(exportedData)) {
const session = await honcho.session(sessionName);
for (const [userId, messages] of Object.entries(users)) {
const peer = await honcho.peer(userId);
await session.addPeers([peer]);
// Sort by timestamp to preserve message order
const sortedMessages = messages.sort((a, b) =>
new Date(a.timestamp).getTime() - new Date(b.timestamp).getTime()
);
await session.addMessages(sortedMessages.map((m) => peer.message(m.content)));
}
}
```
</CodeGroup>
### 5. Update Your Application Code
Reference the [API Comparison](#api-comparison) to replace your Mem0 API calls with the Honcho equivalents.
## API Comparison
### Core Operations
| Operation | Mem0 | Honcho | Notes |
|-----------|------|--------|-------|
| **Initialize** | `MemoryClient(api_key=...)` | `Honcho(api_key=...)` | |
| **Identity** | `user_id` string param | `peer = honcho.peer("id")` | Peers can be users or AI agents |
| **Add messages** | `client.add(messages, user_id=...)` | `session.add_messages([peer.message(...)])` | Session-scoped, triggers reasoning |
| **Add observations** | | `peer.observations.create([...])` | Direct observation or "memory" import, no processing |
| **Search** | `client.search(query, filters={"user_id": ...})` | `peer.search(query)` or `peer.observations.query(...)` | Scoped to peer or session |
| **List all** | `client.get_all(filters={"user_id": ...})` | `session.get_messages()` or `peer.observations.list()` | Messages or observations |
| **Update** | `client.update(memory_id, data=...)` | `honcho.update_message(message, metadata=...)` | Metadata updates only |
| **Delete** | `client.delete(memory_id)` | `peer.observations.delete(id)` or `session.delete()` | Observation or session-level |
### Honcho-Only Capabilities
Mem0 requires manual assembly of context from `search()` results. Honcho's `session.get_context()` returns a ready-to-use `SessionContext` object with built-in token limits, auto-included summaries, and format helpers (`.to_openai()`, `.to_anthropic()`).
<Card title="Get Context" icon="window-restore" href="../../documentation/core-concepts/features/get-context">
Learn more about token-optimized context retrieval
</Card>
Mem0's `search()` returns basic vector, semantic, or raw memory matches. Honcho's `peer.chat()` enables your agent to *reason* about what it knows—returning synthesized natural language insights with streaming support and scoped queries.
<Card title="Dialectic Endpoint" icon="brain" href="../../documentation/core-concepts/features/dialectic-endpoint">
Learn more about inference-powered queries
</Card>
Additional features with **no Mem0 equivalent**:
| Honcho Method | Description | Use Case |
|---------------|-------------|----------|
| `peer.card()` | Stable biographical facts (name, preferences, background) | User profiles, personalization |
| `session.working_rep(peer)` | Cached psychological analysis (mental state, intentions) | Real-time adaptation |
| `session.get_summaries()` | Auto-generated short/long session summaries | Conversation continuity |
| `SessionPeerConfig` | Configure observation settings (who learns about whom) | Privacy controls, role-based learning |
## Next Steps
<CardGroup cols={3}>
<Card title="Architecture" icon="rocket" href="../../documentation/core-concepts/architecture">
Understand peers and sessions
</Card>
<Card title="Dialectic API" icon="brain" href="../../documentation/core-concepts/features/dialectic-endpoint">
Inference responses
</Card>
<Card title="Guides" icon="book" href="../../guides/overview">
Integration examples
</Card>
</CardGroup>
Questions? Join our [Discord](https://discord.gg/honcho) or open an issue on [GitHub](https://github.com/plastic-labs/honcho/issues).

4441
docs/v2.6.0-alpha/openapi.json Normal file
View File

File diff suppressed because it is too large Load Diff

2
sdks/python/pyproject.toml
View File

@ -8,7 +8,7 @@ authors = [
{ name = "Plastic Labs", email = "hello@plasticlabs.ai" },
]
dependencies = [
"honcho-core>=1.6.1",
"honcho-core>=1.7.0",
"httpx>=0.28.0, <1",
"pydantic>=2.0.0, <3",
"typing-extensions>=4.12.0; python_version < \"3.12\"",

4
sdks/typescript/bun.lock
View File

@ -4,7 +4,7 @@
"": {
"name": "@honcho-ai/sdk",
"dependencies": {
"@honcho-ai/core": "^1.6.1",
"@honcho-ai/core": "^1.7.0",
"@types/node": "^24.0.1",
"zod": "4.0.0",
},
@ -106,7 +106,7 @@
"@biomejs/cli-win32-x64": ["@biomejs/cli-win32-x64@2.3.8", "", { "os": "win32", "cpu": "x64" }, "sha512-RguzimPoZWtBapfKhKjcWXBVI91tiSprqdBYu7tWhgN8pKRZhw24rFeNZTNf6UiBfjCYCi9eFQs/JzJZIhuK4w=="],
"@honcho-ai/core": ["@honcho-ai/core@1.6.1", "", { "dependencies": { "@types/node": "^18.11.18", "@types/node-fetch": "^2.6.4", "abort-controller": "^3.0.0", "agentkeepalive": "^4.2.1", "form-data-encoder": "1.7.2", "formdata-node": "^4.3.2", "node-fetch": "^2.6.7" } }, "sha512-sfKIqAIybP/yj6iXGQLFgrqlX1dA7OuAK86p8sy8XiT64ZpEYpEz6viifAsm65LRZMgb0HPTFeBGodseUSoqVQ=="],
"@honcho-ai/core": ["@honcho-ai/core@1.7.0", "", { "dependencies": { "@types/node": "^18.11.18", "@types/node-fetch": "^2.6.4", "abort-controller": "^3.0.0", "agentkeepalive": "^4.2.1", "form-data-encoder": "1.7.2", "formdata-node": "^4.3.2", "node-fetch": "^2.6.7" } }, "sha512-ZZsRlz0DgXaWj5z81KKcw4dLlwSxHqsxuG/Gb9vaozqJa8SSj09IGMm3kJjRTxNOD/AhHxOxAX3l6WEq4VZL5g=="],
"@istanbuljs/load-nyc-config": ["@istanbuljs/load-nyc-config@1.1.0", "", { "dependencies": { "camelcase": "^5.3.1", "find-up": "^4.1.0", "get-package-type": "^0.1.0", "js-yaml": "^3.13.1", "resolve-from": "^5.0.0" } }, "sha512-VjeHSlIzpv/NyD3N0YuHfXOPDIixcA1q2ZV98wsMqcYlPmv2n3Yb2lYP9XMElnaFVXg5A7YLTeLu6V84uQDjmQ=="],

BIN
sdks/typescript/dist.tar.gz
View File

Binary file not shown.

2
sdks/typescript/package.json
View File

@ -20,7 +20,7 @@
"test:coverage": "jest --coverage"
},
"dependencies": {
"@honcho-ai/core": "^1.6.1",
"@honcho-ai/core": "^1.7.0",
"@types/node": "^24.0.1",
"zod": "4.0.0"
},

2
sdks/typescript/src/validation.ts
View File

@ -13,7 +13,7 @@ import { z } from 'zod'
*/
export const HonchoConfigSchema = z.object({
apiKey: z.string().optional(),
environment: z.enum(['local', 'production', 'demo']).optional(),
environment: z.enum(['local', 'production']).optional(),
baseURL: z.string().url('Base URL must be a valid URL').optional(),
workspaceId: z
.string()

2
src/schemas.py
View File

@ -173,6 +173,7 @@ class ResolvedConfiguration(BaseModel):
class PeerConfig(BaseModel):
# TODO: Update description - should say "Whether honcho forms a representation of the peer itself"
observe_me: bool | None = Field(
default=None,
description="Whether honcho should form a global theory-of-mind representation of this peer",
@ -180,6 +181,7 @@ class PeerConfig(BaseModel):
class SessionPeerConfig(PeerConfig):
# TODO: Update description - should say "Whether this peer forms representations of other peers in the session"
observe_others: bool | None = Field(
default=None,
description="Whether this peer should form a session-level theory-of-mind representation of other peers in the session",

2
tests/bench/.gitignore vendored
View File

@ -2,3 +2,5 @@ longmemeval_data
eval_results
perf_metrics
beam_data
obexeval_data
locomo_data

Some files were not shown because too many files have changed in this diff Show More