Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat/realtime #2131

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

feat/realtime #2131

wants to merge 1 commit into from

Conversation

ysolanky
Copy link
Contributor

Description

Realtime init


Type of change

Please check the options that are relevant:

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Model update (Addition or modification of models)
  • Other (please describe):

Checklist

  • Adherence to standards: Code complies with Agno’s style guidelines and best practices.
  • Formatting and validation: You have run ./scripts/format.sh and ./scripts/validate.sh to ensure code is formatted and linted.
  • Self-review completed: A thorough review has been performed by the contributor(s).
  • Documentation: Docstrings and comments have been added or updated for any complex logic.
  • Examples and guides: Relevant cookbook examples have been included or updated (if applicable).
  • Tested in a clean environment: Changes have been tested in a clean environment to confirm expected behavior.
  • Tests (optional): Tests have been added or updated to cover any new or changed functionality.

Additional Notes

Include any deployment notes, performance implications, security considerations, or other relevant information (e.g., screenshots or logs if applicable).

Copy link
Contributor

@dirkbrnd dirkbrnd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great start to make it work with our implementation.
I think if we are going to release this, it has to be with either a built-in websocket interface or a guide on how to build a websocket API using the real-time model.
Because live/cli mode is great for testing, but it doesn't translate to production right?

messages=self.run_response.messages,
extra_data=self.run_response.extra_data,
event=event.value,
# tools=self.run_response.tools,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

? Just curious

await self.aprint_response(message=message, stream=stream, markdown=markdown, **kwargs)


async def live(self, exit_on: Optional[List[str]] = None, **kwargs: Any):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from the acli experience?

@@ -3808,3 +3808,97 @@ def cli_app(
break

self.print_response(message=message, stream=stream, markdown=markdown, **kwargs)

async def acli_app(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are doing this it might be worthit to consider the DX here.

  1. We could consider making CLI / Live a separate class that takes an agent in a constructor, similar to a playground app setup. I kinda feel like it would be more intuitive to use, even though it is more lines of code?
  2. Alternatively this needs a better name I think. run_live and arun_live?


async def create_connection(self):
"""Create and store a persistent connection."""
self.connection = await self.get_async_client().beta.realtime.connect(model=self.id).enter()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be done in get client right?



@dataclass
class OpenAIRealtime(Model):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider making a whole new base_model for realtime models? They kinda work in fundamentally a different way? It could then support a connection and methods like send_message(both text and audio), process_response, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants