Hi everyone! I just saw the announcement about Continue's new API. As someone who's been using Continue for a few months to streamline my team's Python and container-based workflows, this is really exciting news! I wanted to start a thread to gather some thoughts from the community.
I've been looking through the developer preview documentation, and it seems like a solid foundation. The ability to potentially integrate Continue's capabilities directly into our CI/CD pipelines or custom tooling is a game-changer. I'm particularly curious about the endpoints related to context management and workspace actions. Has anyone else had a chance to experiment with the preview?
A couple of things I'm wondering about, based on my initial read:
- How comprehensive is the current scope? The docs mention models, contexts, and steps, but I'm curious about the granularity of control for things like session history or prompt templates.
- What's the authentication story like? I saw API keys mentioned, which is standard, but I'm always interested in best practices for securing these in automated environments.
- For those of us deep in version control, could this API open doors for pre-commit analysis or automated PR description generation? The possibilities seem vast.
Big thanks to the Continue team for putting this out there! I'm really looking forward to seeing how this evolves and what the community builds with it. 😊
still learning
Your point about pre-commit analysis is exactly where my mind went. If the API exposes granular model usage data, we could start building quality gates based on token consumption or response patterns within our CI workflows.
I am, however, already thinking about the data lineage challenges. If teams start firing API calls from various scripts, we'll need to instrument everything to track provenance - otherwise our analytics on "how we're using Continue" will be a black box. The preview docs should ideally address observability hooks or at least a standard way to pass a session identifier.
For authentication in automated environments, I'd recommend a pattern similar to other platform APIs: a service account key rotated via a scheduled job, with usage logs fed directly into a secure audit table. Without that logging, troubleshooting a failed pipeline step becomes guesswork.
Garbage in, garbage out.
Great point about the audit logging. We're using a similar service account pattern for our Looker service tokens, and having those logs in a central table is a lifesaver for debugging.
When you mention a session identifier, do you think it would be enough for the API to just accept a custom header we could set, like `X-Correlation-ID`? That way we could pass through our own internal request IDs from our orchestrator.
I hadn't even considered the data lineage angle, but you're totally right. If we can't trace an API call back to a specific pipeline run or user script, optimizing our usage later will be impossible.