CSPeach™

Architecture

Two paths into SAP.

Both keep your ABAP source in your environment.

Pick the one that matches your controls.

The two planes

How the data flows.

CSPeach traffic splits into two independent planes that share only one endpoint: your CLI. The LLM plane handles AI calls and skill bundles. The SAP plane handles ABAP. They never cross.

CSPeach two-plane architecture A single CLI on the developer's laptop emits two independent transports. The LLM transport goes through api.cspeach.dev on Fly to Anthropic over the Anthropic Messages API, with skill bundles fetched from manifest.cspeach.dev. The SAP transport goes direct from the laptop to the SAP system over ADT REST, or optionally via a customer-deployed BTP wrapper using XSUAA, Destination Service, and Cloud Connector. When a CSPeach skill reads ABAP source for the LLM to explain or refactor, that source travels the LLM transport as prompt content — not the SAP transport. LLM PLANE api.cspeach.dev Fly · US-East Anthropic Messages API Anthropic / OpenAI model API manifest.cspeach.dev skill bundles BYOK and AI Hub modes bypass api.cspeach.dev. SAP PLANE Fast lane laptop → SAP direct ADT via your BTP wrapper BTP lane XSUAA · Destination · CC on the roadmap ADT REST Your SAP system ECC · S/4 · BTP ADT REST stays in this plane. HTTPS ADT REST cspeach-cli developer laptop
Two independent transports from the CLI. ADT REST goes direct to your SAP system. LLM requests go to the proxy — or, in BYOK / SAP AI Hub modes, directly to your chosen LLM endpoint. ABAP source you ask CSPeach to explain, review, or refactor is included in the LLM prompt. See the FAQ for the full data-residency breakdown.

Fast lane — today, default Available today

Developer laptop. Direct to SAP.

The developer runs cspeach from their laptop. ADT REST goes straight to SAP, in-process via @cspeach/sap-client. SAP credentials (user/password or X.509) stay in the laptop's OS keychain.

Who's on this lane
Every developer using CSPeach today. Solo developers, consultancies, mid-size teams — anyone running CSPeach against their own SAP without standing up extra infrastructure first.
What you get
SAP's CHANGE_LOG shows the real developer — not a bridge user, not a certificate proxy. The same audit trail your SAP team already runs on every other developer action. No XSUAA to configure, no Cloud Connector to deploy, no Destination Service to maintain.
When to look at BTP lane
Shops with strict identity policies that require XSUAA + Principal Propagation for every external system, or shops that don't want developer-held SAP credentials at all.

BTP lane On the roadmap — design ready, build in progress

Your BTP. Your audit.

A small wrapper in your own BTP Cloud Foundry subaccount. The wrapper uses the same standard BTP services your team already uses for any custom extension:

  • XSUAA for authentication. The CLI does OAuth2 PKCE device flow; XSUAA returns a JWT.
  • Destination Service for SAP routing. Customer-managed destination, customer-controlled.
  • Cloud Connector for on-prem reach. Outbound-only tunnel from your LAN.
  • Principal Propagation so SAP sees the real developer in SU01 and CHANGE_LOG audit — not a bridge user.

The wrapper will be published open-source when the build is complete. ADT REST traffic stays inside the customer's BTP tenant — it never crosses cspeach.dev or fly.dev. Prompts sent to the LLM travel the LLM plane — the managed proxy by default, or direct to Anthropic in BYOK mode (available now); your AI Hub once that mode ships — see the FAQ for the breakdown.

Roadmap: optional MCP-client mode for customers who deploy SAP's ABAP MCP Server (GA TechEd 2025).

Bring your own key Available today

Your model. Your key.

Set your organization's Anthropic key once. From then on every developer's prompts go straight to Anthropic — on your key, your bill, your contract. The CSPeach proxy is never on the prompt path.

CSPeach BYOK data path The organization sets its Anthropic key in the CSPeach portal, where it is encrypted at rest. Each developer's CLI fetches the key at login into the operating-system keychain. At runtime, prompts and responses travel directly from the developer's laptop to the Anthropic API over TLS. The CSPeach proxy provides skills, authentication and billing only, and is never on the prompt path. CSPeach proxy · Fly skills · auth · billing never on the prompt path CSPeach portal key set once AES-256-GCM at rest Developer CLI key in OS keychain cspeach login Anthropic API api.anthropic.com at login every prompt — direct TLS, end to end CSPeach-hosted your machine your Anthropic account
Set once, encrypted at rest. Pulled into each developer's keychain at login. From there, every prompt and response is TLS-direct laptop → Anthropic — the proxy serves skills, auth and billing, never the prompt.
Encrypted at rest

Your key, sealed

Stored AES-256-GCM encrypted and bound to your org, never logged, shown only as sk-ant-…•••• with a fingerprint. Rotate or revoke any time.

Set once · fleet-wide

Admins set, developers inherit

An owner sets the key in the portal. Every developer's CLI pulls it at cspeach login into their OS keychain — no keys shared over chat, no per-seat copy-paste.

Off the prompt path

Prompts go direct

At runtime the CLI calls api.anthropic.com directly. Your prompts and the model's responses never transit CSPeach. The proxy serves skills, auth and billing only.

Your Anthropic account

Your bill, your terms

Usage lands on your Anthropic contract — your rate limits, your invoicing, your data-retention and zero-retention terms apply, end to end.

Trust boundaries

What lives where.

Concern Wrapper
(open source, customer-deployed)		 Fly proxy
(closed, CSPeach-owned)
Anthropic / OpenAI routing—✓
BYOK key handling—✓
AI Hub mode (future)—✓ (routes to customer's AI Hub URL)
Skill content + signing—✓
Classifier (Haiku)—✓
Spend caps, billing, customer DB—✓
GitHub OAuth / device auth—✓
XSUAA OAuth2 / JWT validation✓—
Destination Service binding✓—
Cloud Connector binding✓—
ADT REST forwarding to SAP✓—
Scope / role enforcement✓—
Audit log of SAP operations✓—
ABAP source code in flight✓ (transit only, in customer tenant)—

The wrapper has no business logic. It validates JWT, applies scope rules, forwards to ADT, returns the response. A competent reviewer can read the wrapper end-to-end in roughly two hours.

Architect FAQ

Questions architects ask.

Does my ABAP source enter cspeach.dev?

Only when you ask a skill to use it. The CLI's skills (/abap-explain, /abap-review, /abap-refactor and others) read the code locally via ADT, then include it in the LLM prompt so the LLM can do the work. In managed mode (today's default), those prompts transit our Fly proxy on their way to Anthropic.

ADT REST traffic itself — read object, write source, ATC, activation, transport — always goes direct laptop → SAP and never transits our proxy in any mode.

Source your team doesn't share with a CSPeach skill never leaves SAP. To keep prompt contents off our proxy too, BYOK mode (available now) routes the LLM call direct from laptop to Anthropic; SAP AI Hub mode (on the roadmap) does the same to your AI Core.

Where do LLM keys and prompts live?

CSPeach has two LLM modes available today (Managed and BYOK) and one more on the roadmap, with different data-residency trade-offs:

  • Managed (today, default) — our Anthropic key lives on our Fly proxy. Your prompts and the LLM's responses transit our proxy so we can meter and bill per use. ADT REST traffic does not transit our proxy in any mode.
  • BYOK (available now) — your own Anthropic key is set once in the portal (encrypted at rest) and pulled into each developer's laptop OS keychain at login. LLM traffic goes laptop → Anthropic directly; we don't see your prompts. See Your model. Your key. for the full path.
  • SAP AI Hub (on the roadmap) — your AI Core token lives in your laptop's OS keychain. LLM traffic goes laptop → your SAP AI Core in your own BTP. We don't see your key or your prompts. Requires a customer-side translation proxy (e.g. SAP's hAIperspace, or pjq/sap-ai-core-llm-proxy) because SAP AI Core doesn't natively speak the Anthropic Messages API.
In BYOK mode, what does CSPeach still see?

Your prompts and the model's responses: never. In BYOK mode the CLI calls api.anthropic.com directly — that traffic does not pass through any CSPeach service.

What CSPeach still handles:

  • Your Anthropic key — held encrypted at rest (AES-256-GCM, bound to your org) so it can be handed to your developers' CLIs at login. Never logged, never shown in clear; used only from each developer's OS keychain at runtime. Rotate or revoke any time.
  • Your CSPeach account — login, seats and roles, plus the signed skill manifest the CLI fetches.

What CSPeach does not see in BYOK mode: your model usage and spend. Because inference goes straight to Anthropic, your token usage and billing run on your Anthropic contract — not metered by us.

Where will the wrapper run?

In your own BTP Cloud Foundry subaccount. It uses standard BTP services — nothing custom or non-standard. The wrapper is small enough to read end-to-end in roughly two hours; the source will be published open-source when the build is complete. Currently on our roadmap — see the BTP lane section above.

Does it work with our SSO?

The wrapper uses XSUAA + Principal Propagation; supports Azure AD, Okta, SAP IAS, anything XSUAA can federate to.

What about audit?

Principal Propagation passes the real user identity to SAP. SU01 and CHANGE_LOG see the developer, not a bridge user.

Can we self-host the LLM side too?

Yes — point CSPeach at your own SAP AI Core via the AI Hub mode, with the translation proxy noted above. Local-only LLM (Ollama / vLLM) is on the roadmap but not yet supported for skill workflows.

Want the wrapper when it ships?

Tell us, and we'll let you know.

Get notified when the wrapper ships Try CSPeach today