Une mémoire Dropstone partagée entre le chat, la CLI et le SDK
La mémoire de compte qui vous suit dans Dropstone Chat, la CLI et le SDK, ce qui la partage et ce qui ne la partage pas, et comment garder l'apprentissage d'une intégration hors de votre propre mémoire.
La mémoire est ce qui relie les surfaces de Dropstone entre elles. Apprenez-lui quelque chose une seule fois, sur n'importe laquelle d'entre elles, et cela sera disponible sur les autres : une mémoire par compte, pas une par outil.
Ce qui la partage
| Surface | Comment elle s'exécute | Partage la mémoire |
|---|---|---|
| Dropstone Chat | connecté | Oui |
| La CLI | connecté avec dropstone login | Oui |
| Le SDK, client agent local | démarre un serveur sous votre compte | Oui |
| Le SDK, client headless | une clé API contre le endpoint public | Non |
| Un chat incognito | lit la mémoire, n'en écrit aucune | Lit, n'écrit pas |
La règle derrière ce tableau est simple : une surface qui s'exécute en tant que vous possède votre mémoire, une surface conçue pour les pipelines ne la possède pas, et un mode lit sans écrire. Le endpoint headless est sans état par conception, donc la même entrée donne la même réponse, peu importe ce que vous avez appris à Dropstone la semaine dernière. Un chat incognito fonctionne dans l'autre sens : il travaille avec ce que Dropstone sait et ne conserve rien de ce qu'il produit.
Pourquoi cela compte dans le code
Un agent qui connaît vos conventions vaut plus qu'un agent que vous briefez à chaque appel. Une règle définie dans Chat s'applique dans une session démarrée par votre application, et un fait enregistré par une session SDK est là la prochaine fois que vous ouvrez la CLI. C'est l'effet cumulatif : plus vous travaillez avec Dropstone, moins chaque surface a besoin d'être informée. Voir Comment un agent apprend en travaillant.
Garder une intégration séparée
Si un service doit avoir sa propre mémoire plutôt que la vôtre, donnez-lui son propre compte, ou un compte de membre d'organisation dédié à cette intégration. Il apprendra alors sur l'intégration et rien d'autre, et votre propre mémoire restera la vôtre. Voir Mémoire et votre confidentialité.
L'éditeur et les autres intégrations
L'extension de l'éditeur, l'API et le reste des intégrations sont documentés dans la référence CLI, qui est le lieu dédié à la configuration spécifique aux surfaces : l'extension VS Code elle-même, la configuration VS Code, l'intégration IDE et l'API HTTP.
Related articles
- Memory across chat, CLI, and SDKDropstone memory belongs to your account, not to one app. A rule you set in the CLI applies in chat, and something learned in chat is available to the SDK. One memory, every surface.
- How Dropstone remembers youDropstone keeps a persistent memory that follows your account across chat, the CLI, and the SDK. Correct it once and it should not need correcting again, anywhere you use it.
- Dropstone SDKA typed TypeScript and JavaScript client for the Dropstone agent, with two entry points: one for headless API calls from CI or a serverless function, one that runs the agent locally with the same account memory as the CLI and Chat.
- Using the API with your planCall Dropstone over HTTP with an API key. The endpoint is OpenAI-compatible, billed pay-per-use from your credit balance, and works from any language. Keys, errors, rate limits, and what the API does not carry.
- Dropstone CLI overviewThe Dropstone CLI is an agent for your terminal that reads your codebase, edits files, runs commands, and shares memory with everything else on your account. Install it in one command. The full reference is at docs.dropstone.io.