Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
plastic-labs avatar

Migrate Honcho Ts

  • 324 installs
  • 6.4k repo stars
  • Updated August 4, 2026
  • plastic-labs/honcho

migrate-honcho-ts is a Claude Code skill that upgrades an existing Honcho TypeScript client when `.core`, config, streaming, and session-scoped APIs changed for developers who need a working SDK after breaking Honcho rel

About

migrate-honcho-ts is a migration skill from plastic-labs/honcho for upgrading the Honcho TypeScript SDK after breaking API changes. It replaces the removed `.core` property with `.http` for advanced HTTP access, updates listing methods so `workspaces()` returns `Page<string>` instead of `string[]`, and adjusts `session.peers()` to return `Peer[]` instead of `Page<Peer>`. Developers reach for migrate-honcho-ts when a TypeScript agent app using Honcho memory fails to compile or behave correctly after an SDK update affecting config, streaming, or session APIs.

  • Replaces removed `client.core` with `client.http` or automatic workspace handling
  • Documents `Page<string>` vs array returns for `workspaces()` and `session.peers()`
  • Moves `updateMessage` onto session and renames `config` to `configuration` with camelCase keys
  • Covers streaming removal on `chat()` and peer/session configuration shape updates

Migrate Honcho Ts by the numbers

  • 324 all-time installs (skills.sh)
  • +14 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #2,220 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Security screen: MEDIUM risk (skills.sh audit)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/plastic-labs/honcho --skill migrate-honcho-ts

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs324
repo stars6.4k
Security audit3 / 3 scanners passed
Last updatedAugust 4, 2026
Repositoryplastic-labs/honcho

How do you migrate Honcho TypeScript client after API changes?

Upgrade an existing Honcho TypeScript client to the current SDK when `.core`, `config`, streaming, and session-scoped APIs changed.

Who is it for?

TypeScript developers maintaining Honcho-powered agent apps who hit compile or runtime errors after SDK changes to `.core`, config, streaming, or session APIs.

Skip if: Python Honcho migrations, new Honcho TypeScript projects on the latest SDK, or apps not using the Honcho TypeScript client.

When should I use this skill?

User mentions Honcho TypeScript migration, `.core` removal, `.http` accessor, workspaces Page return type, or session.peers() API changes.

What you get

Updated TypeScript Honcho client using `.http` instead of `.core`, corrected Page and Peer[] return types, and fixed session-scoped API calls

  • Migrated TypeScript client code
  • Updated HTTP and pagination call patterns

By the numbers

  • Documents 2 listing return-type changes (`workspaces()` and `session.peers()`)
  • Covers removal of the `.core` property in favor of `.http`

Files

SKILL.mdMarkdownGitHub ↗

Honcho TypeScript SDK Migration (v1.6.0 → v2.1.1)

Overview

This skill migrates code from @honcho-ai/sdk v1.6.0 to v2.1.1 (required for Honcho 3.0.0+).

Key breaking changes:

  • @honcho-ai/core dependency removed
  • "Observation" → "Conclusion" terminology
  • "Deriver" → "Queue" terminology
  • getConfig/setConfiggetConfiguration/setConfiguration
  • snake_casecamelCase throughout
  • Streaming via chatStream() instead of chat({ stream: true })
  • Representation class removed (returns string now)

Quick Migration

1. Update dependencies

Remove @honcho-ai/core from package.json. The SDK now has its own HTTP client.

2. Replace .core with .http

// Before
const workspace = await client.core.workspaces.getOrCreate({ id: 'my-workspace' })

// After
const response = await client.http.post('/v3/workspaces', { body: { id: 'my-workspace' } })

3. Rename configuration methods

// Before
await honcho.getConfig()
await honcho.setConfig({ key: 'value' })
await peer.getConfig()
await session.getConfig()

// After
await honcho.getConfiguration()
await honcho.setConfiguration({ reasoning: { enabled: true } })
await peer.getConfiguration()
await session.getConfiguration()

4. Rename listing methods

// Before
const peers = await honcho.getPeers()
const sessions = await honcho.getSessions()
const workspaces = await honcho.getWorkspaces()  // string[]

// After
const peers = await honcho.peers()
const sessions = await honcho.sessions()
const workspaces = await honcho.workspaces()  // Page<string>

5. Update streaming

// Before
const stream = await peer.chat('Hello', { stream: true })

// After
const stream = await peer.chatStream('Hello')

6. Update observations → conclusions

// Before
peer.observations
peer.observationsOf('bob')
maxObservations: 50
includeMostDerived: true

// After
peer.conclusions
peer.conclusionsOf('bob')
maxConclusions: 50
includeMostFrequent: true

7. Update queue status methods

// Before
await honcho.getDeriverStatus({ observer: peer })
await honcho.pollDeriverStatus({ timeoutMs: 60000 })  // REMOVE - see note below

// After
await honcho.queueStatus({ observer: peer })
// pollDeriverStatus() has no replacement - see note below

Important: pollDeriverStatus() and its polling pattern have been removed entirely. Do not rely on the queue ever being empty. The queue is a continuous processing system—new messages may arrive at any time, and waiting for "completion" is not a valid pattern. If your code previously polled for queue completion, redesign it to work without that assumption.

8. Convert snake_case to camelCase

// Before
message.peer_id
message.session_id
message.created_at
message.token_count
{ observe_me: true, observe_others: false }
{ created_at: '2024-01-01' }

// After
message.peerId
message.sessionId
message.createdAt
message.tokenCount
{ observeMe: true, observeOthers: false }
{ createdAt: '2024-01-01' }

9. Update representation calls

// Before
const rep = await peer.workingRep(session, target, options)
console.log(rep.explicit)  // ExplicitObservation[]
console.log(rep.deductive) // DeductiveObservation[]

// After
const rep = await peer.representation({ session, target, ...options })
console.log(rep)  // string

10. Move updateMessage to session

// Before
await honcho.updateMessage(message, metadata, session)

// After
await session.updateMessage(message, metadata)

11. Update card() to getCard() (v2.0.1+)

// Before
const card = await peer.card(target)

// After (v2.0.1+)
const card = await peer.getCard(target)  // Returns string[] | null

// peer.card() still works but is deprecated — use getCard()

// New: setPeerCard / setCard
await peer.setCard(['Prefers dark mode', 'Located in US'])

12. Strict input validation (v2.0.2+)

Client constructor and all input schemas now reject unknown options via .strict() Zod validation.

// Before (v2.0.1 and earlier) — silently ignored
const honcho = new Honcho({ baseUrl: 'http://...' })  // typo: baseUrl vs baseURL — silently fell back to default

// After (v2.0.2+) — throws ZodError
const honcho = new Honcho({ baseUrl: 'http://...' })  // ZodError! Use baseURL

13. peer() and session() always make API calls (v2.1.0+)

Breaking: peer() and session() now always make a get-or-create API call. Previously, calling without metadata/configuration returned a lazy object with no API call.

// Before (v2.0.x) — no API call without options
const session = honcho.session('my-session')  // Lazy, no network request

// After (v2.1.0+) — always hits the API
const session = await honcho.session('my-session')  // Makes POST to /sessions (get-or-create)

14. New properties and methods (v2.1.0+)

// createdAt on Peer and Session
const peer = await honcho.peer('user-123')
console.log(peer.createdAt)  // string | undefined

const session = await honcho.session('sess-1')
console.log(session.createdAt)  // string | undefined

// isActive on Session
console.log(session.isActive)  // boolean | undefined

// getMessage() on Session
const msg = await session.getMessage('msg-id')

15. Pagination parameters on list methods (v2.1.0+)

All list methods now accept page, size, and reverse parameters:

// Before (v2.0.x) — only filters
const peers = await honcho.peers({ metadata: { role: 'admin' } })

// After (v2.1.0+) — pagination controls via options object
const peers = await honcho.peers({
  filters: { metadata: { role: 'admin' } },
  page: 2,
  size: 25,
  reverse: true
})

// Legacy raw-filter form still works:
const peers = await honcho.peers({ metadata: { role: 'admin' } })

// Works on: honcho.peers(), honcho.sessions(), honcho.workspaces(),
// peer.sessions(), session.messages(), scope.list()

16. searchQuery moved in context() (v2.1.0+)

Breaking: searchQuery removed from top-level context() options. Use representationOptions.searchQuery instead.

// Before (v2.0.x)
await session.context({ searchQuery: '...' })

// After (v2.1.0+)
await session.context({ representationOptions: { searchQuery: '...' } })

17. Broader fetch retry logic (v2.1.1+)

The SDK now retries on all TypeError network failures (connection resets, DNS errors, etc.) instead of only those with 'fetch' in the message. No code changes needed — this is transparent.

Quick Reference Table

v1.6.0v2.0.0
client.coreclient.http
getConfig()getConfiguration()
setConfig()setConfiguration()
getPeers()peers()
getSessions()sessions()
getWorkspaces()workspaces()
getDeriverStatus()queueStatus()
pollDeriverStatus()Removed - do not poll
peer.chat(q, { stream: true })peer.chatStream(q)
peer.workingRep()peer.representation()
peer.getContext()peer.context()
peer.observationspeer.conclusions
peer.observationsOf()peer.conclusionsOf()
session.getPeers()session.peers()
session.getMessages()session.messages()
session.getSummaries()session.summaries()
session.getContext()session.context()
session.workingRep()session.representation()
session.peerConfig()session.getPeerConfiguration()
session.setPeerConfig()session.setPeerConfiguration()
{ timeoutMs: 60000 }{ timeout: 60000 }
{ maxObservations: 50 }{ maxConclusions: 50 }
{ includeMostDerived }{ includeMostFrequent }
{ lastUserMessage }{ searchQuery }
{ config: ... }{ configuration: ... }
message.peer_idmessage.peerId
message.created_atmessage.createdAt
peer.card()peer.getCard() (card() deprecated)
(new)peer.setCard(string[])
ObservationConclusion
ObservationScopeConclusionScope
(new v2.1.0)peer.createdAt / session.createdAt
(new v2.1.0)session.isActive
(new v2.1.0)session.getMessage(id)
(new v2.1.0)page, size, reverse on list methods
context({ searchQuery })context({ representationOptions: { searchQuery } })

Detailed Reference

For comprehensive details on each change, see:

  • DETAILED-CHANGES.md - Full API change documentation
  • MIGRATION-CHECKLIST.md - Step-by-step checklist

New Error Types

import {
  HonchoError,
  AuthenticationError,
  BadRequestError,
  NotFoundError,
  PermissionDeniedError,
  RateLimitError,
  ConflictError,
  UnprocessableEntityError,
  ServerError,
  ConnectionError,
  TimeoutError
} from '@honcho-ai/sdk'

New Configuration Types

Configurations are now strongly typed:

await honcho.setConfiguration({
  reasoning: {
    enabled: true,
    customInstructions: 'Be concise'
  },
  peerCard: { use: true, create: true },
  summary: {
    enabled: true,
    messagesPerShortSummary: 20,
    messagesPerLongSummary: 60
  },
  dream: { enabled: true }
})

Related skills

How it compares

Use migrate-honcho-ts for TypeScript Honcho upgrades; use migrate-honcho for Python v1.6 to v2.0 migrations.

FAQ

What replaced Honcho TypeScript `.core`?

Honcho TypeScript removed the `.core` property that exposed the raw `@honcho-ai/core` client. Developers use `.http` for advanced HTTP access, while the SDK handles workspace creation automatically in typical flows.

What return type changes affect Honcho TypeScript migrations?

migrate-honcho-ts covers listing changes where `workspaces()` now returns `Page<string>` instead of `string[]`, and `session.peers()` returns `Peer[]` instead of `Page<Peer>`, requiring pagination and iteration updates.

Is Migrate Honcho Ts safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

AI & Agent Buildingagentsautomation

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.