DigitalOcean AI

Posts on this board are short and written in plain text, with just a Title and a Details field. Here's a version to match: Title Native Google ADK adapter for Harness Runtime Details Harness Runtime has native adapters for Codex, Claude Code, OpenCode, Hermes and LangGraph, but not Google ADK. ADK agents can run today with the custom adapter, but this has gaps: - Limited event detail. Tool calls, sub-agent hand-offs and model responses are not clearly shown in the event stream. - No reliable permission enforcement. Allow / ask / deny rules and approvals cannot be guaranteed on ADK tool calls. - Unclear feature support. It is not clear whether Action Gateway, capabilities and other features work with the custom adapter. For production use, the permission gap is a blocker. Please add a native google_adk adapter that: - Is available in the Create Environment UI and the API. - Maps ADK runner events (tool calls, agent transfers, model responses, state changes) to the Harness Runtime event stream. - Enforces tool permissions and approvals, including on sub-agent tool calls. - Supports the standard ADK entry point (root_agent) and session lifecycle. - Works with Serverless Inference, custom OpenAI-compatible endpoints (for example, via LiteLLM) and Gemini, with API keys stored as secrets. - Matches the other adapters on sandbox sizes, egress, secrets, capabilities, Action Gateway and persistent workspace. This would give ADK multi-agent workflows the same governed, observable production path that LangGraph has today. Refs: https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/concepts/agent-adapters/ https://github.com/google/adk-python

LLM costs can easily go through the roof if we are not careful, unlike other services. Any way for Gradient AI to have this cap?

I genuinely don't understand why you're keeping the TPD limit under wraps for "risk control" or "security" reasons. I've worked on risk control myself—your API response headers return this data on every single call. It's already an open secret at this point. Honestly, this kind of restriction does nothing for "security purposes"; all it does is leave legitimate customers confused and helpless when they inexplicably hit 429 errors. Let's be real: if I were a bad actor, I'd just make one API call, see the TPD limit in the headers, and know exactly what's going on. It serves no purpose whatsoever. Mainstream platforms all publish their rate limits explicitly, and besides, calling your API costs money. it's not post-paid. I personally cannot comprehend why you've set things up this way.

I have been working with xAI's Grok and would like to have that be an option here as well.

Please create an option for the user to create a personal AI agent that knows their account, so they can ask it to change, modify, create, and handle every technical aspect. This will make life much easier, and the site's complexity will decrease, so many people can use it.

I would love it if Digital Ocean offered HIPPA Compliance LLM Inference as a service. I'm getting my BAA signed with multiple vendors right now to be able to do this. I would pay a premium to only have to deal with 1 provider.

Please consider adding GLM-5.1 and Kimi K2.6 to DO AI. They are strong open-weight models that could offer great performance at a lower cost compared to many proprietary alternatives, making them especially attractive for developers and startups.

There are many horror stories of small businesses getting hit with surprise large bills from inference usage of leaked keys. Google Vertex AI added a feature to set inference limits because of this. Other inference providers all have this too. By the time a monitoring email is fired, its usually too late since the cost get very high very quickly. There's no ambiguity about shutting down anything since the server should just refuse any further inference. Digital Ocean is missing this feature. Digital Ocean already has its own limits so most of the work needed is already done. A hard user adjustable per API key monthly spend limit would be ideal.

It would be good if the chatbot can look up user account information, but will need a way to pass through a session token through the chatbot to the underlying function, that way the chatbot can make authenticated function calls on behalf of the user.

It would be nice to have a feature for the embedded AI agent where users could provide feedback on answers (perhaps by clicking 👍/👎 under the agent's response). If it is then possible to see which queries and responses yielded what feedback, this feedback would offer valuable insight into the agent's performance in real world settings and could point to, for example, flaws in our documentation. Thank you for your consideration! Kind regards, Rens